An agent that can reach company systems creates an identity problem that ordinary application architectures can often postpone. A user asks for a report. The agent chooses a tool. A gateway routes the request. A service in another account reads data and performs an action. At each hop, something needs to answer a deceptively basic question: who is calling?

“Alex asked for it” is not enough. The downstream service also needs to know whether the request came through the approved agent gateway, which runtime is executing it, and whether that runtime is entitled to act for Alex in this particular context. If all it sees is a shared API key, the whole path collapses into one indistinguishable principal.

That is the problem Workload identity federation addresses. It is an architecture for establishing, carrying, and checking the identities of software workloads across accounts, trust domains, or organizational boundaries. In an agent system, it usually keeps three facts separate: the initiating user, the workload doing the work, and any gateway that delegated or routed the call.

Plain English: A downstream tool should not have to trust a request merely because it contains a user token or knows one shared secret. It should be able to verify which services handled the request and whether that route is allowed.

Why this matters now

Agent platforms tend to centralize the part users see: a chat surface, a coding agent, or a gateway that discovers tools. The data and business operations they need, however, are usually decentralized. Finance, support, and engineering may each own separate accounts, services, policies, and records. Copying everything into one agent account is often unacceptable. Giving a central agent broad, permanent access to every account is not much better.

AWS’s September 24 reference architecture makes the alternative concrete. It keeps line-of-business data in separate AWS accounts, exposes selected tools through MCP servers, and presents those capabilities to an agent through a central AgentCore Gateway. AWS’s architecture is an implementation pattern, not a universal standard, but it describes the right architectural tension: central discovery and policy without central ownership of all data.

MCP, the Model Context Protocol, is relevant because it gives agents a way to discover and invoke tools. It does not, by itself, settle multi-hop identity, delegated authority, or cross-account authorization. Those concerns must be deliberately composed from the MCP implementation, an identity system, and policy enforcement.

The shift is broader than a single cloud design. Databricks announced its Unity Gateway CLI on September 24 as a central place to configure approved coding agents, models, MCP servers, Skills, routing, and spending policies. It also describes centralized tracing for local tool calls and Skill invocations. Databricks’ announcement shows why a gateway is becoming a control point. But a control point is only trustworthy if downstream systems can distinguish traffic that passed through it from traffic that bypassed it.

The identity facts in one request

Start by separating identities that are often mashed into one token.

The user identity says which human or application principal initiated the work. It is the useful input for questions such as “may this employee view this customer record?”

The workload identity says which running service made a network call: for example, agent-runtime, policy-gateway, or billing-mcp-server. It is useful for questions such as “is this a production gateway from the expected environment?” SPIFFE, a set of specifications for service identity, models this with short-lived cryptographic credentials called SVIDs, issued to workloads. An SVID can be an X.509 certificate or a JWT. SPIFFE’s concepts documentation explains the model.

The delegation path says who is exercising authority on whose behalf. This is different from merely forwarding the user’s credential. OAuth 2.0 token exchange defines impersonation and delegation semantics, including an actor claim for identifying a party exercising authority in a chain. RFC 8693 defines those semantics.

These are related mechanisms, not synonyms. A workload credential identifies a service. A user token identifies an initiating principal. Token exchange can express a delegated relationship. A secure design commonly needs all three.

Plain English: “The user is allowed” and “this service is allowed to call” are separate checks. An agent system is safer when it can make both instead of treating a user token as permission for every machine in the path.

How the pattern works, step by step

Consider a central agent that can query a finance tool and a support tool, each owned by a different account.

First, assign each participating runtime a verifiable identity. Avoid treating a shared secret as the identity of the entire request path. The gateway needs its own identity; so does the agent runtime and each downstream service. The credential should be issued, rotated, and validated by a mechanism appropriate to the environment. That is credential lifecycle management—but lifecycle management alone does not tell a recipient what the credential means or which trust domain issued it.

Second, authenticate the user independently. In AWS’s documented example, the agent forwards the user’s JWT to the gateway for user-level policy evaluation. The gateway then obtains separate OAuth 2.0 machine-to-machine credentials for outbound calls to line-of-business MCP servers. AWS’s architecture is valuable precisely because it avoids pretending that the user token and the gateway’s machine credential serve the same purpose.

Third, make an explicit authorization decision at the gateway. A policy enforcement point is the component that evaluates and applies access rules at a boundary. At this point, policy can combine user claims, requested tool, tenant, environment, and operation. It can decide whether the user may invoke finance.invoice.lookup, not merely whether the agent can reach a finance endpoint.

Fourth, authenticate the next hop as a workload. The finance MCP server should validate the credential presented by the gateway. If federation crosses trust domains, recipients need a configured basis for trusting foreign issuers. In SPIFFE federation, trust domains exchange foreign trust bundles so workloads can validate identities issued elsewhere. SPIFFE federation is one model for this cross-domain trust problem.

