An Agent Identity Is Not an Authorization Decision: Designing Delegated Authority End to End

Agent identity answers which workload is calling. Production authorization must also preserve the human subject, delegation scope, resource audience, task intent, approval, and current business state across every hop.

Giving every agent a distinct identity is necessary. It is also easy to overstate what that accomplishes.

Identity lets a gateway distinguish a planner agent from a finance agent. Authentication provides evidence that the caller controls that identity. Neither fact answers whether the employee was allowed to delegate a particular action, whether the agent may use this tool for this user, whether the downstream token is intended for this resource, whether a human approved these arguments, or whether current business state permits the transaction.

Those are authorization questions distributed across several systems. Treating “the agent authenticated” as their answer creates a new confused deputy: a legitimate workload with a valid credential can be induced to use its reach for the wrong subject, purpose, resource, or moment.

Preserve three principals instead of flattening them

A useful request record therefore carries at least two identities. The human or initiating service remains the subject. The currently executing agent is the actor. In a multi-agent system, the subject can remain stable while the actor changes at every hop. That lets policy ask both “may this user delegate the task?” and “may this agent perform it?”

The third principal is often implicit: the owner of the resource and its policy. A finance application, customer database, source repository, or production control plane has its own authorization rules. An agent platform can authenticate callers and narrow tool reach, but it should not manufacture business authority that the downstream system has not granted.

Separate inbound identity from outbound authority

Agent tool calls cross at least two authentication boundaries. Inbound authentication tells the gateway who is calling it. Outbound authentication determines which credentials the gateway or MCP server presents to the downstream service. These may intentionally differ.

A service-mode agent might authenticate inbound with a machine identity and use a shared downstream service account. Every user receives the same effective data access unless the application adds its own controls. A per-user design may authenticate the human through an identity provider and use per-user OAuth or token exchange/on-behalf-of so a downstream service can enforce user-specific rights. TrueFoundry also documents token passthrough when the MCP server itself validates the same inbound TrueFoundry or identity-provider token. The choice is part of the security model, not plumbing.

Audience binding matters as well. The July 28, 2026 MCP authorization security considerations require clients to identify the target resource and servers to validate that a token was issued for them. They also distinguish the token presented to an MCP server from a separate token the server may use with an upstream API. The specification forbids an MCP server from passing the client’s MCP token through to an upstream API. TrueFoundry’s documented token-passthrough mode is narrower: the gateway forwards the inbound token to an MCP server configured to validate that same issuer and audience. Reusing a broad token across unrelated resources turns one compromise into lateral movement and obscures which service actually authorized the call.

For every tool path, document the inbound subject, agent actor, gateway authorization, outbound credential mode, token audience, downstream principal, and final policy decision point. If a team cannot trace that chain, it cannot reliably explain whose authority produced an action.

Intersect authority at every agent hop

This prevents permission laundering. Suppose an executive may view strategic forecasts and a research agent may query public sources. A planner that can call both should not cause the research agent to receive the executive’s private-data rights. Conversely, a finance worker with standing ERP access should not exercise it for every user who can invoke the planner. Each hop must verify the agent, the subject, the delegation relationship, the requested resource, and the task scope.

A delegation envelope can make those facts explicit. It can include subject, actor, parent actor, task identifier, allowed operations, resource identifiers, data classes, purpose, expiry, maximum depth, approval reference, and correlation identifier. The envelope is not necessarily one universal token; it is the minimum semantic record that policy and evidence systems must preserve across protocol-specific credentials.

Delegation should be attenuated. A parent can grant a child less than it holds, not more. Child agents should not forward credentials they do not need. Maximum chain depth and approved agent-to-agent relationships limit unexpected fan-out. Revocation should cut off new calls promptly, while already committed business operations follow explicit cancellation or reconciliation rules.

Scope approval to a decision, not just a tool name

Human approval is often implemented as “allow the refund tool.” That may be adequate for low-risk cases, but it is not equivalent to approving every future argument, customer, and amount. A strong approval record names the requester and agent, operation, material arguments or their digest, resource, reason, validity, and the state the reviewer saw.

Validity can be count-based or time-based, but time alone is not enough. A payment approved while an invoice was valid may become unsafe after bank details change. A deployment approved for one artifact digest should not cover a different build. Material state changes should invalidate or re-check the approval before execution. The application owns this binding because it understands the business object; a gateway approval can provide a valuable tool-level lease without knowing every domain invariant.

Approval also does not replace authorization. An approver should not be able to grant access they do not possess. The tool must remain within the agent’s permitted reach, the subject’s delegable authority, and downstream policy. Approval is an additional condition for a sensitive action, not an override channel.

Reauthorize at the mutation boundary

Agent runs can last minutes or hours. During that time, a user may change roles, a customer record may be locked, an invoice may be paid, a policy may be tightened, or an approval may expire. Authorization evaluated only when the conversation began is stale by construction. Recheck short-lived credentials and high-impact business conditions at the point of mutation.

