AnthropicClaude Certified Architect – Professional2026-103.2 Analyze authentication and authorization requirements to identify security gaps
Choose whose authority each tool spends
Completed by the knowledge check
Learning objective
Map identities across users, service accounts, agents, and tool credentials, and decide between delegated user permissions and service identity to avoid confused-deputy risks.
Core idea
A request can authenticate successfully at every network hop and still disclose data to the wrong person. Each hop might authenticate a different principal: the person signing in, the application calling Claude, and the service reading a customer record. Your architectural decision is whose authority the final operation spends.
For an architect reviewing a multi-user agent, write that answer for every tool. A powerful service can become a confused deputy when it uses its own permissions to satisfy a requester who lacks them. Model compliance does not resolve that mismatch. The identity path must survive a request that names another user’s resource or arrives through injected document instructions.
How it works
Trace principals separately from agent names
Start with a representative operation and follow it from sign-in to the target system. Record these distinct roles:
| Role | What establishes it | What it does not establish |
|---|---|---|
| End user | Your application’s verified sign-in session | Permission to every record mentioned in a prompt |
| Application workload | A credential accepted by the Claude API | The user’s entitlement in your business systems |
| Agent execution | Your runtime’s association between a run and its initiating principal | A downstream account merely because the agent has a name |
| Tool caller | The credential presented to the tool or gateway | Authority beyond that credential’s scope and the backend’s checks |
| Downstream principal | The account the resource service authorizes | That the original user should inherit all its rights |
The sign-in session and run association are application-owned design elements. Do not treat a model-supplied user ID as their source. Anthropic’s secure-deployment guidance describes the agent as a component whose actions can be influenced by files, webpages, and user input, and recommends putting sensitive resources outside its security boundary.
On the Claude API side, Anthropic distinguishes personal keys from service account keys. A personal key acts as its owner; a service account key represents a non-human account suitable for shared workloads, including agents. An agent run can use a Claude-side service account distinct from its downstream identities. Direct HTTP uses x-api-key; the client SDK reads ANTHROPIC_API_KEY. These authenticate the application to Anthropic. They do not become authorization to read a patient’s chart or change a retail order.
A service account is therefore not inherently the wrong choice. The error is letting a credential valid for one system answer an authorization question in another. Record the issuer, intended destination, represented principal, and permitted operation separately for each credential.
Choose delegated or service authority per resource
Use delegated access when the resource must enforce the requesting user’s rights. The downstream request carries that user’s authorized access rather than a broad account shared by all callers. Still narrow the operations available to the agent: a user with write access need not grant an assistant every write capability.
The Messages API MCP connector, a beta feature (anthropic-beta: mcp-client-2025-11-20) documented for the Claude API, Claude Platform on AWS, and Microsoft Foundry, provides a concrete place to carry an OAuth token: mcp_servers[].authorization_token. Your application obtains and refreshes it; the connector does not perform the user authorization flow for you. See 3.2.4 for its remote-server security review. The application must choose the token belonging to this requester and this server outside model-generated input.
Use a service identity for work that genuinely belongs to the service, such as an approved batch operation or a shared reference catalog. Give it authority over the required resources and operations, rather than assuming every caller should receive everything it can retrieve. If results vary by user, an additional user-specific enforcement point remains necessary even when the downstream account is a service.
For a legacy backend that cannot accept delegated credentials, an external gateway can perform the user’s entitlement check and then execute with a narrowly scoped service account. Anthropic documents custom tools or MCP servers that route authenticated requests through a service outside the agent’s security boundary. This makes the gateway a consequential security component: its request validation must connect the verified requester to the exact resource before spending service authority.
Make the identity decision inspectable
For each tool, produce a principal inventory entry: initiating user, runtime identity, Claude credential, downstream credential, authorization owner, and operation scope. These are your architecture-review fields, not Anthropic API properties. Annotate any hop where a user becomes a service account and explain which check prevents privilege expansion there.
The tempting shortcut is a single account with access to every tenant, combined with instructions telling Claude which tenant to use. Reject that design when a forged resource ID can still reach another tenant. Changing the prompt does not alter the credential the backend sees.
Credential isolation belongs to 3.2.3; enforcement across retrieval and memory belongs to 3.2.2. Here, the inventory must identify who owns those decisions rather than explaining their implementation again. Test the selected path with two authenticated users whose resource sets differ, and inspect which principal the backend authorizes for each request.
Key distinctions and trade-offs
Delegation preserves a user’s access boundary but adds consent, expiry, refresh, and account-lifecycle handling. It also inherits weaknesses in the source system’s entitlements. If every employee can already read every record, passing an employee token does not narrow that access.
A service identity simplifies unattended execution and avoids tying production availability to one employee’s account. It concentrates authority. A gateway that translates user requests into service calls must therefore enforce user-specific restrictions and preserve attribution; a backend log naming only the service cannot explain which user initiated a disclosure.
An agent’s role description is a planning instruction. A service account is an authenticated principal. A tool permission is an execution control. Keep those meanings separate when defending the design to security and operations owners.
Architecture / decision scenario
A financial-services assistant serves 180 advisers. Each adviser can read only their assigned client portfolios, while everyone can read the same research catalog. The proposed pilot uses one account that can read all 24,000 portfolios because the legacy integration already has that credential.
The architect rejects using it directly for interactive portfolio requests: an adviser who names another client’s ID would spend the service’s broader rights. The portfolio team supports user delegation, so the application selects the signed-in adviser’s read token for that tool. The catalog retains a separate read-only service identity because its content is deliberately shared.
A legacy notes system accepts only a service account. The architect places it behind an external tool gateway that resolves the adviser from the authenticated session and checks the requested client before using the service credential. The notes owner must accept that enforcement responsibility; rotating the broad key alone would not change the access result.
The platform team keeps a Claude service account key for the shared application. It is distinct from both downstream identities. Acceptance requires that an adviser can retrieve their own portfolio, cannot retrieve another adviser’s portfolio or notes, and that the operations trail identifies the initiating adviser even on the legacy path.
Common exam traps
- Equating a valid Claude API key with authorization in a business backend.
- Treating an agent name or prompt role as a downstream principal.
- Passing a model-generated user ID as trusted identity.
- Assuming delegated access repairs overbroad source-system entitlements.
- Rejecting every service identity, including a deliberately shared read-only catalog.
- Keeping a broad credential and calling key rotation the confused-deputy fix.
What to remember
Choose the principal per operation, not per assistant. Use delegated user authority where access varies by requester, and service authority where the work belongs to the service. When a gateway spends service authority for users, make its entitlement check and attribution explicit.
Knowledge check
A law firm’s research assistant serves 300 lawyers, each permitted to read only the matters they are staffed on. The matter system supports per-user OAuth tokens. The pilot reads matters through one integration account that can open all 8,000 matters, and the system prompt tells Claude to open only the requester’s matters. Which change prevents a lawyer from reading another team’s matter by naming its ID?
A utility’s billing-history system accepts only a service account, and that account can read every customer’s history. Call-center agents may see only the customers on their own active cases. The assistant needs that history for each agent’s current case. Which design keeps the service account without creating a confused deputy?
A pharmaceutical company’s assistant uses two sources. Trial records are restricted per study team and accept per-user delegated tokens. A drug-interaction reference may be read by every employee, and its vendor issues credentials per organization, not per user. Which principal should the reference tool use?
A manufacturer’s HR assistant moves from a shared service account to delegated employee tokens for the HR records system. A security review then finds that the HR system grants every employee read access to every personnel file. What does the move to delegated tokens change about which files an employee can reach through the assistant?
References
- Anthropic, Get your API key
- Anthropic, Securely deploying AI agents
- Anthropic, MCP connector