Analyze Authentication and Authorization Requirements to Identify Security Gaps

Claude Certified Architect – Professional (CCAR-P) Domain 3: Integration — 19%

Authentication and authorization are among the highest-value security concepts to understand for the CCAR-P exam.

This objective is not primarily testing whether you can define OAuth, API keys, RBAC, or identity providers. It tests whether, when given a production architecture, you can identify where identity or access control is too broad, missing, misplaced, or being enforced at the wrong layer.

The exam-oriented question to keep asking is:

Who is making this request, what exactly should they be allowed to do, on which resource, under what conditions, and where is that decision actually enforced?

---

1 What You Need to Know for the Exam

At exam level, think about authentication and authorization as two separate architectural decisions.

Concept	Question it answers	Example
Authentication	Who are you?	“This request came from Alice.”
Authorization	What are you allowed to do?	“Alice may read Account 123 but cannot refund or delete it.”
Credential	How is identity represented/proven?	OAuth access token, API key, cloud identity
Role	What job function does the identity represent?	Support Agent, Analyst, Administrator
Scope / Permission	Which operation is permitted?	tickets:read, refund:write
Resource authorization	Which specific data may be accessed?	Customer records for Alice’s region only
Policy enforcement	Where is the decision technically enforced?	API gateway, authorization service, backend API, MCP server

Authentication without authorization is not enough

A user can be perfectly authenticated and still receive excessive access.

For example:

User successfully signs in using corporate SSO.

        ↓

Application knows:
"This is Ravi from Customer Support."

        ↓

Agent uses a shared backend credential
with access to ALL customers and ALL operations.

        ↓

SECURITY GAP
Authentication is correct.
Authorization is not.

This distinction is particularly important for AI systems because the model may be able to choose among tools, retrieve documents, invoke other agents, or call enterprise APIs.

A secure login does not make an over-privileged tool safe.

---

2 The CCAR-P Security Mental Model

When you see an authentication/authorization scenario, analyze it in this order:

Identity → Permission → Resource → Action → Enforcement → Audit

Consider a customer-support assistant.

Employee
   |
   | Corporate SSO
   v
Application
   |
   | User identity + entitlements
   v
Claude / Agent
   |
   | Selects allowed tool
   v
Authorization Layer
   |
   | Is this user allowed
   | to perform THIS action
   | on THIS resource?
   v
Enterprise API

The important architectural rule is:

Claude may decide what action to request. Claude should not be the authority that decides whether the action is permitted.

Authorization should be enforced by deterministic application or infrastructure controls.

A prompt such as:

Never allow unauthorized users to issue refunds.

is not a strong authorization mechanism.

A model instruction is advisory behavior. Access control should be enforced outside the model.

---

3 Authentication Requirements

Authentication establishes the identity associated with a request.

Typical identities in a Claude architecture include:

Identity	Example
Human user	Employee logged in using corporate SSO
Application	Backend application calling Claude API
Service	Worker processing asynchronous requests
Agent	Specialized agent invoking another service
MCP client	Claude Code or another client connecting to an MCP server
Machine workload	Cloud workload identity accessing enterprise APIs

Anthropic currently supports multiple authentication approaches across Claude Code deployments, including Claude organizational accounts, Console authentication, enterprise identity arrangements, cloud providers, and organization-controlled configurations. Claude Enterprise also provides capabilities such as SSO and role-based permissions.

Exam Focus

The exam is unlikely to ask:

“Which exact authentication header does product X use?”

It is much more likely to give you something like:

“Employees authenticate with corporate SSO, but all downstream requests use the same administrative API key.”

The correct analysis is:

The front-end authentication may be sound, but the downstream authorization model loses the user’s identity and collapses everyone into an over-privileged service identity.

---

4 Authorization Requirements

Authorization determines what an authenticated principal may do.

For CCAR-P, authorization usually needs to be evaluated across at least four dimensions:

Subject

Who is requesting the action?

Examples:

