Agentic AI · BraivIQ AI Engineering Playbook

Who Is This Agent And What May It Do? Agent Identity, Delegated Authorization And The 2026 Protocol Stack In Code

Every production agent eventually reaches the moment that decides whether it is safe: it is about to call a tool, an API or another agent, on behalf of a person, and the system on the other side has to answer two questions in microseconds - who is this agent, and what may it do? For two years most teams answered with a shared API key and hope. In 2026 that is over. Authorization was the story of Identiverse, a July IETF Internet-Draft set out an architecture for agent credentials, delegated user authority, workload identity and audit trails, Google published the open Agentic Resource Discovery specification, the OpenID Foundation formalised a dual-identity model in which an agent proves both who it is and whose authority it carries, and Microsoft's Agent Framework now scopes MCP sessions per invocation and authenticates every request to the correct identity. This flagship playbook, for senior engineers and architects, is the resulting protocol stack in code: discovery, workload identity, request authentication and delegated authorization as four distinct layers, the on-behalf-of chain preserved end to end, deterministic authorization before every tool call, and the permission-intersection rule that stops delegation becoming a way to launder privilege.

October 2, 2026 · 14 min read · By BraivIQ Engineering

4 layers - Discovery, workload identity, request authentication, delegated authorization - the stack that settled in 2026 · July 2026 - IETF Internet-Draft: agents are workloads that get cryptographic credentials at runtime and carry delegated authority separately · Dual identity - The OpenID Foundation model: prove who the agent is AND whose authority it carries, and stay identifiable as an agent · Per invocation - Microsoft's Agent Framework 1.19 scopes MCP sessions per call and authenticates each request to the correct identity and origin

There is a single moment in the life of every production agent that decides whether it is safe, and it is not the prompt, the model or the plan. It is the instant before a tool call. The agent is about to read a record, write to a system, send a message or ask another agent to act, on behalf of a person who may be asleep, and the system on the other side has to answer two questions in microseconds: who is this agent, and what may it do? For the first two years of the agent era most teams answered with a shared API key and hope - a service account with broad permissions that every agent used, identifiable as nothing in particular, able to do whatever the key allowed. In 2026 that era ended, and it ended because the industry converged, unusually fast, on an answer. Authorization was the story of Identiverse 2026. In July an IETF Internet-Draft set out an architecture for agent credentials, delegated user authority, workload identity, authorization and audit trails, proposing that agents are workloads that should receive cryptographic credentials at runtime, authenticate as themselves, carry delegated authority separately, and preserve both identities through the call chain. Google published the open Agentic Resource Discovery specification for finding and verifying agentic capabilities. The OpenID Foundation's framework for identity management for agentic AI argued for explicit on-behalf-of delegation in which an agent proves both who it is and what it is permitted to do while remaining identifiable as an agent, never impersonating the user. And Microsoft's Agent Framework 1.19 began scoping MCP sessions per invocation and authenticating every request to the correct identity and origin. As an AI Agency Developer London that builds agents which act on real systems for real clients, we think identity and authorization is the layer most teams are furthest behind on, and this flagship playbook is the stack in code.

Why A Shared Key Fails, Precisely: A shared service key answers neither question the system needs answered. It does not say which agent is calling, so every action is attributed to a faceless credential and nothing can be audited, rate-limited or revoked per agent. It does not say on whose behalf the call is made, so the agent acts with the key's full authority regardless of whether the person it serves could do the same thing - which means a user with read-only rights can, through the agent, do whatever the key permits. And it does not scope the authority to the task, so a compromised or manipulated agent - and prompt injection makes manipulation routine - wields everything the key can reach. The 2026 stack fixes all three by separating concerns that a shared key conflates: the agent's own identity, the user's delegated authority, and the specific permission for this specific action. Each is a different credential, issued by a different authority, checked at a different point, and together they are the difference between an agent you can let loose and one you cannot.

The Four Layers Of The Stack

