Per-Caller Identity and Credential Management in Multi-Agent Systems

An orchestrator agent delegates a task to a sub-agent. Every agent in that chain shares one credential, so after the fact nobody can say which agent started the cycle, as non-human principals retrieve data, hand off tasks, and combine results across boundaries that shift from one invocation to the next. It's not the same problem as prompt injection, and classical access-control models like RBAC, ABAC, and ReBAC don't cover it.

Credential sharing is the root error that produces that loop. A shared service key is the wrong identity model for this, and the loop scenario shows what that costs: no per-agent rate limit can trip, because there's no "per-agent" to measure against.

Three sub-problems define the space authority has to travel through as it propagates between agents. Every section that follows is really an answer to one of these three questions, because an identity model that doesn't address all three isn't a complete one.

Why service accounts and human sessions don't fit agents

The instinct to reach for an existing identity primitive, a service account or a human session, is understandable. Neither one fits an agent, and each fails in a specific, predictable way.

A traditional service account has a durable identity, rotating credentials, and a scope fixed to the workload's purpose. That's a complete answer when the question is "is this the billing batch job, and is it authorized to touch the billing tables?" It stops being a complete answer the moment one agent's scope needs to change from one invocation to the next. A coding-assistant agent might act on behalf of Alice for a refactoring task, then seconds later act on behalf of Bob for a deployment task, with the two tasks requiring completely different downstream access. Give the agent a long-lived service principal with broad permissions instead: every action it takes then appears to be the agent's own, with no record of which user's authority actually justified it.

The agent identity management literature names the practical cost of mixing either shortcut: a shared service account or a reused employee session folds several actors into one credential, and that makes later review ambiguous. If an agent borrows a broad human session, its effective permissions balloon past what the automation was supposed to accomplish.

Four agentic architectures are already in production, and each handles user authority differently: user-delegated, where the agent acts as the user with explicit consent; autonomous, where the agent carries its own standing identity; hybrid orchestrated, where one agent delegates to others; and scoped impersonation, where the agent acts as the user but only within a narrow slice of permission. The gaps between the models become exploitable seams when an organization mixes them without a clear policy for which architecture a given agent is supposed to fit.

Standing identity, delegation tokens, and the intersection rule

A correct model needs three parts, and leaving any one out reopens the gap the first two sections described. The agent needs a standing identity, its own principal that persists across invocations. It needs per-invocation delegation tokens that carry the context of whichever human authority it's currently acting under. And it needs an intersection rule that governs how those two things combine into the authority the agent actually exercises at the moment of the call.

The intersection rule carries the most weight. Skipping this rule produces a standard failure mode, because any system where agents inherit authority rather than intersect it will eventually let an agent do something neither its own baseline nor the delegating user's permissions would allow on their own.

The standing identity and the delegation token answer two different questions, and they need to stay two different things, tracked and verified separately. Put together, they form what amounts to a three-part authentication check on every action: the agent is authenticated as itself, the action gets attributed to both the agent and the delegating user, and the scope stays bounded to whatever the user actually consented to for that specific call.

Four places concentrate most of the operational risk this model has to manage: scopes granted too broadly to the agent's standing identity, token theft out of the agent's runtime memory, prompt injection that tricks an agent into misusing scopes it legitimately holds, and the plain difficulty of telling agent actions apart from user actions in the audit trail. A correctly built identity model has to address all four, because strength in three of them doesn't compensate for a gap in the fourth.

None of this holds together without a human on the other end of it. You need a named, accountable sponsor for every production agent, not just a technical identity record. When organizations run many agents, they tend to standardize a class of agent, assign it a sponsor, then spin up instances that inherit the class's baseline but keep their own distinct identities for attribution. That's the pattern that scales past a handful of agents into a fleet.

How delegation chains must propagate authority across agent hops

Every hop in a chain of delegating agents is a place where authority can go wrong in three different directions: it can amplify beyond what anyone intended, it can get cut off when it shouldn't be, or it can simply vanish without anyone noticing. Standard token-passing was built for simpler systems, so it doesn't handle any of the three by default.

Recent research proposes a specific mechanism for making chained delegation tractable: Invocation-Bound Capability Tokens, described in a paper (arXiv:2603.24775), which fuse identity, attenuated authorization, and a record of where the authority came from into one token chain that can only be appended to, never edited. The tokens come in two modes. A compact mode uses a signed JWT for the simple case, one agent calling one other agent. Because the chain is append-only, nothing earlier in it can be rewritten later to cover up what actually happened. This structure catches two specific attack patterns, a delegation depth violation and audit evasion through empty context, that a system running on unsigned tokens or plain JWTs has no way to detect.

The dominant failure mode in production multi-agent systems isn't one bad call slipping through. Depth limits, per-agent rate limits, and timeouts are what contain that, but all three require per-agent identity to enforce, because a rate limit means nothing if the system can't tell which agent is making the calls.

Authorization drift is the quieter failure because it needs no attacker. If you share a credential, you have nothing to check against, so the drift stays invisible until something downstream breaks.

Where per-agent identity lives in the agent runtime

Everything described so far, the intersection rule, the delegation chain, the drift detection, depends on identity being enforced where the agent actually executes, not just at the API's front door. A runtime that only checks identity at the boundary is too coarse and too late, because by the time a call reaches that boundary, the agent has already made the mid-execution decisions that determined what it's asking for.