• Customer
• Support employee
• Manager
• Administrator
• Service account
• Another agent

Action

What operation is being requested?

Examples:

• Read
• Search
• Create
• Update
• Refund
• Delete
• Send
• Approve

Resource

What is being accessed?

Examples:

• Ticket 7281
• Customer Account A
• Medical Record B
• Document C
• Database row D

Context

Under which circumstances should the action be allowed?

Examples:

• User belongs to the same department
• Customer owns the record
• Transaction amount is below $500
• Request originates from an approved workload
• Human approval has been obtained

This can be summarized as:

Can SUBJECT perform ACTION
on RESOURCE
under CONTEXT?

That is much more useful for an architect than simply asking:

Does this user have an access token?

---

5 Least Privilege: The Most Important Exam Principle

The official sample material and both project practice exams strongly reinforce this principle:

Give an identity only the capabilities required to perform its intended job.

Consider:

Customer Support Agent

Tools:
- read_ticket
- search_customer
- draft_reply
- issue_refund
- delete_account
- modify_credit_limit

Support employees only need:

read_ticket
search_customer
draft_reply

The best security improvement is:

REMOVE:
issue_refund
delete_account
modify_credit_limit

Not:

Keep everything + logging

Not:

Keep everything + confirmation prompts

Not:

Use a stronger Claude model

The official CCAR-P sample question uses essentially this reasoning: unnecessary refund and deletion capabilities should be removed entirely, rather than merely logged or protected by prompts.

The workbook also calls this the central principle of Domain 3.

Why removal is stronger

Compare:

Control	Security effect
Remove unnecessary permission	Preventive
Narrow OAuth scope	Preventive
Resource-level authorization	Preventive
Separate privileged agent	Preventive
Human approval	Compensating/preventive gate
Log unauthorized activity	Detective
Alert security team	Detective
Ask Claude to behave carefully	Advisory
Use a larger model	Does not solve authorization

When the exam gives you a choice between:

A. Observe unnecessary privilege

and

B. Remove unnecessary privilege

prefer B, unless the scenario explicitly requires that capability.

---

6 Shared Credentials: A Major Security Gap

A recurring pattern in the project practice exams is:

One shared API credential grants broad account access and is used identically for every request.

Example:

Support User A
Support User B
Manager C
Administrator D
        |
        v
      Agent
        |
        v
SHARED SERVICE API KEY
        |
        v
FULL CUSTOMER DATABASE

This creates several problems.

Excessive privilege

Every request receives the power of the service credential.

Lost user authorization context

The downstream system may know:

CustomerSupportService accessed Account 123

but not:

Alice requested access to Account 123.

Larger blast radius

If the credential is exposed or the agent is manipulated, the attacker gains the credential’s full capabilities.

Poor accountability

Different user actions become difficult to distinguish.

The better pattern is:

Authenticated User
      |
      v
Application
      |
      | identity + entitlement context
      v
Authorization Enforcement
      |
      v
Only permitted operation
      |
      v
Enterprise System

Exam Shortcut

If you see:

“one shared credential + broad permissions + every request”

immediately investigate a least-privilege and authorization-scope gap.

---

7 User Identity vs. Service Identity

This is a very important architectural distinction.

Suppose an employee can read only customers in Region East.

The backend service itself can read every customer.

Weak architecture

Employee
   |
 authenticated
   v
Agent
   |
   | service credential
   v
Database
   |
 ALL customers

The application authenticated the employee but never propagated or enforced their entitlement.

Claude can now retrieve records that the employee should never see.

Better architecture

Employee
   |
   | identity / claims
   v
Agent Application
   |
   v
Authorization Layer
   |
   | filter:
   | region = EAST
   v
Retrieval/API

The authorization decision must use the requesting user’s effective permissions.

This issue becomes especially important in RAG.

---

8 Authorization in RAG Systems

Suppose your enterprise knowledge base contains:

Finance documents
HR documents
Engineering documents
Executive documents
Public documents

