IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
Agent-to-agent delegation
Maya asks Kai to book a trip. Kai asks Sam's partner agent. That agent calls a third service to reserve the room. Maya allowed the first agent. Did she allow the third? Your goal: keep Maya's consent exact as machines pass the task to machines.
- A delegation chain is a request passed through several agents.
- Each hop gets a new token. The user stays the subject.
- The act chain names every agent. Scope only shrinks.
- A bigger job than Maya allowed needs a new approval.
The chain, and how it goes wrong
A delegation chain is a request that passes through several agents, each acting for the one before. The danger is authority amplification. At each hop, the permissions can quietly grow, or the system forgets who the action is for. By the third machine, "Maya wanted a room under ₹5,000" has become "some agent is spending freely on Maya's account".
Maya tells Kai, "Book something nice, up to ₹5,000." Kai hands the task to Sam's travel agent. That agent hands it to a hotel-booking service. If each hop just says "Maya's agent said so", the booking service never learns about the ₹5,000 cap. Maya's consent has disappeared.
A kirana shop's credit book. Maya tells the owner, "My driver may take goods on my khata, up to ₹500." The driver may take less. The driver cannot write a bigger number than Maya allowed. Every line in the book names Maya and who took the goods.
Doing it right: tokens that narrow and name everyone
The clean pattern is token exchange at every hop. Delegation across services explains it. Each agent trades the token it received for a new token for the next service. The authorization server checks the rules each time. Two rules keep it safe:
🧾 Attributable
Every token records the original user and the acting agents. sub stays Maya. An act chain grows. Real tokens nest one act inside another, with the newest actor on the outside. Here we write it as a list: [Kai, Sam-agent]. Any service can see the real requester and every delegate. Nobody acts as Maya. They act for her.
📉 Narrowing only
Scope shrinks down the chain and never grows. "read-calendar, book-travel, spend≤₹5,000" can become "book-travel, spend≤₹3,000". A hop that tries to add a scope or raise the cap is refused.
Consent boundaries and the confused deputy
Maya approved a task, not unlimited calls further down. When a hop wants something bigger than the original request, that is a new decision. Pause and ask a person, using human-in-the-loop approvals. This is human-in-the-loop control. It also defuses the classic confused deputy: tricking a more powerful agent into using its authority for you. The token carries Maya's real rights and the full act chain. So a downstream agent can never do more for a requester than that requester could do alone. (For the same trap across company or cloud borders, see cross-account and cross-cloud trust.)
A chain of agents is only as trustworthy as its weakest hop. Give each agent its own identity in an agent registry. Keep the original user and every delegate in the token. Let scope move one way only. Then "Who authorized this?" always has a full answer.
Go deeper: The A2A protocol (October 2026)
A2A (Agent2Agent) is an open protocol that lets agents from different vendors work together. MCP connects an agent to tools. A2A connects an agent to another agent. It moved to the Linux Foundation in 2025. Version 1.0 came out in March 2026. In August 2026 it joined the Agentic AI Foundation, which also hosts MCP.
- An A2A server publishes an Agent Card. It is a JSON file. It says who the agent is, what it can do and how to sign in.
- The card lists the sign-in methods it accepts: API key, HTTP authentication, OAuth 2.0, OpenID Connect or mutual TLS. A server must reject requests with missing or invalid credentials.
- Version 1.0 added signed Agent Cards, so a client can check who published a card.
- A2A is the road between agents. It does not decide whether Kai may spend Maya's money. The token pattern above does that.
- The token exchange for each hop is RFC 8693.
Sources: a2a-protocol.org and aaif.io.
🧪 Interactive lab — enable JavaScript to play with this one.
Grade a partner agent's declared sign-in methods with A2A Scan. Build a narrowing token with the Token Exchange explainer.