Authentication, Authorization & the Confused Deputy
CoreAnalyze integrations for authentication and authorization gaps · Difficulty 3/5
Explanation
An architect analyzes every integration for authentication/authorization gaps before it ships. The two concepts are related but distinct, and conflating them is the most common source of gaps.
Authentication vs. Authorization
| Concept | Question it answers | Examples |
|---|---|---|
| Authentication | *Who* is calling? | API keys, OAuth, service identities |
| Authorization | *What* may that identity do? | Scoped tool/data access limited to role or entitlement |
Every request to Claude and to any downstream tool must be authenticated. Authorization then decides how far that authenticated identity is allowed to reach — tool access should be scoped so an agent can never read or mutate data the end user is not entitled to.
The Confused-Deputy Risk
The **Confused Deputy** pattern is the risk that matters most in agentic integrations: an agent acting with broad *service* credentials on behalf of a low-privilege *user* can leak or change data the user should not be able to touch. The fix is to scope tool permissions to the user's entitlements, not the service account's broader credentials — the agent should never be able to do more on the user's behalf than the user could do directly.
Secrets Management
Secrets live in environment variables or a secret store — never hard-coded, committed to version control, or placed directly in prompts (this last point connects to prompt-injection and data-handling guardrails covered elsewhere in the exam).
The Throughline
Least privilege runs through both authentication and authorization: authenticate every hop in the chain, and authorize each hop to the narrowest scope that still lets it do its job.
Key Takeaways
- Authentication proves identity; authorization scopes what that identity may do
- Confused deputy: an over-privileged agent acting on behalf of a low-privilege user can leak or mutate unauthorized data
- Scope tool permissions to the user's entitlements, not the service account's broader credentials
- Authenticate every hop: Claude to tool, and tool to downstream service
- Secrets belong in environment variables or a secret store — never hard-coded, committed, or placed in prompts
Glossary Terms
A client-declared filesystem scoping mechanism. The MCP client specifies which file:// URI paths (roots) a server may access. Servers declare which roots they need; clients grant a subset. Roots are a protocol-level declaration enforced by server compliance, not by OS sandboxing.
A security principle applied to agent tool design: give each agent and subagent only the minimum tools required to complete its specific task. Reduces blast radius if an agent is compromised or makes an error. Implemented via AgentDefinition tool lists and skill allowed-tools.
A security risk pattern in which an agent acting with broad service credentials on behalf of a low-privilege user can leak or change data the user should not be able to touch. The fix is to scope tool permissions to the calling user's entitlements rather than the service account's broader credentials, so the agent can never do more on the user's behalf than the user could do directly.
Related Concepts