Use an operation identifier for any retryable side effect. Persist intent before the call, send the identifier where the target supports idempotency, and reconcile against the system of record after ambiguous failure. A runtime event saying “tool returned success” is evidence about the tool interaction; it is not proof that the target committed the intended state. The authoritative transaction or postcondition supplies that proof.

Design the audit record for reconstruction

An audit record should let an investigator reconstruct the authority decision without replaying a model’s hidden reasoning. Record the subject and actor identities, authenticated issuers, parent delegation, requested operation, normalized arguments or protected digest, resource, applicable policy versions, authorization result, approval decision, model and tool events, operation identifier, and reconciled outcome.

Do not store sensitive bodies indiscriminately in the name of auditability. Metadata can establish who, when, which policy, which model, which tool, and how much without retaining raw prompts. Where content is necessary, apply access controls, retention limits, redaction, and purpose-specific logging. TrueFoundry’s current logging configuration explicitly separates stored request and response bodies from cost, token, latency, and metadata records: body storage can be suppressed or redacted while the other trace data remains recorded.

Tamper resistance and retention remain deployment responsibilities. Decide where records are exported, who may alter them, how clocks are synchronized, what correlation identifiers cross systems, and how long each evidence class is retained. Non-repudiation is not produced by adding an agent ID field to an ordinary mutable log.

How TrueFoundry and TrueForge fit

The product mapping is strongest when identity and control surfaces are composed deliberately. For a per-user workflow, preserve the user token, attach the current agent identity, authorize that pair at the gateway, use the intended downstream delegation mode, hold consequential tools where human approval is required, and propagate an operation identifier into the business application. The application then enforces current state and returns an outcome that can be reconciled to the run.

Worked example: an invoice-payment agent

A controller asks a planner agent to pay an approved invoice. The planner delegates validation to an accounts-payable agent, which reads the ERP invoice and vendor record. A separate treasury agent can submit the payment instruction.

The controller remains the subject. Each agent presents its own identity as actor. The planner can call the accounts-payable agent but cannot call the payment tool. The accounts-payable agent can read only invoices in the controller’s entity scope and returns a typed finding, not credentials. The treasury agent receives a delegation envelope limited to the invoice, amount, currency, beneficiary identifier, and expiry.

Before submission, the gateway verifies that the treasury agent and controller pair may reach the payment MCP server. A one-time approval binds the reviewer to the normalized payment instruction. The bank or treasury system independently verifies signing authority, sanctions status, duplicate-payment state, and current vendor details. If the call times out, the workflow checks the operation identifier before retrying. Completion is recorded only after the authoritative system reports the instruction’s committed status.

If the planner is prompt-injected by an invoice attachment, the attacker still faces independent boundaries: the planner lacks payment reach; the worker cannot expand the controller’s scope; the treasury agent receives bounded arguments; approval is specific; and the system of record enforces current rules. The model may still make a bad proposal, but the authority chain limits what that proposal can become.

Failure tests for the authority chain

• Lost subject: remove the human identity at an agent hop and verify the request fails rather than falling back to a shared superuser.
• Agent substitution: present the user token with an unregistered or unauthorized agent identity.
• Permission laundering: ask a low-privilege child to exercise a high-privilege parent’s reach.
• Wrong audience: present a token issued for another MCP resource and verify rejection.
• Stale approval: change material arguments or business state after approval and verify reauthorization.
• Ambiguous mutation: drop the response after commit and verify reconciliation prevents duplicate execution.
• Revoked subject: remove the user’s role during a long run and verify the next sensitive operation rechecks authority.

Identity establishes accountability; authorization bounds action

Agent identity is foundational because shared, anonymous automation cannot support precise policy or reconstruction. But the secure design target is larger: an end-to-end authority chain that preserves who requested the work, which workload acted, what was delegated, which resource was targeted, what a human approved, what current policy allowed, and what the authoritative system committed.

When those facts remain distinct, agent autonomy becomes governable. When they are flattened into one bearer token or one “approved agent” label, valid credentials can hide invalid authority. The engineering rule is simple even when implementation is not: authenticate every actor, attenuate delegation at every hop, and let the resource owner make the final business decision.

References

1. PwC — AI agents as workforce counterparts: what governance should look like.
2. NIST NCCoE — Draft concept paper on software and AI agent identity and authorization.
3. Model Context Protocol — Authorization security considerations, 2026-07-28.
4. TrueFoundry — Agent Identity (beta).
5. TrueFoundry — MCP Gateway Authentication and Security.
6. TrueFoundry — MCP Tool Approvals.
7. TrueFoundry — Logging Configuration.
8. TrueForge — SDK Concepts.

Editorial disclosure. This article reflects TrueFoundry’s engineering interpretation of the cited public materials as of September 13, 2026. Product capabilities are scoped to the linked documentation. Examples are illustrative, not legal advice, an audit opinion, an independent benchmark, or a guarantee of compliance or security.

‍