3.2 · Lesson 2 of 8

Analyze authentication and authorization requirements to identify security gaps

What You Need to Know

Integration security for Claude systems fails most often at the seam between identity and permission. Authentication (AuthN) answers who or what is calling. Authorization (AuthZ) answers what that caller may do to which resource. Agents compound the problem: a human may be AuthN'd in the UI while the tool executes under a broad service principal, or the model may invent resource identifiers that the backend never re-checks.

Architects must treat every tool as an API with a policy. Least privilege means each agent and credential gets only the actions required for its role. Escalation paths should fail closed when the principal lacks access — not improvise with a more powerful fallback key.

Common gap patterns

UI AuthN without tool-path AuthZ
Shared high-privilege service accounts across agents
Trusting model-supplied IDs without binding to verified session context
Prompts used as the only control for irreversible actions

Decision rules

Separate AuthN from AuthZ on every diagram and review checklist.
Enforce AuthZ in the tool adapter or target API — never only in the prompt.
Scope credentials to tenant, action, and blast-radius limits.
Bind mutable actions to verified case/session context, not free-form identifiers.
Fail closed and escalate when permission is missing; do not swap in a broader key.

Where gaps hide in Claude systems

Gaps appear at seams: the chat UI authenticates a human, the gateway forwards a request, the model proposes a tool call, and the adapter executes under a service identity. If any seam trusts the previous one without re-checking permission for the specific resource and action, you have an AuthZ hole. Prompt-injection and confused-deputy scenarios exploit exactly those seams.

Control placement

Gateway: authenticate the caller and attach a verified context object
Tool adapter: authorize action × resource against that context
Downstream API: enforce tenant isolation and amount/rate limits
Credentials: scoped tokens, short TTL, no shared admin keys across agents
Audit: immutable logs of allow/deny with principal and resource IDs

On the exam, if a stem says authentication succeeded but a destructive tool still ran for the wrong customer, do not diagnose model size, RAG chunking, or caching. The keyed gap is authorization and least-privilege binding.

Exam application

Separate AuthN from AuthZ in every stem. Prefer server-side checks, scoped credentials, and verified resource binding. Distractors: longer "be careful" prompts, model upgrades, or logging without deny. Destructive tools without AuthZ are high-signal gaps.

Exam traps

Conflating AuthN with AuthZ
Successful login or a valid API key does not prove the agent may perform a destructive action for a given resource. Exam items often hide this split.
Relying on the model to enforce policy
"Be careful with PII" in a system prompt is not authorization. Destructive tools need server-side permission checks.
Over-privileged shared service accounts
A single god-mode token for "the agent" creates lateral movement and confused-deputy risk across customers and admins.
Logging access instead of denying it
Audit trails matter, but they do not close a gap where the tool still executes unauthorized work.

Practice scenario

A refund agent authenticates to the payments API with a shared service account that can refund any customer. The chat UI verifies the human user, but the tool call does not bind the refund amount or customer ID to that user's entitlements. What is the primary gap?

Option AMissing few-shot examples that tell the model to be careful with refunds.Option BAuthorization: the tool path lacks least-privilege checks tied to verified customer and action scope, even though authentication exists for the UI and service account.Option CLatency: the service account is too slow, so the model skips verification steps.Option DChunking: the refund policy document was split incorrectly in the RAG index.

Build exercise

Close AuthZ gaps on a refund tool path

40 minutes

What you'll learn

Distinguish AuthN vs AuthZ for agent tools
Bind actions to verified session context
Apply least-privilege credentials
Prove denies with automated security tests

Step 1
Map principals, resources, and actions for every tool
For each tool, name who calls it (user, agent, service), what resource it touches, and which actions are allowed. Mark gaps where identity is checked but permission is not.
Why: Security reviews for agents fail when AuthN and AuthZ are not drawn on the same diagram.
You should see: A matrix: tool × principal × resource × action × enforcement location (gateway, API, DB).
Step 2
Bind tool calls to verified context, not free-form IDs
Pass a signed session or case token into the tool layer. Reject refunds where customer_id is not in the verified set for that session.
Why: Agents can invent or swap IDs. AuthZ must validate server-side against trusted context.
You should see: Rejected call when customer_id does not match the authenticated case; accepted call when it does.
Step 3
Replace god-mode service accounts with scoped credentials
Issue credentials that can only refund within a product, region, or amount band, or use per-tenant tokens with short TTL.
Why: Least privilege at the credential layer limits blast radius if the agent is prompt-injected or mis-routed.
You should see: New credential policy document and a failed call when amount or tenant is out of scope.
Step 4
Add deny-by-default tests for destructive tools
Write automated cases: wrong customer, over-limit amount, missing authZ header, expired session. Expect hard failures, not model apologies.
Why: Exam-level judgment expects evidence that gaps are closed in the path, not only in prose.
You should see: CI tests that fail the build if unauthorized refunds succeed.

Sources

Tool use overview — docs.anthropic.com
Claude Code security — docs.anthropic.com
Model Context Protocol — docs.anthropic.com — connection and capability boundaries