Identity propagation and policy decisions

Preserve accountable identity

AI requests often cross user interfaces, gateways, applications, retrieval services, model endpoints, agents, and tools. If the original identity is replaced by one broad service account, downstream controls cannot reliably distinguish who requested an action, on whose behalf it runs, or what permissions apply.

Carry an identity envelope that separates:

• The initiating human or system actor.
• The authenticated workload and service identities.
• Delegated authority and its permitted scope.
• Tenant, project, purpose, and request context.
• Authentication strength, policy version, and relevant claims.
• Correlation identifiers for evidence and incident response.

Do not forward reusable user credentials through the chain. Use bounded delegation or token exchange where supported, with short lifetime, intended audience, and least privilege.

Policy decision and enforcement points

A policy decision point evaluates trusted identity and request context against versioned policy. A policy enforcement point applies the result. Keep these responsibilities explicit even when one product performs both.

A useful decision record states:

• Subject, resource, action, purpose, and environment.
• Policy and data versions used.
• Allow, deny, redact, require approval, or route result.
• Obligations such as filtering, logging, rate limits, or evidence capture.
• Reason code that is useful without exposing secrets.
• Decision and enforcement timestamps.

Fail securely and explainably

Define behavior for expired credentials, unavailable identity providers, missing claims, policy timeouts, clock drift, stale group membership, and evidence-store failure. High-impact actions should not become broadly allowed because a dependency is unavailable.

Service and tool identity

Every privileged workload, retrieval connector, model endpoint, and agent tool should have a distinguishable identity. Rotate credentials, constrain audience and network reachability, and make revocation effective. Authorization must be checked at the resource or action boundary, not inferred from the fact that a request passed an upstream gateway.