# 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 {#authority-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 and authenticated UI 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.

## Invocation-bound capabilities {#invocation-bound-capabilities}

A Resource integration sometimes needs to cross another privileged boundary after an invocation has been admitted. It does not authenticate again as the user, receive an ambient platform credential, or construct a second authorization scheme. Instead, it asks the owning runtime to mint a short-lived capability from the already admitted invocation.

```text
authenticated Run or Credential owner
              │
              ▼
admitted Resource invocation
  exact Resource + operation + arguments + Policy decision
              │
              ▼
invocation-bound capability
  audience + scopes + expiry + canonical invocation identity
              │
              ▼
privileged service validates its request-specific claim
              │
              ▼
owner-backed operations redeem against the original invocation record
```

The capability binds the exact Resource CRN and immutable Resource hash, invocation id and journal position, Policy decision hash, and canonical hash of the original operation arguments. Run-owned capabilities also bind their tenant, namespace, Agent, Session, Run, and pinned authority and Resource snapshots. Audience, scopes, claims, and expiry can only attenuate that authority.

Argument identity is independent of storage. The argument bytes may remain inline, move to content-addressed storage, or be materialized only while the integration runs; the canonical argument hash remains the invocation identity. A consumer must compare the signed capability with that original record. It must not derive a second identity from a database representation, content reference, or newly decoded copy of the payload.

The target service validates the signed common fields and may additionally bind the capability to its exact operation and request hash. When an operation needs authoritative live owner state, it redeems the capability with that owner against the original invocation record, including applicable terminal and revocation state. This preserves one Resource boundary across sandboxes, platform-management calls, Credential lifecycle work, and other delegated Resource operations without creating a second identity scheme for each service.

## Late binding without mutable history {#late-binding}

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 [Resources, effects, and recovery](/docs/foundations/resources-effects.md), [Policies](/docs/policies.md), [Scoped bindings](/docs/credentials/scoped-bindings), and [Channels and Auth Providers](/docs/channels.md).