Different employees have different access.

A dangerous architecture is:

User Query
    |
    v
Retriever using global service account
    |
    v
Search ALL documents
    |
    v
Restricted documents added to Claude context

Then relying on:

System Prompt:
"Do not reveal information the user is not authorized to see."

is architecturally weak.

The better architecture is:

User Query
    |
    | User identity + entitlements
    v
Authorization-aware Retriever
    |
    | Apply ACL/security filters
    v
Only authorized chunks
    |
    v
Claude

The key principle is:

Never retrieve unauthorized content into the model context in the first place.

Once sensitive information reaches the context, you have already crossed an important security boundary.

This aligns with the workbook’s Domain 3 RAG guidance, which states that retrieval should respect the requesting user’s permissions rather than depending on the model to hide content afterward.

---

9 Tool Authorization

Claude-based agents frequently operate through tools.

For every tool, ask:

Who may see this tool?
Who may invoke it?
On which resources?
With which parameters?
Does invocation require approval?
What identity reaches the downstream system?

Consider two agents.

Support Agent

read_ticket
search_customer
draft_response

Supervisor Agent

read_ticket
search_customer
draft_response
issue_refund

This is preferable to giving both agents every tool and telling one of them:

Don't use issue_refund unless you're a supervisor.

The tool surface itself should reflect authority.

Claude Code follows a comparable permission-oriented security philosophy: it uses restricted permissions by default and requires permission for additional sensitive actions. Anthropic’s documentation emphasizes that Claude Code only has permissions granted to it rather than assuming unlimited system authority.

Exam Principle

Capability design and authorization design overlap.

A capability that the current role should never use should normally not be exposed to that agent.

---

10 Authorization Between Agents

Multi-agent systems introduce another authorization boundary.

Consider:

Research Agent
      |
      v
Finance Agent
      |
      v
Payment Agent
      |
      v
Bank API

If Research Agent can invoke Payment Agent with arbitrary instructions, its effective privileges may include financial actions even if it has no payment tool directly.

This is transitive privilege.

A common exam scenario may describe:

Agent A can call Agent B, but there is no defined limit on what Agent A may ask Agent B to perform.

That represents an authorization gap.

A better model is:

Research Agent
      |
      | allowed:
      | get_balance
      | get_transaction_history
      v
Finance Agent

Research Agent
      X
      | NOT allowed:
      | initiate_payment
      v
Payment capability

Agent-to-agent communication should therefore have explicit:

• allowed operations
• identity propagation
• scopes
• resource boundaries
• sensitive-action gates

Do not assume “internal agent” means “trusted for everything.”

---

11 MCP Authentication and Authorization

MCP makes authorization especially relevant because MCP servers may expose enterprise data and powerful actions.

Current MCP guidance uses standardized OAuth-based authorization for protected remote MCP servers. MCP authorization is particularly relevant when servers access user-specific data, expose sensitive actions, operate in enterprise environments, or need per-user accountability.

Claude Code can also pin OAuth scopes requested from an MCP server rather than accepting a broader advertised scope set. This is a practical example of applying least privilege to MCP authorization.

For example:

MCP Server advertises:

documents:read
documents:write
users:read
users:admin
payments:execute

Your research assistant needs only:

documents:read

The correct approach is not:

Request all scopes because they may be useful later.

It is:

Request only documents:read.

OAuth Scope Minimization

Think:

Requested permissions ⊆ Required permissions

not:

Requested permissions = Everything server supports

MCP’s current security guidance explicitly includes scope minimization among the areas security designers must consider.

---

12 Authentication Is Not the Same as OAuth Scope

A subtle exam trap is treating authentication as if it establishes permission.

OAuth/OIDC-style systems may give you:

Identity:
Alice

Token:
valid

Scopes:
documents:read

But Alice’s access may still need to be constrained to specific resources.

For example:

documents:read

does not necessarily mean:

read every document in the company

You may additionally need:

Department = Legal
Region = US
Document classification <= Confidential
Project membership = Project X

