3.2 Authentication, Authorization & the Confused Deputy

Lesson 3.1 was about WHAT an agent can do — which tools sit on its keyring. This lesson is about WHO is holding the keyring, and whether they're allowed to use each key. Those are two genuinely different questions, and conflating them is the most common source of gaps in real integrations. Ask yourself, at a hotel front desk: the receptionist checks your ID (that's proving who you are), and separately decides which room key to hand you (that's deciding what you're allowed to access). A hotel that only ever did the first — checked IDs but handed every guest a master key — would feel obviously broken. Yet that's exactly the shape of a surprising number of production agent integrations.

Authentication answers "who is calling?" — proven with API keys, OAuth tokens, or service identities. Authorization answers a completely separate question: "what is that identity allowed to do?" You can have airtight authentication (every request is cryptographically verified) and still have a catastrophic authorization gap (the verified identity can touch data it has no business touching). The exam expects you to hold these apart cleanly, because most integration failures live in the gap between them — not in a missing password, but in a correctly-verified identity with the wrong scope.

Here's a subtlety that trips people up: authentication isn't a single gate at the front door of your system — it needs to happen at EVERY hop. Consider the chain: a user talks to your app, your app calls Claude, Claude requests a tool call, your code executes that tool call against a downstream service (a database, a payments API, an internal microservice). Each arrow in that chain is a separate call that needs its own verification. If you authenticate the user at the front door and then let every downstream hop trust whatever comes through unchallenged, you've built a system with one lock on a house that has five doors.

This matters concretely for tool implementations. When your code executes a tool on behalf of an agent, that execution should itself authenticate to the downstream service — with credentials appropriate to that specific call, not with a single all-powerful service account reused everywhere out of convenience. Reusing one broad credential across every hop is exactly the setup that produces the confused-deputy problem we'll get to next.

• •User → your app: authenticate the human (login, session, OAuth).
• •Your app → Claude: authenticate your application's API key/credentials.
• •Claude → tool execution: the model REQUESTS a tool call; your code decides whether and how to run it (recall Domain 1's model-proposes-code-disposes split).
• •Tool execution → downstream service: your code authenticates to the database, payments API, or internal service — every hop, not just the first one.

Now the pattern the exam cares about most in this task statement. Imagine an internal agent that helps employees look up customer records. To do its job across many customers, the agent's tool is configured with a broad SERVICE credential — one that can read and write ANY customer's record in the database. A given employee, on the other hand, is only entitled to see customers in their own territory. If the agent scopes its lookups only by what the SERVICE credential permits — which is everything — rather than by what the REQUESTING EMPLOYEE is entitled to see, the employee can ask the agent to pull up a customer outside their territory, and the agent, wielding its broad service credential, will happily do it.

This is the confused-deputy problem: an agent (the "deputy") acting with credentials more powerful than the user it serves gets tricked — or simply asked, with no malice at all — into using that power on the user's behalf, reaching data the user was never entitled to touch directly. The agent isn't hacked. Nothing is stolen through some exotic exploit. The agent is just doing exactly what it was configured to do, using a service credential that was never scoped to the person actually making the request. That's what makes it insidious: it looks like the system working correctly, right up until someone reaches something they shouldn't.

The fix follows directly from naming the problem correctly: scope tool permissions to the CALLING USER's entitlements, not the service account's broader credentials. The agent should never be able to do more on a user's behalf than that user could do by walking up to the system directly and trying it themselves. In practice this means passing the user's identity and entitlements THROUGH to the authorization check at the point of data access — not authorizing purely against the service account and trusting the agent to self-limit based on the user's request.

One more authn/authz hygiene point rounds out this lesson, and it's a simple rule that's nonetheless a frequent real-world failure: where do credentials physically LIVE? Secrets — API keys, database passwords, service tokens — belong in environment variables or a dedicated secret store. They must never be hard-coded into source, committed to version control, or — and this is the mistake specific to agentic systems — placed directly into a prompt or system prompt.

Why call out prompts specifically? Because it's an easy trap unique to this domain: an engineer debugging a tool integration pastes an API key straight into a system prompt "just to get it working," intending to fix it properly later. Now that key lives inside every request sent to the model provider, inside any logs that capture the prompt, and potentially inside any transcript a reviewer or eval pipeline stores. A secret in a prompt has quietly become a secret with a much larger blast radius than a secret in an environment variable ever had. This connects forward to Domain 5's data-handling and prompt-injection guardrails — a secret sitting in context is also a secret a sufficiently crafted injected instruction might get the model to repeat back.

You can now separate authentication from authorization, verify every hop rather than just the front door, recognize a confused-deputy setup even when it looks like normal operation, and spot secrets that have leaked into the wrong layer. An architect's job is to find these BEFORE the integration ships, not after an incident report.

With tools right-sized (3.1) and access correctly scoped to real identities (3.2), the agent is safe to connect to real data. The next lesson turns to the data itself: how do you design a retrieval pipeline so the agent actually finds the right information when it needs it?