Identity, Policy, and authority

Learn how authenticated identity, exact Resource names, pinned Policy, scoped bindings, and safe-point controls constrain Agent execution.

Agent code is not an authority boundary. The platform authenticates the caller, resolves an exact principal and optional downstream customer, evaluates Policy against exact Constal Resource Names, and pins the accepted authority into the Run before tenant code executes.

Authority has layers

Platform, principal, Agent, Resource, Tool, and presented capability layers intersect. Explicit deny wins. Scopes only narrow an existing grant. Auth Providers return bounded identity evidence for Channel ingress; they cannot grant tenants, roles, scopes, customer CRNs, or Policies. Credential Providers create outbound authority for Resources; they do not authenticate incoming callers.

A Run records the Auth Provider evidence, customer authorization sequence, Policy CRNs and hashes, Resource snapshot, Toolset, deployment revision, and one aggregate authority hash. Replay continues against that accepted snapshot rather than silently acquiring current permissions.

Late binding without mutable history

Scoped bindings select the correct Resource or Credential for a tenant, customer, or principal at admission. An authenticated safe-point rebind can change Policy, budget, or Resources for later positions. Earlier facts and invocations keep their original hashes and provenance. Resource disable, integration disable, Credential revocation, and emergency deny cut through pinning at the next invocation boundary.

This model supports shared Agents without letting message input select authority. Customer identity comes from authentication; binding resolution happens under Policy; and Agent code receives only accepted names and safe identity views. Continue with Policies, Scoped bindings, and Channels and Auth Providers.