This is the difference between broad functional permission and fine-grained resource authorization.

---

13 RBAC, ABAC and Resource-Level Authorization

You do not need to become an IAM specialist for this objective, but you should understand the architectural reasoning.

RBAC — Role-Based Access Control

Access is determined from role.

Support Agent → read ticket
Supervisor → read ticket + issue refund
Administrator → user administration

Good when permissions align cleanly with organizational roles.

ABAC — Attribute-Based Access Control

Access depends on attributes.

Allow read if:

user.department = document.department
AND
document.classification <= user.clearance
AND
user.region = record.region

Useful when authorization depends on context or many attributes.

Resource-level authorization

Authorization operates on a particular object.

Alice may read Ticket 103
Alice may NOT read Ticket 487

Exam Strategy

Do not become distracted by terminology.

The important requirement is:

Authorization must be sufficiently granular to enforce the business access rule.

Whether the implementation uses RBAC, ABAC, policy engines, ACLs, database row-level security, or another mechanism is secondary unless the scenario specifically asks you to select one.

---

14 Credentials and Secrets

Another important security boundary is credential handling.

Avoid putting credentials into model-readable context.

Bad:

System prompt:

Payment API token:
sk_live_xxxxxxxxx

Better:

Claude
   |
   | structured tool request
   v
Application / Tool Host
   |
   | retrieves credential securely
   v
Secret Store
   |
   v
Payment API

The model should know:

issue_refund(order_id, amount)

It does not need to know:

secret payment API credential

The practitioner workbook makes this same distinction for enterprise integrations: credentials should remain host-side or be injected after requests leave the model’s readable context.

---

15 Authentication and Authorization Gaps You Should Recognize Immediately

Scenario signal	Likely security gap	Better approach
Shared admin API key for every request	Excessive authorization scope	Scoped credentials / authorization per request
User authenticated but service account accesses everything	User authorization lost downstream	Propagate identity or enforce entitlement at backend
Agent exposes unused destructive tools	Capability bloat / least-privilege violation	Remove tools
Model instructed not to reveal restricted documents	Authorization being delegated to model	Filter before retrieval
Every employee gets same MCP scopes	Over-broad authorization	Scope per use case/role
Agent A can request anything from Agent B	Undefined agent-to-agent authorization	Explicit invocation boundaries
Credentials included in prompts	Secret exposure	Host-side secret management
Logging used instead of access restriction	Detective control substituted for prevention	Prevent unauthorized action
Confirmation required for tool nobody should use	Unnecessary capability still exists	Remove capability
Larger model proposed to solve privilege problems	Wrong control layer	Authorization enforcement
Authenticated token but no resource ownership check	Missing object-level authorization	Resource-level policy
Permanent highly privileged credentials	Excessive blast radius	Scoped/short-lived credentials where possible

---

16 Preventive vs Detective Controls

This distinction is extremely useful for eliminating exam distractors.

Preventive

Stops unauthorized access before it happens.

Examples:

Remove tool
Deny scope
ACL filtering
Role restriction
Authorization policy
Resource ownership check
Human approval before irreversible action

Detective

Discovers that something occurred.

Examples:

Logs
Alerts
SIEM monitoring
Audit reports
Anomaly detection

Both are useful in production.

But:

A detective control normally does not compensate for unnecessary privilege when removing that privilege is practical.

This is why:

"Keep delete access but log it"

is generally weaker than:

"Don't grant delete access."

---

17 Prompt-Based Security vs Enforced Security

This is one of the most important conceptual distinctions for Claude architecture.

Prompt instruction

Never issue a refund above $500.

Useful for behavior.

Not sufficient as the authoritative security control.

Application authorization

if refund_amount > employee_limit:
    deny()

Enforced.

Better architecture

Claude proposes:
issue_refund(order=123, amount=750)

        ↓

Authorization Policy

Employee max refund = $500

        ↓

DENIED

Claude does not get to override the policy.

