On this page
TLDR
Agent authentication and authorization is a stack of controls, not one setting: which identity the process runs as, what credentials each tool call carries, and which actions need a human in the loop. The exam trap is assuming MCP is secure by default - MCP authorization is optional by spec and transport-scoped (HTTP transports SHOULD use OAuth 2.0; STDIO pulls credentials from the local environment), so an unaudited server can legally expose tools with zero auth.
What you are deciding
Authentication tells you who the agent is; authorization decides what it may do. Give each agent the narrowest tools its task needs, and enforce the limit where the tool runs, not only in the prompt.
Which capability does this agent actually need, and where is each limit enforced?
What it is
For an architect, agent auth is not one control but a stack: the identity the agent process runs as, the credentials each tool call carries to reach external systems, and what a human must approve versus what runs unattended. Traditional RBAC assumes a mostly-static permission set; agentic systems break that assumption because an LLM can chain tool calls at machine speed, across systems, without a human in every loop - so access analysis has to reason about the agent's full reachable capability surface, not just its nominal role.
That stack spans multiple platform layers, and none of them alone secures a multi-tool agent: MCP's authorization spec governs server-to-server auth, the Claude Agent SDK's permission rules govern what a coding/agentic harness is allowed to invoke, and the Managed Agents API's per-tool policies govern server-executed tools specifically. These are separate control mechanisms for separate deployment models, not layers of one combined stack you configure together on a single tool call - an architect has to know which runtime a given agent actually runs on before reaching for either one. An architect who audits only one layer, or who assumes they compose freely, has not closed the gap this objective tests.
How each certification frames it
CCA-P: How CCA-P tests authentication and authorization
CCARP-D3-O2Analyze authentication and authorization requirements to identify security gaps
The Professional guide asks candidates to analyze authentication and authorization requirements to identify security gaps (PDF page 5, Domain 3). The task is diagnostic: find the gap in a described configuration, such as a write tool the task never needed.
Strong answers separate three questions: is the caller identified, is this action permitted for that caller, and is the limit enforced by something other than the model's good behavior.
CCD-F: How CCD-F tests identity, secrets and keys
CCDVF-D7-O4Identity, Secrets, and Key Management: managing secrets, credentials, and API keys across Claude development and production environments, including identity validation and authentication, access approval and level verification, and authorized access monitoring
The CCD-F objective is the build-side view: managing secrets, credentials and API keys across Claude development and production environments, including identity validation and authentication, access approval and level verification, and authorized access monitoring (PDF page 8, Domain 7).
The same principle applies on both certifications: least privilege, enforced in code or configuration. Do not carry CCA-P scenario conventions into CCD-F answers or the reverse.
How it works
MCP authorization is transport-scoped, not universal. HTTP-based MCP transports SHOULD implement OAuth-based authorization - MCP servers MUST expose OAuth 2.0 Protected Resource Metadata per RFC 9728 - while STDIO transports SHOULD NOT; they instead pull credentials from the local environment. Critically, MCP authorization is OPTIONAL by spec, so a server can legally expose tools with zero auth. Treat auth requirements differently per transport choice, and audit which servers actually enforce it rather than assuming the spec guarantees it.
The Claude Agent SDK enforces tool access via layered permission rules: allowedTools/disallowedTools, permission modes, and a canUseTool runtime callback. Deny rules from disallowedTools and settings.json always block, even in `bypassPermissions` mode - this is a hard floor, not a default that a looser mode can override. These rules apply when you are running an Agent SDK / Claude Code-based harness that you orchestrate yourself.
Managed Agents API governs tools by execution type, not uniformly, via a separate mechanism. Per-tool permission policies (always_allow, always_ask) apply to server-executed pre-built and MCP tools on a Managed Agents session - a declarative policy set at agent-configuration time, evaluated server-side, not a runtime callback in your own code. Custom, application-executed tools are not policy-governed by the platform - their access control is the integrator's own responsibility. Do not conflate the two mechanisms: PreToolUse hooks and canUseTool are Agent SDK constructs for a self-orchestrated harness; always_allow/always_ask policies are Managed Agents constructs for a server-hosted session - a given tool call is governed by whichever one matches the runtime it actually executes on, not both at once.
Non-human identity is the emerging failure class. Agents holding long-lived API keys, chaining across systems, and acting outside business hours break assumptions baked into human-oriented IAM. The shift is toward short-lived, scoped, auditable credentials per agent/tool pair rather than one shared service-account key, often behind a dedicated agent-governance layer (a policy/identity/audit plane between the agent and every downstream system) so every tool call passes the same check regardless of agent or model.
Secrets and credential lifecycle management spans dev and prod separately (CCDVF-D7-O4). An architect must maintain distinct credential sets per environment - a dev-scoped API key must never be valid against a prod resource, and vice versa - stored in a secrets manager (not committed to source or baked into an agent's system prompt), rotated on a defined cadence, and scoped to the narrowest permission the tool actually needs. Promotion from dev to prod should re-issue credentials rather than copy them forward, so a leaked dev key has no prod blast radius. Identity validation and access-level verification happen at issuance (who/what is this credential for, and what is it allowed to touch) and again at every use.
Authorized-access monitoring is the other half of CCDVF-D7-O4, not an optional add-on. Every credential use should be logged with enough context to answer "which agent, which tool, which environment, when" after the fact - and that log should feed alerting on anomalies (a dev key used against a prod endpoint, a refund tool invoked outside business hours, a spike in denied-permission attempts) rather than sitting unread until an incident forces a manual audit. This is the same non-human-identity monitoring problem as above, applied specifically to the dev/prod boundary this objective names.
Worked example (Agent SDK / self-orchestrated harness). An enterprise support agent runs as a Claude Agent SDK harness that reads a CRM, issues refunds in a billing system, and calls an internal MCP server for order lookups. The architect should NOT grant one shared API key with billing-write scope to the whole agent: CRM/order-lookup MCP tools get read-only, short-lived tokens; the refund tool is gated by a PreToolUse hook that pauses for human approval above a threshold; STDIO-local tools (file/shell access) inherit environment credentials scoped to a sandboxed execution user, never the agent's own broad identity. If the same agent instead ran as a Managed Agents session, the refund gate would be an always_ask per-tool policy configured on the agent, not a PreToolUse hook - the mechanism changes with the runtime, the least-privilege goal does not.
Worked example: a permission matrix for a support agent
Authored teaching example, not a bank question.
A support agent needs to look up orders and issue small refunds. The first draft gives it four tools, including a general account-admin tool 'to be safe'.
| Tool | Class | Decision | Where enforced |
|---|---|---|---|
| lookup_order | Read | Allow | Allow rule |
| issue_refund | Write, capped | Allow with cap and escalation above it | Tool code plus hook |
| update_address | Write | Reject, no task needs it | Not exposed; deny rule |
| admin_close_account | Admin | Reject, no task needs it | Not exposed; deny rule |
The agent holds two tools instead of four, and the only write path has a limit that survives prompt injection or a model mistake. Check afterwards that the permission mode is not bypassPermissions: listed allowed tools do not constrain that mode.
How this decision goes wrong
Confusing authentication with authorization
Looks right: The agent signs in with a valid service identity, so its calls are trusted.
Why it fails: A valid identity only says who is calling. A broad credential still lets a confused or manipulated agent do anything that identity may do.
Instead: Authorize per tool and per action. Issue the agent a credential scoped to its task, not a shared administrator key.
Treating logging as permission enforcement
Looks right: Every tool call is logged, so misuse will be caught.
Why it fails: A log records an action after it happened. It does not stop a refund from being issued or a record from being changed.
Instead: Block at the point of execution with deny rules, hooks or limits in the tool, and use logs to review and to alert.
Relying on an allowed-tools list in bypass mode
Looks right: The configuration lists only safe tools as allowed.
Why it fails: Anthropic documents that allowed_tools does not constrain bypassPermissions mode: unlisted tools fall through to the mode, which approves them.
Instead: Use deny rules for anything that must stay blocked, and avoid bypassPermissions outside a controlled sandbox.
Where you'll see it
Enterprise support agent (Agent SDK)
CRM/order-lookup MCP tools get read-only short-lived tokens; the refund tool is gated by a PreToolUse hook so a human approves above a threshold.
Same agent as a Managed Agents session
The refund gate becomes an always_ask per-tool policy configured on the agent instead of a PreToolUse hook - same least-privilege goal, different mechanism because the runtime differs.
Show 1 more examples
Regulated dev-to-prod pipeline
CCDVF-D7-O4's Security & Safety domain: distinct, re-issued credentials per environment (never copy a dev key into prod), scoped to least privilege, with access-use logging that alerts on anomalies like an off-hours spike in approvals or a dev-issued key touching a prod resource.
Decision tree
Is this MCP tool served over HTTP or STDIO?
Is the agent a self-orchestrated Agent SDK harness, or a Managed Agents session?
allowedTools/disallowedTools, permission modes, and canUseTool/PreToolUse hooks in your own code.always_allow/always_ask policies set at agent configuration time - a different, server-side mechanism, not a hook you write.Is the tool platform-executed (pre-built or MCP) or custom/application-executed?
always_allow / always_ask) if running as a Managed Agents session.canUseTool/PreToolUse hooks, whereas a Managed Agents session must authorize the agent.custom_tool_use event before your app returns the result.Does the action cross a risk threshold (e.g. refund amount, data write)?
PreToolUse hook on an Agent SDK harness, or an always_ask policy on a Managed Agents session - so a human approves before execution.Does the credential or tool cross a dev/prod environment boundary?
How each cert tests this
CCA-P
Architect - Professional (D3 · Integration): tests identifying auth/authz GAPS across an agent's integration surface - which transport requires OAuth, which tools are policy-governed by the platform, and where a shared broad credential violates least privilege.
CCD-F
Developer - Foundations (D7 · Security & Safety): tests concrete implementation - managing secrets, credentials, and API keys across dev and prod environments, identity validation and authentication, access approval and level verification, and authorized-access monitoring.
The exam trap
Candidates often assume "MCP has OAuth, so it's secure by default." The spec explicitly makes authorization optional and transport-dependent - an architect who doesn't audit which MCP servers actually enforce OAuth 2.0 Protected Resource Metadata (vs. running open) has a live security gap, which is precisely what this objective tests.
Question patterns
CCA-P practice questions
4 approved CCA-P questions for this topic. Tap an answer to check it, then read the rationale for every option.
A multi-agent system has a lead agent spawn five subagents to each independently propose a fix for the same bug in a shared codebase, then apply whichever fix returns first. In production this caused two subagents' file edits to overwrite each other in a race condition. What is the core orchestration design flaw?
CCD-F practice questions
2 approved CCD-F questions for this topic. Tap an answer to check it, then read the rationale for every option.
A team connects Claude to an internal MCP server over a local STDIO transport and concludes "MCP has OAuth built in, so our tool access is secure by default." What is the flaw in this reasoning?
Frequently asked
Showing 6 of 6 questions
Sources and next steps
- Claude Certified Architect - Professional Exam Guide v1.0 (July 2026), PDF page 5, section: Domain 3: Integration and Domain 4: Evaluation, Testing & Optimization, detailed objectives. Checked 2026-10-16.
- Claude Certified Developer - Foundations Exam Guide v1.0 (July 2026), PDF page 8, section: Domain 7: Security and Safety (Identity, Secrets, and Key Management). Checked 2026-10-16.
- Configure permissions (Claude Agent SDK docs), section: How permissions are evaluated; Allow and deny rules. Checked 2026-10-16.