What You Need to Know
Authentication answers who is calling. Authorisation answers what may they do. A request passes from the user to the client, the agent, its tools and the downstream systems they reach. Each step is a hop. Effective privilege is what the identity at a hop can reach. A security gap is wherever effective privilege exceeds the legitimate need of the user who makes the request.
This lesson uses one made-up example throughout: an airline whose staff use an agent for shifts and spare-part orders. Its scheduling tool reads staff records, and these records include pay. Its ordering tool calls the parts supplier. At each hop, ask two questions. Who does the downstream system believe is calling? What can that identity reach?
Stronger Login Does Not Narrow a Scope
Stronger authentication (MFA, SSO) changes who can start a session. It does not change what an over-broad scope permits once the session exists. If the scheduling tool reads every staff record, MFA does not change that. A shared credential, an admin key at a tool boundary and an agent that reads every record are authorisation gaps. Scoping, identity propagation (tool calls carry the authenticated user's identity) and credential separation fix them.
The Confused Deputy
The classic gap is an agent that serves many users through one over-privileged service account (an account for software, not for a person). Any user can then potentially reach anything that the account can reach, such as a manager's pay. The agent is a confused deputy: it uses its privilege for users who should have less. The MCP security best-practices document names this attack class for proxy servers (servers that pass requests on to another service). It requires per-client consent: the user approves each client separately.
The architectural fix is identity propagation. Tool calls carry the authenticated user's identity, and every read or write is scoped to what that user may legitimately reach. A member of the check-in staff then sees only their own shifts. When identity propagation is done properly, the agent can never exceed the rights of the user that it acts for. As a side effect, every call also carries attribution into the audit trail.
Secrets Never Meet the Model
Prompts are logged and cached, and the model can repeat them in its output. So treat a credential in context that the model can see as public. Anyone who has the logs can read a supplier key in the agent's system prompt. Secrets belong in a secrets manager, a system that stores credentials and controls who can read them. Inject each secret at the tool boundary, and scope it to the minimum resource and lifetime.
After a leak, the order matters: rotate the key immediately, then move the privileged call behind a backend that the client cannot bypass. Rotation alone leaves the new key exposed to the same leak path.
Token Passthrough Is Forbidden
Remote MCP servers authenticate with OAuth. In their authorisation model, each hop authenticates for itself. Token passthrough means accepting a client's token and forwarding it downstream. It is a named anti-pattern, and the MCP specification explicitly forbids it. It does four kinds of harm.
- It breaks audience validation (the check that a token was issued to this server).
- It destroys attribution, because downstream logs show the wrong identity.
- It circumvents rate limits and controls tied to the token.
- It lets a stolen token pass downstream.
Each hop gets its own scoped credential, so the airline's ordering server never forwards a manager's token.
Trace the Whole Chain
Scoping the agent's identity has no real effect if a tool that it calls still uses an admin credential. Effective privilege is measured at every hop. The analysis ends only when you have asked the two questions at each hop.
Attribution Is an Architecture Decision
Every tool call should appear in the audit trail with user attribution: who asked, which tool, which resource. Without attribution, incident response cannot distinguish one user's actions from another's when users share a credential. Nobody can say who placed a duplicate parts order. One API key shared across users and environments is the worst case. It gives no attribution and the maximum blast radius on a leak. Rotating the key breaks everything at once.
In the exam
The exam's favourite pattern presents an authorisation gap as an authentication question and offers MFA. If you distinguish the two, you remove most of the wrong options on this objective. For the three authorisation gaps above, every option that strengthens login fixes the wrong kind of problem, however sensible it is in isolation. The exam offers "Just forward the user's token" as a simple, practical choice, and it is a wrong answer. An option that secures one hop while the question's gap is at another hop is a wrong option. Objective 3.4 covers connecting attribution to monitoring. This objective covers designing attribution into the calls.
Exam Traps
Adding MFA or SSO when the scenario describes an over-broad scope or shared credential
Login strength governs who gets a session, not what the session can reach. A stronger login leaves an over-broad scope unchanged. Narrow the scope, propagate the requesting user's identity, or separate the shared credential.
Logging all agent calls as the fix for a structural privilege problem
A detective control: it records cross-user reads after they happen rather than making them impossible. Propagate the requester's identity and scope each read to their own records.
Forwarding the user's token downstream because it keeps the design simple
Token passthrough is explicitly forbidden by the MCP specification: it breaks audience validation, corrupts attribution, bypasses controls tied to the token, and lets stolen tokens travel. Each hop authenticates for itself with its own scoped credential.
Securing the client-to-agent link when the gap sits at the agent-to-downstream hop
Effective privilege is measured at every hop. An admin credential at the tool boundary is the gap, and agent-level scoping has no real effect while the tool can still reach everything. Trace the whole identity chain before choosing.
Practice Scenario
A customer-service agent answers account questions for any customer who authenticates to the web app. The agent calls an internal accounts API using a single service credential with read access to ALL customer records. A security review asks what is wrong with this design. Which change addresses the actual gap?
Build Exercise
Identity-Chain Map, Hop by Hop
What you'll learn
- How to draw the full identity chain of an agent integration
- How to spot the hop where effective privilege exceeds user need
- Where credentials belong, how they are scoped, and what a leak response looks like
- How to verify per-hop authentication and per-call attribution
- Pick an agent integration and draw every hop: user to client, client to agent, agent to each tool, each tool to its downstream system
Why: Security gaps between hops are easy to miss. The drawing shows every link, including the ones nobody owns.
You should see: A chain diagram with an arrow per hop and the calling identity labelled on each arrow.
- At each hop, write who the downstream side believes is calling and what that identity can reach; flag every hop where effective privilege exceeds the requesting user need
Why: This is the two-question method the exam expects: who is calling, and what may they do. The flagged hops are your findings.
You should see: A privilege annotation per hop, with at least the over-broad hops flagged in red.
- Locate every credential: where it is stored, its scope, its lifetime, and whether it ever appears in model-visible context
Why: A key in a prompt is exposed — prompts are logged and cached, and the model can repeat them. The inventory finds the credential that was placed in a prompt.
You should see: A credential table: store, scope, lifetime, and a model-visible column that reads no in every row.
- Check the remote hops: does each hop authenticate for itself, or is any token being passed through? Fix any passthrough with per-hop scoped credentials
Why: Token passthrough is a named, forbidden anti-pattern: it breaks audience validation (the check that a token was issued to this server) and attribution and lets stolen tokens pass downstream.
You should see: Per-hop confirmation of self-authentication, or a redesign note where a token was passed through.
- Verify each tool invocation lands in the audit trail with user attribution, then write the incident-response question the trail must be able to answer
Why: An audit trail that only shows the service account cannot answer who did what. Writing the question first tests whether the trail is useful enough to store.
You should see: A sample trail entry naming user, tool, and resource — and one incident question it demonstrably answers.
Sources
- MCP Security Best Practices — Model Context Protocol
- MCP Transports — Model Context Protocol
- Claude Certified Architect Professional Exam Guide (v1.0) — Domain 3 — Anthropic