CCAR-P Rule

Hard security requirements belong in deterministic enforcement layers, not solely in prompts.

---

18 Human Approval Is Useful — But Not a Replacement for Least Privilege

Consider:

Agent can:
- read_ticket
- draft_response
- delete_customer

Every delete_customer call asks:
"Are you sure?"

But support employees never need deletion.

The best solution is:

Remove delete_customer.

Now consider a different scenario:

Managers legitimately need to issue refunds above $5,000, but the action is high risk.

A reasonable architecture may use:

Manager authorization
        +
Transaction limit policy
        +
Human approval
        +
Audit log

The difference is:

The capability is genuinely required.

Use approval to gate a necessary sensitive capability, not to justify retaining an unnecessary one.

---

19 Step-by-Step Exam Method

When you encounter a security vignette, use AUTH GAP:

A — Authenticate

Who is the principal?

Human, application, service, agent?

U — Understand required access

What does the role actually need?

T — Trace identity

Does the user’s identity survive downstream calls, or does everything become a shared service account?

H — Harden privilege

Can unnecessary tools, scopes, APIs, records, or actions be removed?

G — Gate sensitive operations

Which legitimate high-risk operations require additional policy or human approval?

A — Authorize resources

Does the control apply to the exact record/document/account involved?

P — Prove and audit

Can you reconstruct who requested what and what happened?

For CCAR-P questions, however, remember:

Audit comes after correct authorization. Audit does not replace authorization.

---

20 Worked Example

A healthcare organization has a Claude-based patient-support assistant.

Employees authenticate with enterprise SSO.

The agent uses a single backend API credential with permission to:

read_patient
update_patient
delete_patient
read_billing
modify_billing

Most support employees need only:

read_patient
update_contact_details

The RAG index also contains clinical and billing records, and retrieval is performed with the shared service credential.

Security gaps

Gap 1 — Authentication exists, but authorization is overly broad.

The employee’s identity is known, but downstream access is based on a highly privileged service identity.

Gap 2 — Excessive tool permissions.

Employees can indirectly reach operations they do not need.

Gap 3 — Retrieval ignores user entitlement.

The model could receive billing or clinical information the employee should not access.

Gap 4 — Large blast radius.

Any application bug or successful attack can potentially exercise all privileges held by the shared credential.

Gap 5 — Weak accountability.

Backend logs may identify the service rather than the employee responsible for the request.

Better architecture

Employee
   |
   | Enterprise authentication
   v
Application
   |
   | Employee identity + role
   v
Authorization Policy
   |
   +---- allowed tools
   |
   +---- allowed patient records
   |
   +---- allowed data classes
   |
   v
Claude
   |
   v
Authorized tool/retrieval request
   |
   v
Backend systems

---

21 Common Exam Traps

Trap 1: “Add more logging”

Logging is valuable, but it does not reduce unnecessary privilege.

If the role never needs deletion access:

Remove deletion access.

Trap 2: “Add a confirmation prompt”

Confirmation is useful for legitimate high-risk actions.

It is not a justification for unnecessary capability.

Trap 3: “Use a more capable model”

Model capability does not define authorization.

A more intelligent model with an over-privileged credential remains over-privileged.

Trap 4: “The user already logged in”

Authentication answers only:

Who is this?

You still need:

What may this identity do?

Trap 5: “The backend service is trusted”

Trusted services still need scoped permissions.

A compromise of a highly privileged “trusted” component produces a correspondingly large blast radius.

Trap 6: “Tell Claude not to expose restricted content”

If Claude receives unauthorized information, your security boundary is already too late.

Filter at retrieval or service access.

Trap 7: “Internal agent calls are trusted”

One agent calling another crosses an authorization boundary too.

Trap 8: “All OAuth scopes are easier”

Convenience is not least privilege.

Request only what the workflow requires.

---

22 High-Yield Exam Decision Table

