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.
Run the handshake and watch where each scenario fails:
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.
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.
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.
Tool calling extends the LLM's output space to include structured function invocations. The model emits a JSON object naming a tool and its arguments; the runtime executes the tool and feeds the result back as a new message. An agent is a loop that repeats this cycle — observe, think, act — until the task is complete or a stopping condition is met.