CCAR-P - Integration (19% of the exam) - Section 3.2

Analyze authentication and authorization requirements to identify security gaps.

Tracing whose identity and permissions an AI system acts with, where credentials are held, and whether authorisation is enforced by the system or merely requested of the model. Candidates should spot gaps such as shared service credentials, missing per-user scoping, and authorisation decisions left to the prompt.

authentication versus authorisationacting on behalf of a usercredential handlingserver-side enforcement

Practice question for this objective

Free sampleIntegrationhard

A software company's engineering assistant lets staff ask it to open, review and merge pull requests on the company's code-hosting platform. Its integration authenticates to the platform with one bot token holding organisation administrator rights, and the system prompt tells it to act within each requester's permissions. A quarterly audit found that a contractor with read-only access to the billing repository asked the assistant to merge a change there, and the merge succeeded. The platform's audit log attributes the merge to the bot account, branch protection settings have not changed in a year, and the same contractor's direct attempt to merge the same change an hour earlier was rejected. What most likely allowed the merge?

ABranch protection on the billing repository was misconfigured and let any account merge without approval
BThe contractor's identity provider group grants write access that the platform mapped incorrectly
CThe platform authorised the merge against the bot token's rights, not the contractor's delegated identity Correct
DThe model ignored its instruction to check permissions, which a stronger system prompt rule would enforce

An assistant acting for users through one privileged shared credential lets every user borrow that credential's rights; delegated user identity keeps authorisation with the target system. The code-hosting platform makes its authorisation decision against the identity on the request. Because every request arrives with the bot's administrator token, the platform sees an administrator and allows the merge, whatever the human requester may do. The contractor's rejected direct attempt shows the platform's controls work; they were simply never applied to the contractor's identity.

Why A is wrong: This is tempting because an unexpected merge into a protected repository points at protection settings. It is wrong because the settings were unchanged and correctly rejected the contractor's own direct attempt, so protection works for the contractor's identity.

Why B is wrong: This is tempting because group-to-permission mapping errors are a common source of excess access. It is wrong because the platform rejected the contractor's direct merge, which shows the contractor's own mapped permissions are read-only as intended.

Why C is correct: Correct. The audit log attributes the merge to the bot, so the platform checked the bot's administrator rights. Acting on the requester's delegated identity, or a token scoped to that user, would let the platform's own authorisation reject the merge as it did the direct attempt.

Why D is wrong: This is tempting because the model did act outside the requester's permissions despite the instruction. It is wrong because a prompt rule only asks the model to self-police; the platform will accept anything the administrator token can do, so rewording the prompt leaves the gap open.

See more CCAR-P practice questions, answers explained.

Exam traps in Integration

Answers that look right on this material and are not. Each one is a distractor from a different question in the CCAR-P bank for this domain.

Give the assistant its own service account with caseworker-level rights, so the audit log names the assistant as the author of every change it makes
Why it is wrong: This is tempting because the legal audit log would now distinguish assistant changes from manual ones. It is wrong because the log would no longer record which caseworker each change was made for, and the shared account's rights are not the individual caseworker's, so a caseworker could reach records outside their own permissions through the assistant.
The resident's password was weak enough to be guessed, giving the tester an officer's authenticated session
Why it is wrong: This is tempting because credential guessing is a classic route to elevated access. It is wrong because the tester used her own resident account and login passed the test, so no officer session was obtained; authentication was not the gap.
Keep the shared credential and route every write request the assistant makes through a human approval queue in the servicing team
Why it is wrong: An approval queue is tempting because it stops unreviewed loan changes. It is wrong because the assistant's role needs no writes at all, so this gates a capability that should not exist, and it does nothing about the audit's second requirement: the shared credential can still read any other customer's loan.

Examworthy is not affiliated with or endorsed by Anthropic. Original, blueprint-aligned practice material only.