AI agent delegated authority should preserve three distinct principals: the user or service requesting an outcome, the agent selecting an action and the executor changing an authoritative system. Collapsing them into one service account makes access easy but destroys accountability. A protected resource should know who initiated the work, which agent acted, which workload presented the request, what delegation was granted and which policy allowed the exact effect.
This model extends permissions beyond a list of tools. Edilec's AI agent control plan explains action tiers, approvals and audit, while the secure API access control guide covers bounded tokens and object policy. Here the focus is identity continuity across several decision makers and workloads, especially when an agent calls MCP servers or delegates to another agent.
Start AI agent delegated authority with three principals
The initiator owns the business request and may be a human, scheduled service or upstream workflow. The agent is a governed software identity associated with a model, configuration, owner and allowed role; it chooses among permitted actions but should not authenticate as the user. The executor is the workload and domain service that validates authority and commits the effect. In some deployments the agent runtime and executor share infrastructure, but their logical roles and evidence remain separate.
Add intermediaries when needed without losing the core distinction: coordinator agent, specialist agent, protocol gateway and tool server. Each hop records actor and subject rather than replacing the chain with the latest caller. The domain resource decides how much of the chain it needs for policy. A low-risk read may require user and workload; a regulated approval may require every delegation and configuration identifier.
Choose delegation instead of accidental impersonation
RFC 8693 describes token exchange and distinguishes delegation from impersonation. In delegation, an actor operates on behalf of a subject and both can remain represented. In impersonation, the intermediary acts as the subject within the granted context and may be indistinguishable to the receiver. Agents usually benefit from explicit delegation because investigators and policy engines need to know that software selected the action.
Do not place “on behalf of Alice” only in a log message or prompt field. Use identity-provider-supported claims or a protected evidence reference whose integrity the resource trusts. Define maximum delegation depth, permitted actor types and whether an agent may delegate further. Reject chains with an unknown issuer, missing audience, expired link or agent that is not approved for the requested resource.
| Principal | Proves | Must be authorized for | Evidence field |
|---|---|---|---|
| Initiating user or service | Origin of business request | Purpose, tenant and source records | subject_id and authentication event |
| Agent identity | Software configuration selecting action | Capability, delegation and risk tier | agent_id and release ID |
| Gateway or runtime workload | Mediated network request | Route and credential exchange | client_id and workload identity |
| Executor | Committed authoritative effect | Object, action and invariants | service_id and result reference |
| Approver when required | Accepted a bounded consequence | Specific request digest and window | approver_id, decision and expiry |
Give every agent a governed non-human identity
Register an agent identity with owner, purpose, environments, model and prompt release, tool allowlist, data classes, maximum authority, incident contact and expiry. Do not use a generic “AI service” identity for unrelated agents. Issue credentials to the workload through a managed workload identity system, not static secrets in prompts or configuration files. Rotate credentials independently from model or agent releases.
Review the agent as a software principal throughout its lifecycle. A changed model, system instruction, tool set or autonomy level may materially change how the identity is used even if its client ID remains constant. Require release evidence before expanding authority. Disable dormant agents, remove unused grants and preserve historical release identifiers so prior actions remain attributable after upgrades.
Issue audience-bound credentials at each resource
The user authenticates to the application. The application or agent runtime then obtains a token for the specific MCP server or API, carrying only approved subject and actor context. The MCP authorization specification requires resource indicators in its HTTP authorization profile so the token identifies the intended MCP resource. That MCP token should never be passed to a backend API with a different audience.
When the MCP server calls the backend, it uses token exchange, a supported on-behalf-of flow or its own workload credential with a protected delegation reference. The backend validates audience, issuer, expiry, actor, subject and scopes before evaluating domain policy. Short lifetimes limit exposure, while sender-constrained tokens can reduce bearer replay where supported. Models never receive or transform credentials.
Authorize the request, chain, and object together
A valid token proves an authenticated grant, not that every action is appropriate. Policy should combine initiator role, agent identity and release, executor, tenant, object ownership, tool, argument limits, time, device or workload assurance and approval evidence. The server that owns the record enforces invariants. A gateway can deny broad classes early, but it should not become the only place where business authorization exists.
Follow the resource-centric approach in NIST's Zero Trust Architecture: protect users, assets and resources through explicit decisions rather than trust inherited from network location. Re-evaluate long-running tasks when access, risk or resource state changes. An approval should authorize a digest of consequential fields and expire; it should not create a durable super-scope for the agent.
Match federation assurance to consequence
Cross-domain agent systems depend on federation and assertions. NIST SP 800-63C describes federation assurance levels with increasing audience restriction, replay protection, assertion-injection protection and trust requirements. Use these concepts to assess identity assertions entering an agent platform. Higher-consequence actions need tighter audience, proof and trust establishment than a low-risk informational query.
Document which identity provider vouches for each principal, how keys are established, how assertions are bound to relying parties and how revocation propagates. External agent metadata or a self-declared name is not identity proof. Verify organizational control of endpoints and signing keys. Where partners cannot provide the required assurance, constrain them to lower-risk capabilities or require an internal approval and executor.
Build a reconstructable delegation record
For every consequential action, record initiator, authentication event, agent and release, intermediate actors, target resource, tool contract, scopes, policy decision, approval, request digest, idempotency key, executor and authoritative result. Use stable pseudonymous identifiers where direct personal data is unnecessary. Protect integrity and access. Logs should reference credentials by token or grant identifier, never store bearer values.
Join events with a trace and business task ID, but do not rely on trace context for authorization. The audit log design guide helps structure who, what, when and outcome evidence. Test whether an investigator can distinguish user intent from agent choice and executor behavior. If all three appear as one service account, the design has failed even if a verbose prompt transcript exists.
| Control failure | Resulting ambiguity | Required prevention |
|---|---|---|
| Shared agent service account | Which agent release selected the action | Distinct agent IDs and release evidence |
| User token passed downstream | Which intermediary exercised authority | Audience-bound exchange with actor context |
| Approval stored as prose | Which exact effect was accepted | Request digest, approver and expiry |
| Gateway-only authorization | Whether domain invariants were checked | Resource-server object and action policy |
| Token captured in logs | Credential can be replayed | Secret redaction and reference-only evidence |
Roll out authority in measured stages
Begin with read-only access where logs show all three principals. Add one reversible action under deterministic policy and required human approval. Then introduce delegated execution with audience-bound tokens and idempotency. Run wrong-audience, wrong-tenant, expired-approval, unapproved-agent and compromised-gateway tests. Advance only when both denial and successful outcome can be reconstructed from protected evidence.
Review authority as a portfolio. Measure grants by agent, unused scopes, denied chains, privilege escalation, approval frequency, stale agent releases and actions lacking complete principal evidence. Tie access review to agent ownership and deployment inventory. When retiring an agent, revoke credentials and grants, remove catalog visibility and retain compact historical attribution. The runtime should fail closed if the identity service cannot verify a consequential chain.
Key takeaways
- Keep initiator, agent and executor as distinct principals even when they share infrastructure.
- Prefer explicit delegation evidence over accidental impersonation through a user token.
- Give each agent a governed identity tied to owner, release, tools and maximum authority.
- Issue a new audience-bound credential at every protected resource and keep tokens out of model context.
- Authorize the complete chain and exact object, then preserve a reconstructable result record.
Frequently asked questions
Is the agent identity the same as its workload identity?
Not necessarily. The workload identity authenticates the running software; the agent identity names the governed configuration and role selecting actions. One workload can host several agents, but requests must carry a protected agent identifier and release that policy can verify.
Can an agent use the user's access token?
Avoid direct pass-through. Obtain a token for the specific resource through an approved delegation flow, preserving actor context where possible. Direct reuse expands audience and makes the agent invisible to the downstream service and audit trail.
Who is accountable when an agent makes a mistake?
Organizational accountability depends on governance and law, but the technical record should identify the requester, system owner, agent release, policy, approver and executor. Clear evidence enables the organization to determine whether failure arose from intent, configuration, authorization, model behavior or execution.
Conclusion
AI agent delegated authority is trustworthy when identity survives automation. The user remains the originator, the agent remains the software actor choosing an action and the executor remains the resource owner committing it. Audience-bound credentials and resource policy connect those roles without giving any one token universal reach.
Test the architecture by selecting one production change and reconstructing the entire chain without reading a prompt transcript. If the evidence shows who asked, which agent release decided, what was approved, which credential reached which audience and what record changed, the design supports both control and useful delegation.