- In short
- Authorization model parity means the access-control model that governs an organisation's existing systems must also govern the Claude integration layer. A Claude layer that bypasses that model creates a new, unintended path to restricted data. Authorization checks belong in the tool or API layer the agent calls, not solely in prompt instructions to the model, and an authenticated user is not automatically authorised for every action the agent can perform.
The Claude layer must inherit the existing access-control model
An enterprise already has an authorization model: rules about which users and roles can read which data and perform which actions, enforced across its existing systems. When Claude is added as a layer in front of or alongside those systems, the exam's requirement is blunt: the same model has to govern the Claude layer too. Parity, not a parallel scheme, and not a gap. If the underlying order system lets only account owners view an order, the Claude integration that reads orders must enforce the same rule.
The failure mode when parity is missing is precise and dangerous. A Claude layer that does not enforce the existing model becomes a new path to restricted data, one that was never designed to apply the access policy. Users who could not reach certain data directly can now reach it by asking the agent, because the agent's path skips the checks the direct path enforced. The integration has quietly created a hole in an access-control model the organisation believed was complete.
- Authorization model parity
- The requirement that the access-control model governing an organisation's existing systems also governs the Claude integration layer, enforced at the tool or API layer the agent calls. Without parity, the Claude layer becomes an unintended path to restricted data that bypasses the established policy.
Enforce at the tool layer, not in the prompt
Where parity is enforced matters as much as that it exists. The checks belong in the tool or API layer the agent calls, the same layer that already knows how to apply the organisation's access policy, not solely in prompt instructions to the model. A prompt that says "only return data the user is authorised to see" is an instruction to a model that has no reliable way to enforce it and, as the user-asserted role claim topic showed, can be talked around. The tool layer, by contrast, can check the verified role and scope against the requested action and simply refuse when the check fails, before any data is returned.
So the pattern is: identity comes in verified from server-side injection, and the tool the agent calls consults that identity against the same authorization rules the underlying system uses. The model orchestrates; the tool layer authorises. Relying on the model to be the authorization boundary puts the decision in the one place that cannot enforce it.
Authenticated is not authorised
The distinction the exam presses on is authentication versus authorization. Authentication answers "who is this user," and server-side identity injection handles it. Authorization answers "what may this user do," and it is a separate decision. A user can be perfectly authenticated, their identity verified beyond doubt, and still not be authorised for a given action the agent can perform. Treating a valid login as a licence for everything the agent can reach collapses the two, and it is exactly how an over-broad agent leaks data to users who are who they say they are but should not have access.
Parity keeps the two separate at the right layer. Authentication establishes the verified identity; the tool layer then checks that identity's authorization for each specific action against the underlying model. Being logged in gets you in the door; it does not open every room.
What the exam trips candidates on
Two traps recur. The first is relying on the model to refuse unauthorised requests instead of enforcing authorization at the tool-call layer, which places the decision where it cannot be reliably enforced. The second is assuming that because a user is authenticated, they are automatically authorised for every action the agent can perform, collapsing authentication into authorization. The credited answer enforces the existing access model at the tool layer and keeps the two concerns distinct.
Worked example
A Claude agent helps employees query an internal HR system. Any authenticated employee can ask it questions, and a system-prompt line instructs the model to 'only reveal salary data to HR staff.' A non-HR employee asks the agent for a colleague's salary and, after some rephrasing, gets it. Diagnose the design failure and fix it.
There are two coupled failures here, and both are this knowledge point's traps. First, authorization was placed in the prompt: 'only reveal salary data to HR staff' is an instruction to the model, and the model is not a reliable authorization boundary, which is why rephrasing eventually got past it. Second, the design treated 'authenticated employee' as sufficient to reach the salary-query capability, conflating authentication with authorization; the employee's identity was genuine, but genuine identity does not authorise the action.
The fix restores parity at the right layer. The internal HR system already has an access-control model, only HR staff may read salary fields, and the Claude layer must enforce that same model rather than inventing a weaker one. Concretely, the salary-lookup tool the agent calls checks the requesting user's verified role (from server-side identity injection) against the HR system's rule and refuses to return salary data when the role is not authorised, before any data leaves the tool. With the check at the tool layer, no amount of rephrasing to the model matters, because the model never receives salary data it should not return. Authentication still governs who can talk to the agent; authorization, enforced in the tool layer against the existing model, governs what each authenticated user can actually retrieve.
Common misreadings to avoid
Misconception
Instructing the model in the system prompt to refuse unauthorised requests is an adequate authorization control.
What's actually true
Misconception
Once a user is authenticated, they are authorised for whatever the agent is able to do.
What's actually true
How this shows up on the exam
Expect an integration where authorization is either missing, delegated to a prompt instruction, or assumed from authentication. The reliable reading is that the Claude layer enforces the same access model as the underlying systems, at the tool layer, and that authenticated is not authorised. This knowledge point builds on server-side identity injection and minimal necessary identity context, unlocks multi-tenant API key isolation, and connects to metadata-enriched indexing, where authorization is enforced at the retrieval layer of a RAG pipeline.
A Claude agent over an HR system relies on a system-prompt rule to keep salary data away from non-HR staff, and lets any authenticated employee query it. A non-HR employee eventually extracts a salary. What is the correct fix?
People also ask
Where should authorization checks live in a Claude integration?
Can the Claude layer bypass existing access controls?
Is an authenticated user automatically authorised?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
Official prep for this domain
Anthropic's own free prep module for this part of the syllabus, on the official prep course. Free with an Anthropic Academy sign-in.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.