If the scenario says…	Think…
“Used by every request”	Is privilege scoped per request?
“Shared credential”	Blast radius and lost identity
“Full account access”	Excessive privilege
“Only needs read access”	Remove write/delete capability
“Log misuse”	Detective, not preventive
“Ask user to confirm”	Compensating control
“User authenticated”	Authorization still needs checking
“Shared RAG index”	Entitlement-aware retrieval
“Agent can invoke another agent”	Transitive authorization
“Administrative tool”	Should normal agent even see it?
“OAuth/MCP scopes”	Minimize scopes
“Credentials in context”	Secret exposure
“Prompt says never…”	Advisory, not enforcement
“Sensitive irreversible action”	Strong authorization + approval
“Different roles use same agent”	Role-specific capabilities/policies

---

23 What the Current Anthropic/MCP Guidance Adds

For exam preparation, do not memorize rapidly changing configuration fields. Instead understand what current platform features illustrate architecturally.

Anthropic’s current Claude Code documentation uses a permission-based model with restricted default behavior and explicit authorization for more sensitive actions. This reinforces the broader principle that an agent should operate within deliberately granted boundaries rather than possessing unrestricted machine authority.

Current Claude Code MCP support also permits organizations to restrict the OAuth scopes requested from an MCP server. That is a concrete example of scope minimization and least privilege.

The current MCP authorization guidance recommends standardized OAuth-based authorization for protected remote MCP servers and emphasizes authorization when user-specific information, sensitive operations, enterprise controls, consent, or accountability are involved.

For CCAR-P, the lasting principle is therefore:

Authenticate the principal, preserve the relevant identity context, grant only required authority, enforce access outside the model, and minimize privileges at every integration boundary.

---

24 Exam-Focused Scenario Questions

The following questions are newly written for preparation. They follow the architecture-first style seen in the official guide and the supplied practice exams; they are not live CCAR-P questions.

Question 1 — Shared Service Credential

A financial-services company builds a Claude-based relationship-manager assistant. Employees authenticate using corporate SSO. However, the assistant accesses the CRM using one service credential that can read and modify every customer account. Junior relationship managers should only be able to view accounts assigned to them.

What is the most significant security gap?

A. Corporate SSO should be replaced with API keys. B. The Claude system prompt should list the accounts each employee may access. C. The downstream authorization model does not enforce the authenticated employee’s entitlements and instead uses an over-privileged shared identity. D. Additional logging should be enabled for CRM calls.

Correct Answer: C

Why

Authentication is already working: the organization knows which employee is using the assistant.

The failure is downstream authorization. The employee’s entitlement is lost when the request is executed using a global service credential.

The backend should enforce authorization using the requesting user’s identity or equivalent scoped entitlement context.

Why D is tempting: logging improves auditability, but unauthorized access could still happen.

Exam lesson: Authentication at the front door does not compensate for missing authorization at downstream systems.

Question 2 — RAG Authorization

A healthcare assistant searches a shared vector index containing clinical, billing, HR, and administrative documents. All employees authenticate correctly. Retrieval runs using a service identity that can search the entire index. The system prompt instructs Claude to “never show documents the current employee should not access.”

What should the architect change first?

A. Use a more capable Claude model. B. Apply the requesting user’s authorization filters during retrieval so restricted chunks never enter Claude’s context. C. Add citations to all generated answers. D. Log responses containing sensitive terminology.

Correct Answer: B

Why

This is fundamentally a retrieval authorization problem.

The best design is:

Identity
   ↓
Entitlements
   ↓
Authorized retrieval
   ↓
Claude

not:

Retrieve everything
   ↓
Claude
   ↓
"Please don't reveal restricted content"

A larger model does not enforce authorization. Citations improve traceability but might simply cite restricted documents. Logging discovers exposure after it occurs.

Exam lesson: Authorization should usually happen before sensitive data enters the model’s context.

Question 3 — Excessive Agent Capability

An internal HR assistant is used by recruiters to review candidate information and draft interview communications. Its tool configuration includes:

