How agents authenticate each other
When agents call other agents and tools on your behalf, 'it said it was the billing agent' is not security. Identity, authentication, scoped authorization, and delegation for multi-agent systems.
What you'll learn
- Why agent-to-agent trust needs verifiable identity, not a claimed name
- Authentication options — OAuth2 client credentials, mTLS, signed agent cards
- Scoped authorization, delegation (on-behalf-of), and the confused-deputy risk
Before you start
The moment agents start calling other agents and tools — over A2A, MCP, or plain HTTP — a security question appears that single-agent demos never face: how does one agent know it can trust another, and limit what that other agent is allowed to do? “The request said it came from the billing agent” is not an answer. This is real authentication and authorization, applied to non-human callers.
Three questions, in order
Every agent-to-agent (or agent-to-tool) call has to settle three things:
- Identity — who are you? A verifiable identifier, not a self-asserted name.
- Authentication — prove it. A cryptographic credential the callee can check.
- Authorization — what are you allowed to do? A scope that bounds the action, independent of who’s asking.
Before the diagram, predict it: an attacker tries two things — (a) a request that claims to be the billing agent but isn’t, and (b) a request from the genuine billing agent asking for something outside its job. Which gate stops each one?
The two failures are the whole lesson. A spoofed identity dies at verification — you can’t forge a signature from a trusted issuer. An over-scoped request dies at authorization even with a genuine identity — because least privilege bounds what a valid caller can do, which is your defense against a compromised or confused agent.
How authentication actually works
You don’t invent crypto — you use established machine-to-machine auth:
- OAuth 2.0 client credentials — the standard for service-to-service. The calling agent gets a short-lived access token from an authorization server and presents it; the callee validates issuer, signature, expiry, and scopes. MCP’s authorization spec is built on OAuth/OIDC.
- mTLS (mutual TLS) — both sides present certificates, so each cryptographically proves its identity at the transport layer. Common inside a service mesh.
- Signed agent identity (A2A) — agents publish an Agent Card describing their identity and capabilities; calls carry signed credentials so a peer can verify the card came from who it claims.
The common thread: a short-lived, signed, scoped credential — never a static “trust me, I’m the X agent” string.
Authorization and delegation
Identity tells you who; scopes tell you what. Grant each agent the minimum scopes it needs (least privilege) so a breach is contained. When an agent acts for a user, it should carry delegated authority — an on-behalf-of / token-exchange flow that narrows the user’s permissions to just this task — not the agent’s own god-mode credentials.
In one breath
- When agents call other agents or tools, “it said it was the billing agent” is not security — non-human callers need real authentication and authorization.
- Settle three questions in order: Identity (a verifiable ID, not a claimed name), Authentication (prove it with a cryptographic credential), Authorization (a scope bounding what even a valid caller may do).
- Use established machine auth — OAuth2 client credentials, mTLS, signed A2A agent cards — always a short-lived, signed, scoped token, never a static “trust me, I’m the X agent” string.
- Grant least-privilege scopes, and when acting for a user pass delegated (on-behalf-of) authority, not the agent’s god-mode credentials.
- The classic failure is the confused deputy — a low-privilege agent tricks a high-privilege one (often via prompt injection); defend by verifying identity per hop, passing scoped delegated tokens, and never letting content escalate privilege.
Quick check
Quick check
Next
Authentication is one slice of running agents safely in production. See agent security for prompt-injection and least-privilege, and observability to log and trace every inter-agent call.
Practice this in an interview
All questionsA confused deputy occurs when an agent uses its elevated permissions to perform an action on behalf of a less-privileged caller that the caller could not do directly, leading to privilege escalation. The root cause is that a trusted agent acts on natural-language requests, including from other agents, without verifying the originator's authority, so robust systems propagate identity and scope on every hop and enforce access control on agent-to-agent calls.
Keep raw credentials outside model context and traces. Let the model propose typed intent, authorize the final action and arguments deterministically, then have a trusted executor inject a short-lived, narrowly scoped, audience-restricted credential for one call. Re-authorize downstream and gate high-impact writes with explicit approval.
Key risks include prompt injection, especially indirect injection via tool or retrieval outputs, hijacking the agent, excessive tool permissions enabling damaging actions, data exfiltration, confused-deputy privilege escalation, and unbounded loops driving cost or harm. Mitigations include least-privilege tools, sandboxing, input and output guardrails, human-in-the-loop approval for sensitive actions, and audit logging.
An agent is an LLM placed in a loop where it reasons, chooses and calls tools or actions, observes the results, and repeats until a goal is met, rather than producing one response and stopping. The key differences are autonomy, tool use, memory and state, and multi-step control flow driven by the model's own decisions.