105 — Agent Identity & Delegated Authorization

Concept overview

Agent identity separates the human or system principal requesting work from the runtime and tools acting on that request. Delegated authorization carries a constrained permission relationship across those actors. An authenticated agent is not automatically entitled to every resource the user can access, nor should a user inherit the runtime's infrastructure privileges.

Design the effective permission as the intersection of user authority, workflow policy, workload capability, resource constraints, and current approval. Preserve both requesting and acting identities in audit records. Token exchange is one possible mechanism for obtaining audience-specific credentials; it does not replace application-level decisions about permitted business actions.

Why it matters in production

Proof of concept

A proof of concept may use one service identity with synthetic data, but should record where user and workload authority will diverge.

Production

Production requires workload authentication, audience-bound credentials, resource authorization, short lifetimes, and approval checks at the system performing the effect.

Enterprise scale

Enterprise scale adds delegation-chain visibility, revocation propagation, cross-domain trust policy, service ownership, and tests for confused-deputy and privilege-expansion paths.

Architecture components

Requesting principal

Provides the authenticated user or system identity and the authorized task context.

Workload identity

Identifies the specific runtime or tool service independently of the requesting principal.

Delegation broker

Issues constrained credentials for an approved downstream audience and operation scope.

Policy decision point

Combines principal, workload, resource, task, and approval attributes into a permit or deny decision.

Resource enforcement point

Rechecks authority at the target service and records both requester and actor in the operation receipt.

The architecture, mapped

flowchart LR
    U["Authenticated requester"] --> B["Delegation broker"]
    W["Verified workload identity"] --> B
    P["Workflow and approval policy"] --> B
    B --> T["Short-lived audience-bound token"]
    T --> E["Resource enforcement point"]
    E --> R["Permitted business operation"]
    E --> A["Requester and actor audit record"]

Runtime flow

1. 1

   Authenticate requester

   Resolve the principal and task context through the trusted application session rather than user-supplied identity text.

2. 2

   Identify workload

   Authenticate the runtime instance or tool service and verify that it is approved for the workflow class.

3. 3

   Constrain delegation

   Request the minimum audience, resource, operation, and lifetime needed for the next action, preserving the delegation relationship.

4. 4

   Evaluate business policy

   Check current resource access and any version-bound human approval before the downstream service accepts the request.

5. 5

   Execute with attribution

   Perform the allowed operation and record requester, actor, policy version, resource, and operation identifier.

6. 6

   Expire or revoke

   Stop issuing new authority when the task ends or access changes; reauthorize long-running steps before consequential effects.

Case-scoped investigation delegation

Banking · Illustrative enterprise scenario, not a reported customer outcome.

Business situation

Illustrative architecture: An operations employee asks an agent to collect evidence for a payment exception assigned to their branch.

The problem

A shared service credential could expose other branches or allow a drafting agent to perform payment release actions.

Agent requirement

Delegate only case-specific reads while maintaining separate approved authority for any later operational release.

Architecture

A broker derives scope from the authenticated assignment; each evidence service checks the requester, workload, and case resource before returning records.

Runtime

• Authenticate operator
• resolve assigned case
• authenticate investigation workload
• issue read audience token
• fetch permitted evidence
• record both identities

Failure scenario

The operator loses case assignment during a long investigation; subsequent reads fail reauthorization and the workflow pauses for reassignment.

Operational impact

Measure denied out-of-scope attempts, revocation delay, audit attribution coverage, and authorization latency; token issuance volume is not evidence of correct access.

Architecture tradeoffs

Failure scenarios & recovery

Common architecture mistakes

Using the model's claimed user ID as authentication.

Derive identity only from verified application and workload channels.

Propagating one bearer token through every tool.

Issue audience-specific credentials and minimize downstream scope.

Recording only the agent's service account in audit logs.

Preserve requester, actor, delegation context, and policy decision references.

When to choose this pattern

Choose it when

• Agents act on behalf of users across several enterprise services.
• Different specialists require different resource and operation permissions.
• Long-running workflows must respond to reassignment, revocation, and changed approvals.

Avoid it when

• Anonymous public information retrieval needs no delegated enterprise authority.
• The target service cannot enforce resource scope or distinguish requesting and acting identities.
• Delegation would bypass an existing required human authorization step.

Architecture checklist

• Define requesting, acting, and approving identities for every consequential operation.
• Authenticate workloads independently of user sessions and model text.
• Restrict token audience, resource scope, operations, and lifetime.
• Recheck resource authorization and approval at the target service.
• Record the delegation chain and policy version without logging credential secrets.
• Test confused-deputy, wrong-audience, and revoked-assignment scenarios.
• Define renewal, revocation propagation, and policy-unavailable behavior.

Related concepts

• 21 — Authorization-Aware RAG
• 22 — Role-Based Access Control (RBAC)
• 23 — Attribute-Based Access Control (ABAC)
• 26 — VPC Peering / Private Links
• 30 — Non-Repudiation Logs
• 34 — Tenant Isolation
• 44 — Human-in-the-Loop (HITL)

Primary references

• IETF RFC 8693: OAuth 2.0 Token Exchange
• NIST SP 800-207: Zero Trust Architecture
• MCP authorization specification, 2025-11-25