• read_candidate
• draft_email
• schedule_interview
• change_salary
• terminate_employee

Recruiters never need the final two capabilities.

Which change best reduces risk?

A. Keep all tools and log calls to change_salary and terminate_employee. B. Require recruiter confirmation before invoking those tools. C. Remove change_salary and terminate_employee from the recruiter’s agent capability surface. D. Add stronger instructions to the system prompt explaining when these tools are inappropriate.

Correct Answer: C

Why

This is the textbook least-privilege scenario.

A capability that the role does not need should not be available to the agent acting for that role.

Logging is detective. Confirmation is compensating. System prompting is advisory.

Removal is preventive.

Exam lesson: When the exam offers remove unnecessary privilege versus monitor unnecessary privilege, removing it is usually the stronger architectural answer.

Question 4 — Agent-to-Agent Authorization

A multi-agent procurement solution contains a Research Agent, Supplier Agent, Contract Agent, and Payment Agent.

The Research Agent may invoke the Payment Agent using arbitrary natural-language requests. The Payment Agent can initiate actual supplier payments.

What is the primary architectural concern?

A. Natural-language agent communication will increase latency. B. The Research Agent indirectly receives payment capability because there is no explicit authorization boundary governing what it may request from the Payment Agent. C. The Payment Agent should use a larger Claude model. D. All agents should share one credential to simplify authentication.

Correct Answer: B

Why

Privileges can become transitive.

Even though the Research Agent does not directly expose a payment tool, it can effectively obtain payment capability through another agent.

The architecture needs explicit restrictions on what one agent may request from another.

For example:

Research Agent → Payment Agent

Allowed:
get_payment_status

Denied:
create_payment
modify_bank_account
cancel_payment

Exam lesson: Treat agent-to-agent calls as security boundaries, not merely orchestration links.

Question 5 — MCP Scope Selection

A company connects a research assistant to an enterprise MCP server. The authorization server supports these scopes:

documents:read
documents:write
users:read
users:admin
payments:read
payments:execute

The assistant only searches policy documents.

Which configuration best follows the expected security architecture?

A. Request every scope now so future features require no authentication changes. B. Request documents:read only and expand authorization later if a justified business requirement emerges. C. Request every scope but instruct Claude not to use dangerous tools. D. Request administrator scopes and rely on audit logs.

Correct Answer: B

Why

This directly applies scope minimization and least privilege.

The application should request only what its current business function requires.

Current Claude Code MCP functionality supports restricting requested OAuth scopes, demonstrating exactly this architectural pattern.

Exam lesson: “Maybe we will need it later” is not a valid reason to grant privilege today.

---

25 Exercise 1 — Security Gap Review

Instead of a generic build exercise, use this architecture-review exercise because it closely matches the reasoning expected of a professional architect.

Scenario

You are reviewing a Claude-based customer-service assistant.

Architecture:

Customer Service Employee
       |
       | Corporate SSO
       v
Web Application
       |
       v
Claude Agent
       |
       +---- CRM Tool
       |
       +---- Refund Tool
       |
       +---- Delete Account Tool
       |
       +---- RAG Search
       |
       v
Shared Service Credential
       |
       v
All Customer Data

Facts:

• 80% of employees only need ticket lookup and response drafting.
• Supervisors may issue refunds up to $500.
• Only administrators may delete accounts.
• The RAG index contains both normal customer data and VIP customer data.
• Every operation uses one shared administrative service credential.
• Logs capture the service account but not always the initiating employee.

Candidate Task

Identify at least seven authentication/authorization gaps and redesign the architecture.

A strong answer should identify issues such as:

1. excessive shared service privilege
2. loss of user identity downstream
3. refund tool exposed to unauthorized employees
4. delete tool exposed to unauthorized employees
5. no transaction-limit enforcement for supervisors
6. RAG retrieval not scoped to user entitlement
7. inadequate per-user auditability
8. excessive blast radius
9. sensitive capabilities exposed unnecessarily
10. relying on the model rather than backend authorization

