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. A security gap is wherever effective privilege, what the identity at a hop can reach, exceeds the requesting user's legitimate need.
Take a sandwich shop whose staff use an agent for shifts and bread orders. Its rota tool reads staff records, pay included. Its ordering tool calls the supplier. At each hop, ask two questions. Who does the downstream side believe is calling? What can that identity reach?
Stronger Login Does Not Narrow a Scope
Strengthening authentication (MFA, SSO) changes who can start a session. It does nothing about what an over-broad scope permits once the session exists. If the rota tool reads every staff record, MFA leaves that untouched. A shared credential, an admin key at a tool boundary and an agent that reads every record are authorisation gaps, fixed by scoping, identity propagation and credential separation.
The Confused Deputy
The classic gap is an agent serving many users through one over-privileged service account. Any user can then potentially reach anything the account can, such as the manager's pay. The agent is a confused deputy, exercising its privilege for users who should have less. The MCP security best-practices document names this attack class for proxy servers and mandates per-client consent.
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 counter assistant then sees only their own shifts. Done properly, the agent can never exceed the rights of the user it acts for. Every call also carries attribution into the audit trail as a side effect.
Secrets Never Meet the Model
Prompts are logged, cached and can be echoed back by the model, so treat a credential in model-visible context as published. A supplier key in the agent's system prompt is readable by anyone with the logs. Secrets belong in a secrets manager, injected at the tool boundary, scoped to the minimum resource and lifetime.
After a leak, the order matters: rotate the key immediately, then move the privileged call behind a backend the client cannot bypass. Rotation alone leaves the new key on the same leak path.
Token Passthrough Is Forbidden
Remote MCP servers authenticate via OAuth. Their authorisation model has each hop authenticate for itself. Token passthrough, accepting a client's token and forwarding it downstream, is a named anti-pattern the MCP specification explicitly forbids. It does four kinds of harm.
- It breaks audience validation.
- It destroys attribution, because downstream logs show the wrong identity.
- It circumvents rate limits and controls keyed to the token.
- It lets a stolen token travel.
Each hop gets its own scoped credential, so the shop's ordering server never forwards the manager's token.
Trace the Whole Chain
Scoping the agent's identity is cosmetic if a tool it calls still uses an admin credential. Effective privilege is measured at every hop. The analysis ends only when each hop has been asked the two questions.
Attribution Is an Architecture Decision
Every tool invocation should land in the audit trail with user attribution: who asked, which tool, which resource. Without it, incident response cannot tell one user's actions from another's behind a shared credential. Nobody can say who ordered the extra bread. One shared API key across users and environments is the worst case: no attribution, maximum blast radius on leak, and rotation breaks everything at once.
In the exam
The exam's favourite move dresses an authorisation gap as an authentication question and offers MFA. Telling the two apart dismantles most of this objective's distractors. Against the three authorisation gaps above, every login-strengthening option is a category error, however sensible in isolation. "Just forward the user's token" is planted as pragmatic simplicity and keyed as wrong. Options that secure one link while the stem's gap sits at another are hop-blindness distractors. Wiring attribution into monitoring is objective 3.4's job; designing it into the calls is this one's.
Exam Traps
Adding MFA or SSO when the stem describes an over-broad scope or shared credential
Login strength governs who gets a session; it does not narrow what the session can reach. The over-broad scope survives the stronger login untouched — an authentication fix planted on an authorisation gap.
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. The same category error as the audit-log distractor in objective 3.1.
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 keyed 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 is cosmetic 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 hide between hops. The drawing forces every link into view, 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 published — prompts are logged, cached, and echoable. The inventory catches the credential that took a shortcut.
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 and attribution and lets stolen tokens travel.
You should see: Per-hop confirmation of self-authentication, or a redesign note where a token was travelling.
- 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 earns its storage.
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