AnthropicClaude Certified Architect – Professional2026-103.2 Analyze authentication and authorization requirements to identify security gaps
Scope every read and write upstream
Completed by the knowledge check
Learning objective
Enforce authorization and tenant or resource scoping in tools, retrieval, and memory rather than relying on the model to respect permissions.
Core idea
A deterministic pre-tool check can stop a prohibited operation, but an enterprise assistant also needs authorization wherever data enters or persists beyond the agent. This lesson adds backend resource checks, retrieval scoping, and memory isolation to that execution policy.
Your acceptance condition is that an unauthorized resource never reaches the response context or the storage mutation. A prompt asking Claude to ignore another tenant’s records is too late after those records have been retrieved. The same principle applies when a permitted memory tool reads a store belonging to someone else.
How it works
Bind authorization to the resource operation
Treat tool input as a proposal and resolve the principal and tenant from trusted session state. For a multi-client system, choose where every route to the resource enforces that authority.
Make the resource service the shared enforcement point for agent tools and other clients. Its authorization check combines the authenticated principal, tenant, requested action, and target resource; an agent-facing check must not be the only route that applies it. Define the entitlement predicate in the backend’s domain, such as account ownership, assigned care team, or project membership, and apply it to direct lookups as well as search. A permitted search result does not grant authority to update that resource through another endpoint.
An application-owned dispatcher can return a failed call as a tool_result with is_error: true. That communicates denial without supplying the forbidden record. Preserve the failure as a failure; substituting the service account or silently searching a broader dataset would undo the authorization decision.
Filter retrieval before assembling context
Build the retrieval query from two inputs: model-proposed relevance criteria and application-enforced access criteria. The tenant or permitted resource set must constrain which records can be returned. Your index adapter owns that filtering; it is not a tenant authorization feature of the Claude Messages API.
Anthropic’s secure-deployment guide recommends request validation outside the agent’s boundary and minimal access to required resources. Apply that principle to the search adapter: it must reject an attempt to widen the trusted tenant filter, and the underlying data service must enforce its own access policy.
For example, an application can take a model’s query text while supplying an immutable tenant predicate from the session. The exact query syntax depends on the chosen index and is not an Anthropic field. Verify that the selected store applies the predicate before any unauthorized result is returned to the model.
Filtering only the final answer leaves both an exposure and a capacity problem. Unauthorized passages have already entered context, and they may displace authorized results. A retrieval test must inspect returned resource IDs and the context assembled from them, not merely look for forbidden words in the final answer.
Give memory its own authorization boundary
Anthropic’s memory tool is client-side. Claude requests file operations, and your application controls their storage. Its /memories prefix can map to a per-user directory or database keys. The tool’s visible path is not proof that the underlying store belongs to the signed-in user.
Derive the physical namespace from trusted tenant and user state. In an illustrative application, /memories/preferences.txt resolves inside that user’s permitted store; a model-proposed path cannot select another tenant’s store. Shared organizational memory needs a separate, explicitly authorized policy rather than an accidental common directory.
Authorize reads and writes independently. A user permitted to read shared operating instructions need not be permitted to replace them. The memory handler receives command and path fields; check the requested operation before applying it. For rename, validate both old_path and new_path so an allowed source cannot be moved into another security scope.
The memory documentation also requires validation against directory traversal. Resolve paths to canonical form and verify they remain within the memory directory; a prefix check alone does not stop /memories/../../secrets.env. Apply this to every command. Canonical containment protects the filesystem boundary; selecting the correct per-user root protects the identity boundary. You need both.
Recheck reuse of already authorized data
Authorization at retrieval time does not authorize every later recipient. If the application reuses an answer or memory entry, associate it with its permitted recipient scope. A cache keyed only by the question can replay a tenant-specific answer to a different user without making another tool call.
This is an application storage requirement, not a promise made by the memory tool. Keep reuse within the same authorized scope or reauthorize before serving it. Permission changes must affect later access to persisted content as well as fresh reads. Identify the owner of that invalidation decision when reviewing the retrieval and memory adapters.
Key distinctions and trade-offs
Tool availability answers whether a capability can be proposed. Authorization answers whether this principal can perform this action on this resource. Tenant isolation answers which resources can be considered at all. None substitutes for the others.
A shared store reduces duplication but needs more explicit membership and write controls. Separate per-user stores simplify isolation but make intentionally shared knowledge harder to maintain. Choose deliberately for each memory class rather than copying a single demonstration store into a multi-user service.
Pre-filtering can reduce the candidate pool and expose index-design limitations. Solve that inside the authorized pool. Broadening search to other tenants to improve answer quality changes the security requirement rather than tuning retrieval.
Architecture / decision scenario
A healthcare scheduling assistant serves 12 clinics. Staff can view appointments only for their assigned clinic; supervisors can read a shared procedures collection but only its editors can update it. The team proposes searching all appointment documents and asking Claude to suppress records from other clinics because a global index is easier to operate.
The architect rejects that alternative. The tool handler resolves the clinic from the verified staff session, and the retrieval adapter applies the clinic constraint before returning appointments. The appointment backend also checks the requested record, so a direct lookup cannot bypass search scoping.
Personal scheduling preferences use a user-specific memory root. Shared procedures use a separate authorized store. The handler checks command, validates canonical path containment, and requires editor authority for writes. A cross-store rename is denied even if its source exists.
The data-platform owner must demonstrate that staff from clinic A cannot retrieve clinic B’s records through search, lookup, persisted memory, or answer reuse. The alternative needs fewer storage rules but fails the isolation requirement. Acceptance examines returned resource IDs and storage effects, with zero unauthorized records reaching context.
Common exam traps
- Retrieving every tenant’s documents and filtering only the final answer.
- Trusting a tenant ID because it appears in valid tool arguments.
- Guarding search while leaving direct record lookup unscoped.
- Treating
/memoriesas automatic per-user isolation. - Checking only the source path of a memory
rename. - Reusing an authorized answer for an unauthorized recipient.
What to remember
Resolve identity outside model input, enforce access in the resource service, and scope retrieval before context assembly. Map memory to the correct authorized store and validate every operation and path. Persisted data needs the same recipient checks as fresh data.
Knowledge check
An accounting firm’s assistant searches one shared index of client documents for 40 client teams. Staff may see only their own clients’ documents. A proposal retrieves the top 20 passages across all clients and has Claude leave other clients’ passages out of the answer. What should the retrieval adapter do instead?
In a clinic-scoped scheduling assistant, the search tool filters appointments by the staff member’s clinic. A penetration test calls get_appointment directly with another clinic’s appointment ID and receives the record. Where should the fix be enforced?
A manufacturer’s multi-user operations assistant uses the client-side memory tool. Each user’s memory maps to their own directory, and a shared procedures store is writable only by editors. A non-editor’s session issues rename with old_path in that user’s directory and new_path inside the shared procedures store. The handler canonicalizes and authorizes old_path only. What should the handler do?
new_path as a write and deny the renamenew_path is free of ../ sequencesrename writes to its destination, so both paths need canonical containment and authorization, or an allowed source can be moved into a store the user may not write. Here the destination fails the write check. A traversal check protects the filesystem boundary but not the identity boundary between stores, and a log entry records the write instead of preventing it.To cut latency, a bank’s assistant caches answers keyed by the normalized question text. An auditor finds that an answer built from one corporate client’s account data was served to a user from another client who asked the same question. What should the architect change?
References
- Anthropic, Securely deploying AI agents
- Anthropic, Memory tool
- Anthropic, Control execution with hooks
- Anthropic, Handle tool calls