Fifth, enforce local authorization too. The data-owning service retains control over its own tool logic, data access, and business rules. AWS describes the central gateway evaluating user claims and tool actions while line-of-business MCP servers authenticate inbound tokens and retain control of their local behavior. The AWS reference architecture therefore has layered authorization, not a single all-powerful gateway decision.

Finally, reject bypass paths. Positive controls say what is allowed. Negative controls say what must not happen. AWS documents allowedWorkloadConfiguration, which can restrict a runtime to requests whose identity chain includes an approved AgentCore Gateway. That reduces the chance that a caller invokes the runtime directly and skips gateway policy. AWS’s authentication guidance and security guidance describe this control.

Plain English: Do not just let the gateway in. Configure the downstream service to refuse calls that did not come through the gateway when the gateway is part of your security design.

What it is not

Workload identity federation is not network segmentation. Network controls can limit who can connect, but they do not cryptographically prove which workload made a request or that it passed through an approved intermediary.

It is not capability mediation, either. Capability mediation limits which tools or actions an agent may use. Federated identity provides authenticated principals and call-path information on which those decisions can rely. You need both: a real identity does not make every tool call appropriate.

Nor is it a guarantee that an agent made a good decision. A model can misunderstand the user, follow malicious content in a document, or select a harmful but technically authorized action. Identity proves provenance and constrains access; semantic authorization, business rules, approvals, and Guardrails still decide whether the requested operation is sensible.

A practical example: a cross-account incident assistant

Imagine an incident assistant used by operations engineers. It can read service health from the production account, customer impact from a support account, and billing status from a finance account. The assistant should summarize evidence but must not issue refunds or alter production resources merely because a user asks in a chat.

A workable design starts with narrow MCP tools. The support server exposes a read-only case lookup. The production server exposes status and recent deployment information. The finance server exposes an invoice-status lookup, not a generic database query.

When an engineer asks a question, the agent sends the user context to the gateway. The gateway verifies the user’s claims and chooses whether the relevant tool is permitted. It then calls a destination MCP server with its own machine credential. The destination verifies that credential, recognizes the gateway as an approved workload, and enforces its local rule: perhaps only on-call engineers can read account-specific details, and no tool in this Workflow can mutate data.

The key point is that an attacker cannot gain the same route merely by discovering the support server endpoint. If the server requires an approved identity chain containing the gateway, a direct call is rejected. The user’s authorization, the gateway’s identity, and the service’s own policy all have to line up.

This is also operationally useful. An audit record can distinguish “the user requested this lookup,” “the gateway authorized this tool,” and “the finance service returned this result.” Those are materially better debugging and incident-response facts than “the shared agent credential called finance.”

Where it breaks

The most common mistake is confusing a valid credential with a complete authorization decision. A correctly authenticated gateway can still become a confused deputy: it has broad authority and is tricked into applying it for the wrong user, target, or action. Policies need to bind the user, workload, target service, intended operation, tenant, and delegation context together.

Forwarding user tokens also expands the blast radius of leakage. Check audience, scope, expiry, and replay behavior. Avoid logging raw credentials. Treat a token passed through several services as a security-sensitive asset, not harmless request metadata.

Federation adds operational work. Foreign issuers or trust bundles must be onboarded; keys rotate; clocks drift; issuers become unavailable; and revocation behavior must be understood before an incident. A system that only works while every issuer is reachable may fail in precisely the outage where the agent is supposed to help.

Portability is another limit. Different cloud platforms and identity providers expose different chain and delegation semantics. AWS’s allowed-workload feature is useful evidence of the pattern, not a portable contract every MCP host implements. Define the security properties you require first, then map them to each platform’s mechanisms.

What you can do this week

Start with a call-path inventory for one agent workflow. For every hop, write down: initiating user, calling workload, receiving workload, credential presented, issuer, audience, delegated authority, and policy decision. If your diagram has only arrows and API keys, it is not yet an identity design.

Choose one sensitive downstream tool and make bypass prevention testable. Attempt the approved path through the gateway and an otherwise identical direct call. The latter should fail for a specific, observable identity or authorization reason.

Then separate policy ownership. Put broad tool discovery and cross-domain routing at the platform boundary, but retain local business authorization with the service that owns the data. This reduces the chance that a central platform team accidentally becomes the permanent author of every domain rule.

Finally, add evaluation cases for identity failures alongside normal agent Evaluations: expired credentials, wrong audience, unknown issuer, missing gateway in the chain, user authorized for one tool but not another, and direct service invocation. Agent reliability is not only about whether the model chose a plausible tool. It is also about whether every service can prove that the request arrived by an authorized route.