The architecture that has settled is best understood as four layers, each answering one question, and conflating them is the root of most agent security failures. The first is discovery: how an agent finds and verifies the capabilities it may use. Google's Agentic Resource Discovery specification and the registries built on it let an agent locate a service's capabilities from a signed, verifiable catalogue rather than from whatever a web page happens to say - which matters because a capability an agent discovers from untrusted content is a capability an attacker can plant. The second is workload identity: how the agent proves it is the agent it claims to be. Here the stack borrows from service-mesh security that predates agents - WIMSE credentials, SPIFFE identities and the SVIDs that carry them, mutual TLS - so that a running agent is issued a short-lived cryptographic identity at startup by the platform, exactly as a microservice is, and presents it on every call. The third is request authentication: proving that a specific HTTP request genuinely came from that identity and was not replayed or tampered with, which is where Web Bot Auth and HTTP Message Signatures sit - the request itself is signed, so a receiver can verify the caller without a shared secret. The fourth is delegated authorization: what this agent may do, for which audience, on whose behalf - expressed as OAuth access tokens obtained through OAuth 2.1 with PKCE for browser-based agents, JWT bearer assertions for service-to-service flows, token exchange to convert a user's authority into a narrowly scoped token for the agent, and transaction tokens that bind a permission to a single operation. The layers compose: a discovered capability is called by an agent with a workload identity, in a signed request, carrying a delegated token that names the user, the audience and the scope. Remove any layer and a specific attack becomes possible. Keep all four and the receiver can answer both questions deterministically.

Discovery - locate capabilities from signed, verifiable registries (Agentic Resource Discovery), never from untrusted page content.
Workload identity - the agent is a workload: issued a short-lived SPIFFE/WIMSE identity at runtime, presented over mTLS, authenticating as itself.
Request authentication - every request signed (Web Bot Auth, HTTP Message Signatures) so receivers verify origin and integrity without shared secrets.
Delegated authorization - OAuth 2.1 with PKCE, token exchange and transaction tokens that say what the agent may do, for which audience, on whose behalf.
Preserve both identities - the agent's own and the delegating user's travel together through every hop of the call chain.

The On-Behalf-Of Chain And The Intersection Rule

The most important idea in the stack is the one the OpenID Foundation's framework makes explicit: an agent acting for a person carries two identities, and both must survive the whole chain. The agent authenticates as itself - so the receiver knows it is dealing with an agent, which agent, and can apply agent-specific policy - and it carries the user's delegated authority separately, as a token obtained through an explicit on-behalf-of flow rather than by borrowing the user's session. This is the opposite of impersonation, and the distinction is load-bearing: an agent that impersonates the user is invisible as an agent, inherits everything the user can do, and leaves an audit trail that says the user did it. An agent with dual identity is visible, scoped, and leaves a trail that says this agent, for this user, did this. The flow in code is token exchange: the user's authority is exchanged, by an authorization server that knows both parties, for a token scoped to the agent, the target audience and the specific permissions the task requires, with a short lifetime. When that agent delegates onward to another agent, the exchange happens again, and the chain of delegation is recorded in the token so that three hops later a receiver can see the originating user, every agent in between, and the narrowing of scope at each step. Which brings the rule that must never be violated: effective permission at any hop is the intersection of what the delegating party may do and what the receiving agent may do, never the union. Intersection means delegation can only narrow authority. Union means an agent with broad rights launders them to a caller that had none. The compositional authorization research of 2026 formalises exactly this - governance overlaid on delegation and scope - and the practical test for any agent platform is whether a low-privilege user can, through a chain of agents, cause an action they could not have taken themselves. If they can, the system has a union somewhere, and it is a breach waiting for a prompt.

Deterministic Authorization Before Every Tool Call