Then redesign using:

SSO
 ↓
User identity
 ↓
Role/entitlement policy
 ↓
Role-specific tools
 ↓
Resource-level authorization
 ↓
Authorized retrieval/API
 ↓
Audit using effective user identity

This exercise is valuable because it forces you to analyze the whole authorization chain, rather than simply remembering definitions.

---

26 Exercise 2 — Authorization Matrix

Create an authorization matrix for a Claude-powered enterprise support solution.

Example:

Capability	Support Agent	Supervisor	Administrator	AI Agent Enforcement
Search ticket	Allow	Allow	Allow	Tool exposed
Read customer	Assigned accounts	Team accounts	All	Resource filter
Draft reply	Allow	Allow	Allow	Tool exposed
Send reply	Allow	Allow	Allow	Backend permission
Refund ≤ $100	Allow	Allow	Allow	Policy check
Refund $101–$500	Deny	Allow	Allow	Role + amount
Refund > $500	Deny	Approval	Approval	Human approval
Delete account	Deny	Deny	Allow	Admin-only tool
Search VIP data	Deny	Conditional	Allow	Retrieval ACL

Then answer these questions for every row:

Who authenticates the user?
Where does authorization happen?
Does Claude receive the capability?
Does the backend independently validate it?
Whose identity appears in the audit trail?
What happens if Claude requests a forbidden operation?

This is one of the best ways to develop the architecture judgment the CCAR-P objective is trying to measure.

---

27 Five Things to Memorize

If you remember only five rules from this section, remember these:

1. Authentication asks “Who are you?” Authorization asks “What may you do?”

A valid identity can still be over-privileged.

2. Least privilege means removing authority that is not required.

Logging unnecessary privilege is not equivalent to removing it.

3. Enforce authorization outside Claude.

Prompts may guide behavior; deterministic application or infrastructure controls enforce security policy.

4. Preserve authorization through every integration boundary.

User → application → Claude → tool → MCP → agent → API → database.

A secure first hop does not make later hops secure.

5. Filter sensitive information before it enters Claude’s context.

Especially for RAG, apply user/resource entitlements during retrieval rather than asking the model to hide unauthorized information afterward.

---

28 Final Exam Cheat Sheet

AUTHENTICATION
Who are you?

AUTHORIZATION
What may you do?

LEAST PRIVILEGE
Only what you need.

SHARED ADMIN CREDENTIAL
Red flag.

UNUSED POWERFUL TOOL
Remove it.

LOGGING
Detective, not a substitute for prevention.

CONFIRMATION
Useful for necessary high-risk actions,
not justification for unnecessary privilege.

RAG
Filter by user entitlement BEFORE retrieval.

PROMPT
Behavioral guidance, not hard authorization.

MCP
Authenticate + authorize + minimize scopes.

AGENT-TO-AGENT
Define invocation boundaries.

CREDENTIALS
Keep secrets outside model-readable context.

SERVICE IDENTITY
Do not automatically substitute it
for the requesting user's authorization.

SENSITIVE ACTION
Authorize deterministically;
add approval where justified.

EXAM DEFAULT
Prevent > detect.
Narrow > broad.
Scoped > shared.
Enforced > instructed.

---

29 What the Exam Is Really Testing

For this objective, CCAR-P is testing whether you think like the architect accountable for the complete system.

A developer may ask:

“Can Claude call this API?”

An architect should also ask:

“Should this particular user, through this particular Claude workflow, be permitted to perform this particular operation on this particular resource?”

That second question is the heart of this objective.

The strongest CCAR-P answer will usually be the option that preserves identity, minimizes privilege, places authorization at an enforceable system boundary, constrains data and tool access before Claude can misuse them, and limits the blast radius of a failure.

That reasoning is strongly aligned with the official Domain 3 objective and with the supplied practice material’s repeated focus on least privilege, shared credentials, capability scoping, RAG entitlements, and agent-to-agent access boundaries.