Federated Credentials and Per-Caller Identity for Agent Tool Calls

Federated credentials and per-caller identity are not a security add-on for AI agents. They are a first-principles infrastructure requirement, because agents cross multiple trust boundaries at runtime in ways that static machine identities and shared service accounts were never designed to handle.

Why AI agents don't fit the identity models built for humans or services

Enterprise identity infrastructure was built for two categories: human users and static service accounts. The same agent acts on behalf of different users at different times, with different scopes, in chains of delegation. Its scope changes per invocation, not per deployment.

Treating an agent as a service account fails at the delegation chain. An agent authentication has to answer a fundamentally different shape of question. Each question is necessary, and no service account model answers more than the first.

Early deployments fall into two failure modes. The second treats the agent as a human impersonation: the user's actual token is handed to the agent, which makes agent actions indistinguishable from human actions in the audit log. That token is also usable far beyond what the user authorized for the task.

Neither failure is theoretical. A majority of organizations run agents under one of these two broken models today, using shared or generic service accounts or delegated human user identities. Only a minority have established dedicated agent identities.

How an agent actually crosses trust boundaries during a single task

A single agent task routinely spans four or more authentication protocols at once. The gaps between those protocols are where security guarantees break down, not the protocols themselves. The agent authenticates to an LLM provider via API key, to an enterprise API via OAuth, to a cloud database via managed identity, and to a tool server via an MCP token. That is four credential types, four trust domains, and four validation requirements, all in one task.

Each protocol sits in a different tool. None has visibility into the others. The agent's full authentication surface exists nowhere as a single picture.

Static credentials compound the exposure. Google's SDK stores a token until the process terminates. The moment an agent starts, it holds long-lived secrets in memory across every LLM it connects to.

Scope creep follows from the protocol sprawl. When each protocol needs its own permission configuration, teams default to the broadest access that works everywhere. Organization-wide API keys replace scoped access, because fine-grained per-protocol permissioning is operationally unmanageable without purpose-built tooling.

The depth of the problem shows in agent-to-agent delegation. When one agent delegates a subtask to another, the identity chain can span three providers, three authentication methods, and three trust domains. An OpenAI-authenticated orchestrator delegates to a sub-agent authenticated by another vendor that then calls Salesforce APIs. No single audit system captures that complete delegation path.

The two-identity model as the architectural answer to the delegation problem

The durable answer is not a better secrets manager but a two-identity model with per-invocation delegation. Every tool call carries the agent's standing identity and the user's delegated authority as separate, composed facts. That is what makes the action attributable, auditable, and scope-bounded at the same time.

The model gives the agent its own standing identity, and it issues per-invocation delegation tokens that carry the user-authority context separately. The scope is bounded to what the user explicitly consented to for this specific invocation. Three discrete identity facts, one composed authentication ceremony.

Standing identity means each cataloged agent has a durable credential: a JWT-signing keypair, an mTLS certificate, a managed identity binding, or equivalent. It carries the agent identity as subject, the user identity as on-behalf-of, the narrowed scope, and a short expiration. The resource server validates the assertion and enforces the scope.

This resolves both failure modes from the opening section. The agent's own identity is visible in the audit log, not invisible behind a human token. And the user's delegated authority is bounded to what was consented, not broad service-account permissions.

The model accommodates four agentic deployment architectures, each with a different delegation shape. Hybrid orchestrated: one agent delegates to sub-agents, each needing both its own identity and the propagated user-authority context. Scoped impersonation: the agent acts as the user but only at narrow, pre-specified scopes.

One warning applies. The two-identity model does not self-enforce. Each agent's architecture must be declared, cataloged, and governed.

The protocol stack that implements per-invocation delegation

The protocol stack for per-caller identity is four standards that compose, not one. Standing credentials, per-invocation delegation tokens, on-behalf-of propagation across hops, and federated token exchange for third-party tools must work together as one ceremony. The standing credential layer gives each agent a durable identity: a JWT-signing keypair, an mTLS certificate, or a managed identity binding, rotated on a schedule and revocable from the catalog entry. Microsoft Entra Agent ID makes this concrete. Agent identities in Entra do not carry credentials of their own. They rely on the agent identity blueprint to acquire tokens, so a compromised agent cannot exfiltrate its own keys.

The per-invocation delegation token layer issues a JWT bearer assertion at invocation time. Where possible, the token is bound to the agent runtime context via DPoP or mTLS. That sender-constraining means a stolen token cannot be replayed from a different context.

The on-behalf-of propagation layer handles multi-hop delegation. OAuth 2.0 Token Exchange, RFC 8693, is the most common mechanism. Multi-hop orchestration remains the open hard problem: when an orchestrator decomposes a task and delegates sub-tasks to sub-agents, the delegation chain must hold end to end through an arbitrary number of hops.

Federated token exchange covers third-party tools. Workload identity federation lets a workload prove its identity in one environment and receive credentials in another via OIDC tokens rather than stored secrets. It does not address subsequent hops to Salesforce, GitHub, Slack, or other third-party services. Federated API token exchange extends the pattern beyond that: an agent obtains an access token from an external IdP without requiring the user to re-authenticate each time.

The MCP authorization layer adopted OAuth 2.1 with PKCE and resource indicators. The critical gap: authentication in MCP is optional, not required by the spec. Servers that skip it are technically compliant and practically insecure.

The four protocols compose into one logical flow. A JWT bearer assertion covers downstream API invocation. A standing agent identity token feeds audit logging.

Where production deployments break: the four operational failure points

