Agent-to-Agent Authorization: Deciding What a Delegated Agent May Do Before It Calls the Next Model

When an orchestrator agent asks a research agent to pull a customer file and summarize it through an LLM, three HTTP calls leave your environment, and each one is authenticated with a credential that says which agent is calling. Authentication answers who is calling, and authorization answers a harder question the same call rarely carries: whether this agent, acting for this user, is permitted to send this data to this model for this purpose right now. A stack that authenticates its agents and stops there hands each delegated agent the full reach of whatever token it holds. I want to walk the authorization decision on agent-to-agent traffic, the delegated-authority requirement behind it, and where the decision has to sit to actually hold.

Authentication and authorization on agent traffic

Agent-to-agent authentication has matured, and mutual TLS, signed tokens, and workload identity now let one agent prove to another which service it is, work covered in agent-to-agent authentication and agent-to-agent TLS. Authorization is the separate decision that runs after identity is established. The authenticated research agent still needs a verdict on the specific action it is about to take. A valid identity is the ticket to the building. Authorization is the lock on each individual door, and agent stacks that ship the ticket without the locks give a compromised or confused agent a wide hallway.

The delegated-authority problem

The core issue with agent chains is that authority gets inherited instead of scoped. NIST's AI agent identity and authorization work frames this as delegated authority: an agent acting for a user should carry that user permissions for that task, bounded to what the task needs, and no more. The NIST NCCoE comment window on the software and AI agent identity and authorization project closed April 2, 2026 per the NCCoE. In practice, most orchestration frameworks give the sub-agent a static service credential with permanent access to the full model API. A research agent that only needs to summarize public filings holds the same reach as one cleared for customer records, because the credential was provisioned once for the service and never narrowed per request. Static service credentials violate least privilege by design.

Where the authorization decision has to sit

An authorization decision that lives inside the calling agent is self-attestation. The agent decides it is allowed, acts, and logs its own choice. Independent authorization has to sit on the traffic between agents, on the path the HTTP calls actually take, where a policy decision point can evaluate each request against the delegated identity and the data in it before the call proceeds. A raw sub-agent call looks like this:

An enforcement layer reads the delegated identity from the request, classifies the content, checks whether user-482 permissions plus this agent role allow this data to reach this model, and returns a verdict before the model is reached:

Action lineage: the record the chain has to leave

Authorization is only half the requirement. The other half is action lineage, a structured record of who authorized this action, under which policy, at what moment, with what outcome, for every hop in the chain. When the orchestrator, the research agent, and the model call each pass through the same enforcement point, the lineage reconstructs the whole chain from independent records rather than from each agent's account of itself. A regulator asking what an agentic system did with a specific customer record on a specific day gets an answer assembled from the traffic, not from the agents that would each prefer to say it went fine. Related enforcement on tool calls is covered in MCP tool call authorization.

Compliance framing

Agent chains do not get a lighter audit standard because the actor is software. EU AI Act Article 12 requires automatic, traceable event logging for high-risk systems, including inputs and the natural persons involved, applying from August 2, 2026 per the European Commission. For an agentic system, the natural person involved is the user the chain acts for, and the traceable record has to bind that person to each delegated action. Application logs written by the agents fail this, because they lack the delegated identity and the policy state, and because the system under audit is writing its own account. My blunt take: any agent framework that logs its own decisions and calls that an audit trail is selling you a diary, not evidence.

DeepInspect

This is the gap DeepInspect closes. DeepInspect is a stateless proxy that sits inline on the traffic between your agents and the models and tools they call, and it is model-agnostic, so one layer covers OpenAI, Anthropic, Bedrock, Vertex, and self-hosted endpoints. For every request it reads the delegated identity the application supplies, classifies the data in the prompt, evaluates whether that identity and agent role are permitted this action under policy, and returns a pass or block decision before the call reaches the model. Enforcement adds under 50 milliseconds in internal testing, and the default on ambiguity is deny.

For every decision it commits an identity-bound record before the response returns, written independently of the agents. Across a chain, those records reconstruct the action lineage that no single agent could attest to on its own. DeepInspect requires the delegated identity to be supplied by the application, which is the upstream agent-identity responsibility, and it enforces and records everything downstream of that. Let's talk today.