Agentic AI introduces a genuinely new kind of coordination unit: a goal-directed entity whose execution path gets partially generated at runtime. Skipping this layer produces an agent that reads everything its index can reach and writes wherever its API key happens to allow.

A well-built agent runtime puts identity enforcement at the base: agents run in isolated sandboxes with per-agent IAM, connected to external systems through standardized adapters. The identity layer is the substrate the policy engine depends on, not a feature stacked on top of it afterward.

Amazon Bedrock AgentCore is a documented production example of this layered approach. Because it integrates with those providers along with Auth0, the model doesn't lock an organization into one identity provider at the inbound boundary.

Wood Mackenzie's deployment on AgentCore shows what this buys in practice. Without it, each new agent adds a case nobody can fully reason about.

What the emerging protocol stack provides for agent identity

Two protocols are becoming the de facto standards for how agents talk to each other and to their tools: MCP at the tool-calling layer, A2A at the agent-to-agent layer. Neither one prescribes an enterprise identity model, a policy graph, or an audit control plane, so authority, attribution, and scope still have to be designed separately, whichever protocol you adopt.

MCP's current posture leans on static secrets for most server authentication. A scan that identified roughly 1,862 MCP servers found that all 119 instances manually tested lacked authentication. That's consistent with the spec itself: authentication in MCP is optional, so a server can be fully compliant with the protocol and still be practically insecure. The 2026 MCP roadmap, published in March, lists enterprise readiness as a priority, including audit trails, SSO-integrated auth, and configuration portability, but a roadmap is a stated intention, not something already delivered. A July 2026 release went further and removed protocol-level sessions entirely, so much of what the industry had spent the previous year calling "MCP session security" needs rethinking.

A2A standardizes how agents discover each other through Agent Cards, how they exchange tasks and messages, and it declares authentication schemes. On AgentCore, A2A support adds enterprise authentication through SigV4 or OAuth 2.0, session isolation, and scalability on top of the standard protocol, which is a useful illustration that adopting a protocol and enforcing identity are two separate decisions an organization has to make, not one.

SPIFFE, the Secure Production Identity Framework for Everyone, a CNCF-graduated project that handles workload identity, underlies both protocols. That gives an agent a cryptographic identity that doesn't depend on a shared secret sitting in a config file somewhere.

Four questions every service in a multi-agent system needs to be able to answer still aren't answered by any single protocol or standard on its own: who is the agent, who authorized it, what is it allowed to do, and what is the scope of this particular delegation. Answering all four requires composing the runtime, the identity provider, and the protocol layer together. That's the right architecture for agent workflows spanning multiple organizations, but it's still early, and production implementations of the full composition are sparse.

Memory scoping as the extension of per-agent identity into persistent state

Identity enforcement at the call boundary means little if the memory layer behind it leaks across boundaries that were supposed to stay separate. Memory scoping determines what one caller's session can read from another's, so if a per-agent identity model gets authentication right but ignores memory, it has left half the problem unsolved.

Large language models carry no memory between API calls on their own. Memory has to be built explicitly, and that means every decision about what gets persisted, where it's stored, and who can read it back is an identity decision as much as it's an architecture decision. A single shared namespace across all four lets data cross boundaries that were supposed to keep it apart, the same way one shared credential did.

Multi-tenancy is the property that matters most here. That requires the memory layer to support scoped namespaces, at the user level, the organization level, or the session level, enforced by the same identity primitives that already govern tool calls elsewhere in the system.

A clear line also needs to separate what belongs in an agent's working memory from what belongs in durable system-of-record storage. Durable business state, orders, tickets, customer records, the outcome of a compliance check, belongs in a database that survives retries, crashes, and handoffs between agents, governed by the same authorization model that applies to everything else the agent touches.

Per-agent identity in a working multi-agent system

A correctly built per-agent identity model changes what's observable in a running system. Every action traces back to the agent that took it. Every hop in a delegation chain can be audited on its own. Any single agent can be suspended or have its access revoked without taking the rest of the fleet down with it.

Incident response is a useful test case for this. A documented reference architecture for multi-agent incident response uses dynamic agent discovery, pulling identity-provider configuration from a parameter store for each remote agent it talks to, and provisions OAuth 2.0 machine-to-machine authentication through distinct client applications for each agent in the chain: a WebSearch agent, a Monitoring agent, a Gateway agent, and a Host agent. Because each one has its own distinct identity, a compromised or misbehaving agent has its blast radius bounded to its own scope rather than spreading across the whole incident-response workflow.

Cox Automotive's deployment shows the same principle holding at scale. The company runs 17 production agents, each cataloged with its own capabilities and ownership, each running as its own principal, and every cross-agent handoff goes through A2A, with the receiving agent checking the calling agent's permissions before it acts. The catalog itself matters nearly as much as the runtime enforcement: knowing which agents exist, what each one owns, and who's accountable for it makes a meaningful authorization review possible.

The agent gateway is where much of this becomes a practical control plane. Per-agent identity is what makes that trace mean something, so it doesn't just read as a flat, undifferentiated list of calls.

What makes all of this composable is a runtime built for agents from the ground up: one that enforces per-agent identity at the execution layer, connects out to external systems through standardized adapters, and runs a policy engine on top of that identity substrate, rather than bolting identity controls onto general-purpose cloud infrastructure after the system is already running. You add per-agent identity from the start, because the rest of the architecture depends on that decision.