Getting the protocols right is necessary but not sufficient. Production deployments fail at four operational pressure points that the protocol standards themselves do not resolve. Over-broad scopes are the first. In practice, teams default to the broadest scope that works everywhere, because dynamic agent access patterns make per-call permission configuration operationally expensive without a runtime that handles it automatically. A data analysis agent might determine it needs additional table access and attempt to escalate privileges, all without human authorization, across multiple protocol boundaries at once.

Token theft from agent runtime memory is the second. A compromised agent process exposes every credential it holds. Tokens bound to a specific runtime context cannot be replayed from a different one.

Prompt-injection attacks are the third, and they concentrate operational risk. It is instructed to act within its permissions by a crafted input. This is not protocol configuration. Audit-trail attribution failure is the fourth. RFC 8693's act claim provides the wire mechanism, but teams must actually log it. Credential rotation at scale adds a fifth pressure point. Static secrets distributed at deployment time persist in application memory, appear in configuration files, and compound as the agent estate grows.

What major platforms have shipped and where each one stops

The major cloud identity platforms have each shipped a production-grade piece of the per-caller identity model. Each covers a bounded surface, and the gaps between them are where teams building heterogeneous or cross-cloud agent estates assemble their own solutions. Microsoft Entra Agent ID reached general availability in April 2026. Credentials live in the agent identity blueprint, not on the agent instance, so a compromised agent cannot exfiltrate its own keys. For heterogeneous stacks, the governance surface extends beyond what a single IdP can cover.

AWS Bedrock AgentCore is AWS's managed runtime and toolset for building, deploying, and governing agents. It provides orchestration, memory store, and identity and permissions as managed building blocks, with persistent sessions up to 14 days and GPU-accelerated instance types. The scope: strong within the AWS ecosystem, with cross-cloud and cross-organization federation requiring additional work.

Google Vertex AI Agent Engine operationalizes per-agent identity principals secured by binding them to trusted runtime environments. Google Cloud's Workload Identity Federation handles federation from external OIDC and SAML issuers into GCP IAM. It is well-trodden for infrastructure workloads and extended to agent principals in this model.

The shared gap: each platform handles its own ecosystem's first hop well. None cleanly solves cross-organization, multi-hop delegation chains where an agent passes authority across organizational boundaries to a partner's agent infrastructure. The Cloud Security Alliance published the Agentic Trust Framework on February 2, 2026, the first governance specification applying Zero Trust principles to autonomous agents. The deployments lag them.

Why per-caller identity requires purpose-built agent infrastructure, not adapted cloud tooling

The per-caller identity pattern imposes requirements that general-purpose cloud IAM was not designed to satisfy and cannot be made to satisfy by configuration alone. Those requirements are runtime credential resolution, per-invocation policy evaluation, delegated context propagation, and cross-protocol audit. The core design mismatch is structural. Per-caller agent identity requires evaluating policy at tool invocation time for a composed identity: agent plus user plus delegation chain plus task context. That identity does not exist as a static entry in any directory.

Static machine identities run the same job in the same way, every single time. Agents are dynamic, crossing multiple trust domains as a matter of course. The infrastructure layer has to be designed for this dynamism, not adapted from infrastructure designed for the static case.

A purpose-built agent runtime must handle things adapted tooling cannot. The agent discovers what tool it needs at runtime, so the credential must be provisioned at runtime against a policy that accounts for the current user context. Per-action permission intersection means the user's delegated scope, the agent's standing permissions, and the task context are all evaluated together at the moment of tool execution, not independently or in sequence. Token vault isolation from the LLM context window is a hard requirement. Persistent session state that survives credential rotation means rotating a standing credential cannot break an in-flight long-running session.

A prototype can run on environment variables or a shared service account. The gap between prototype and production is not engineering effort. It is the absence of an infrastructure layer designed to provide these things.

The analogy that holds: the operating system is the layer that makes application code portable and safe across hardware. The agent runtime is the analogous layer for autonomous agents. It provides identity composition, credential lifecycle, and delegation propagation that agent code cannot sensibly re-implement per deployment.

Multi-tenant isolation is a concrete requirement. Not through direct API calls, not through tool invocations, not through the agent's memory stores. This enforcement must be consistent throughout the system, not just at the entry point.

What a production-grade per-caller identity implementation looks like end to end

A production-grade per-caller identity implementation is not a single configuration decision. It is a layered set of runtime behaviors, each addressing a specific failure point identified earlier, that together make the two-identity model operational. Runtime credential resolution happens at invocation time. Credentials are never passed into the LLM context window. The token vault stays isolated from the model's input and output surface.

For every tool call on behalf of a user, the IdP issues a short-lived JWT bearer assertion with a 5 to 15 minute expiration. It carries the agent subject, the user on-behalf-of claim, the narrow scope, and runtime binding via DPoP or mTLS where supported. The resource server validates the full assertion, not just the bearer token, and enforces the scope.

RFC 8693 Token Exchange runs at each hop. The orchestrator does not pass its own token to sub-agents. It issues delegation tokens bounded to the sub-agent's specific task.

Runtime guardrails sit at the runtime layer, not the application layer. Prompt-injection detection runs there, intercepting and evaluating tool call requests before executing them against credentials. Step-up approval applies risk-based policy that requires additional user confirmation before the runtime issues a delegation token for destructive or irreversible operations.

Long-running agent sessions, the kind that span multiple days on platforms like AgentCore, require that credential rotation not break in-flight work. Memory and context that persists across sessions must be scoped to the user identity that owns it. Cross-user or cross-tenant context leakage is a runtime enforcement responsibility, not an application responsibility.

These checkpoints evaluate whether an implementation is production-grade. Does credential rotation propagate to in-flight downstream connections? Is multi-tenant context isolation enforced throughout the system, at tool invocation, in memory stores, and in the audit trail?