Identity and tokens establish what an agent may do in principle. The enforcement point is the instant before a tool call, and the research consensus of 2026 is that this check must be deterministic and must sit outside the model. The pattern - formalised as pre-action authorization - inserts a policy decision between the agent's intent and the tool's execution: the agent proposes a call (tool, arguments, target), a policy engine evaluates it against the agent's identity, the delegated scope, the target's rules and the context (what has already happened in this session, how consequential the action is), and only an explicit allow lets the call proceed. The evaluation is code, not a prompt: a model deciding whether it is allowed to do something is exactly the component an attacker manipulates, so the decision is taken by a policy layer the model cannot talk its way past. Consequential actions - money, deletion, external communication, permission changes - carry an additional gate requiring a transaction token bound to that specific operation or a human approval, so that even a fully authorised agent cannot perform them by accident or injection. And every decision, allowed or denied, is logged with the agent identity, the delegating user, the delegation chain, the proposed call and the policy that decided it, because the audit trail is both the forensic record and the evidence that governance was real. Microsoft's Agent Framework scoping MCP sessions per invocation is the same instinct at the transport layer: a session, a credential and a scope that exist only for this call, so there is no standing channel for a compromised agent to reuse. Short-lived everything - identities, tokens, sessions - is the quiet principle underneath the entire stack.

The failure modes this stack is designed to prevent: Four attacks define the threat model. Impersonation: an agent using the user's session acts with the user's full rights and leaves a trail blaming the user - prevented by dual identity and on-behalf-of tokens. Privilege laundering: a chain of agents in which authority grows at a hop - prevented by the intersection rule enforced in token exchange. Confused deputy via injection: an agent manipulated by content it reads into calling a tool it is technically allowed to call - prevented by deterministic pre-action authorization with consequence gates outside the model. And standing-credential compromise: a long-lived key or session stolen once and used indefinitely - prevented by runtime-issued, short-lived identities and per-invocation sessions. An agent platform that cannot explain how it stops each of these is not ready for agents that act.

The Bottom Line

The moment before a tool call is where agent safety is decided, and the two questions it poses - who is this agent, and what may it do - can no longer be answered with a shared key. In 2026 the industry converged on a stack that answers them deterministically: discovery from signed registries, workload identity issued at runtime through SPIFFE and WIMSE and presented over mTLS, request authentication through signed HTTP, and delegated authorization through OAuth 2.1, token exchange and transaction tokens that name the agent, the audience, the scope and the user - with both the agent's identity and the user's authority preserved through every hop of the chain, as the IETF draft and the OpenID Foundation's dual-identity model prescribe. The rule that holds it together is intersection, never union: delegation can only narrow authority. The enforcement point is a deterministic policy check before every tool call, outside the model, with consequence gates and a complete audit trail, and the quiet principle underneath is that everything - identities, tokens, sessions - is short-lived and scoped to the invocation, exactly as Microsoft's framework now does for MCP. Build this and you can let agents act on real systems on real people's behalf. Skip it and you are one prompt injection from an agent doing something nobody authorised, attributed to someone who did not do it. Building agents on this stack is exactly the work we do.

References & Further Reading

DEV Community - AI agent authentication in 2026: Web Bot Auth, ARD and OAuth (the four-layer stack, the July 2026 IETF draft): https://dev.to/webdecoy/ai-agent-authentication-in-2026-web-bot-auth-ard-oauth-247
Cerbos - Identiverse 2026: agents made authorization the story: https://www.cerbos.dev/blog/identiverse-2026
DEV Community (Arcade) - how to manage multi-user AI agent authentication and authorization in 2026 (OAuth 2.1, OIDC, delegated access): https://dev.to/arcade/how-to-manage-multi-user-ai-agent-authentication-and-authorization-in-2026-oauth-21-oidc-and-2943
arXiv - before the tool call: deterministic pre-action authorization for autonomous AI agents: https://arxiv.org/pdf/2603.20953
Cloud Security Alliance - Agent Identity Governance Framework v1: https://labs.cloudsecurityalliance.org/agentic/agentic-identity-governance-framework-v1/