AnthropicClaude Certified Architect – Professional2026-100 Prerequisites
Separate identity from permission to act
Completed by the knowledge check
Learning objective
Apply identity, authentication, authorization, and least-privilege fundamentals to user and service access.
Core idea
Access design answers four questions: who is acting, how their identity is verified, what they may do, and how narrowly that permission is granted. As an architect, you need separate answers for the person requesting work and the service executing it.
A successful sign-in does not grant every resource permission. A model’s understanding of a request does not supply either identity or permission. Establish this vocabulary before choosing credentials or enforcement mechanisms.
How it works
An identity represents an actor in the system. In your access map, distinguish the end user, application service, tool service, and credential used against an external system. A displayed agent name describes a workflow participant; it does not by itself identify a security principal accepted by the destination.
Authentication verifies the identity of a user, process, or device. NIST’s definition includes processes and devices, so the term is broader than a human sign-in screen. A service must also prove the identity under which it accesses a dependency.
Authorization determines the rights granted to an entity for a resource or operation. Specify the subject, action, resource, and relevant scope. “Can use the assistant” is different from “can read this student’s record” or “can modify this grade.” See 3.2.1 for user-versus-service identity choices and 3.2.2 for enforcement in tools, retrieval, and memory.
Least privilege gives an entity only the authorizations and resources needed for its assigned function. Apply it to users and to processes acting for them. A summarization service that needs record reads has no task-derived reason to receive grade-write access. See 3.1.2 for narrowing agent capabilities.
Two permissions can matter on one path: the application service can reach a records API, while the requesting user is entitled to only a subset of its records. Treating service connectivity as proof of user entitlement creates an access gap. Record both actors and the decision at the destination rather than asking the model to infer the user’s rights.
Anthropic’s prompt-injection guidance also recommends limiting access to sensitive data and actions. This connects least privilege to consequence: if hostile content redirects a model, narrow permissions reduce what the execution path can reach. Permission does not make the content trustworthy; see 0.5 for that distinction.
Key distinctions and trade-offs
Authentication versus authorization: Verified identity is an input to an access decision, not the decision’s result.
User versus service access: The user initiates a task; a service may execute it with a different identity. That difference must remain visible in the design.
Capability versus entitlement: Advertising a tool describes an available operation. It does not establish that this caller may apply it to every resource.
Narrow permissions can require more explicit task partitioning and access decisions. Broad credentials reduce that work but enlarge the consequences of a mistaken or manipulated action. Make the assigned function the reason for each grant.
Architecture / decision scenario
An education provider has a four-person platform team building a student-record summarizer. Tutors may read records for their assigned students; only registrars may change grades. The assistant must never write grades.
The team proposes one records-admin service credential, with the model checking tutor assignments, to simplify integration for four engineers. You reject this choice: the broad grant permits unnecessary grade writes, and the assignment rule needs enforcement at the records API.
You map tutor authentication separately from the summarizer’s service authentication. The records API’s resource policy checks the tutor’s assignment, while the service receives read access for its summarization function and no grade-write grant. A student’s uploaded note cannot enlarge either permission. The platform owner maintains service access, and the education operations owner defines tutor assignments. The team has a reviewable access map before selecting the detailed controls in 3.2.1 and 3.2.2.
Common exam traps
- Equating a successful sign-in with access to all records.
- Treating a service credential as the requesting user’s entitlement.
- Relying on a prompt to compensate for unnecessary write permissions.
What to remember
Name every actor, authenticate it, authorize each scoped operation, and grant only what its function needs. User access and service access require separate reasoning.
Knowledge check
Hospital staff sign in through single sign-on before using a discharge-summary assistant, whose service credential can read every ward’s records. A nurse asks for a summary of a patient outside their ward. What should decide whether that record is included?
A three-person team builds a payroll summarizer that only reads pay records. The team proposes an admin credential with read and write access to simplify integration. Which grant should the summarizer’s service receive?
A university agent named “Registrar Assistant” has an update_grade tool in its tool list. A tutor, who may read grades but not change them, asks it to raise a student’s grade. What should determine whether the write happens?
References
- NIST, Authentication.
- NIST, Authorization.
- NIST, Least privilege.
- Anthropic, Mitigate jailbreaks and prompt injections.