# Authentication & Access Control for Agent Systems > 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. **Domain:** CCARP-D3 · Integration (19% of the exam) **Canonical:** https://claudearchitectcertification.com/concepts/auth-and-access-control-for-agents **Last reviewed:** 2026-05-04 ## Quick stats - **Access-control layers:** 3 - **MCP transports:** 2 - **MCP auth requirement:** Optional - **Exam domain:** CCARP-D3 - **Also tested in:** CCDVF-D7 ## 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 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. ## Where you'll see it in production ### 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. ### 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 1. **Is this MCP tool served over HTTP or STDIO?** - **Yes:** HTTP: expect OAuth 2.0 Protected Resource Metadata (RFC 9728) - but verify the server actually implements it, since authorization is optional by spec. - **No:** STDIO: credentials come from the local environment - scope that execution user narrowly rather than inheriting the agent's own broad identity. 2. **Is the agent a self-orchestrated Agent SDK harness, or a Managed Agents session?** - **Yes:** Agent SDK harness: enforce access via allowedTools/disallowedTools, permission modes, and canUseTool/PreToolUse hooks in your own code. - **No:** Managed Agents session: enforce access via per-tool always_allow/always_ask policies set at agent configuration time - a different, server-side mechanism, not a hook you write. 3. **Is the tool platform-executed (pre-built or MCP) or custom/application-executed?** - **Yes:** Platform-executed: governed by Managed Agents per-tool policies (always_allow / always_ask) if running as a Managed Agents session. - **No:** Custom/app-executed: access control is the integrator's responsibility, but the MECHANISM depends on runtime - a self-orchestrated Agent SDK harness enforces it in canUseTool/PreToolUse hooks, whereas a Managed Agents session must authorize the agent.custom_tool_use event before your app returns the result. 4. **Does the action cross a risk threshold (e.g. refund amount, data write)?** - **Yes:** Gate it with the mechanism matching the runtime - a PreToolUse hook on an Agent SDK harness, or an always_ask policy on a Managed Agents session - so a human approves before execution. - **No:** Can run unattended under a scoped, short-lived, per-tool credential - never one shared long-lived key. 5. **Does the credential or tool cross a dev/prod environment boundary?** - **Yes:** Re-issue environment-scoped credentials at promotion time rather than reusing them, and confirm access-use logging/alerting covers that boundary (CCDVF-D7-O4). - **No:** Standard per-tool scoping and monitoring still apply within the single environment. ## Exam-pattern questions ### Q1. An enterprise agent connects to an internal MCP server over STDIO for local file operations, and the architect assumes it's protected because 'MCP supports OAuth.' What's the actual security posture? STDIO transports SHOULD NOT implement OAuth - they pull credentials from the local environment, and MCP authorization is optional by spec overall. The distractor "the server enforces OAuth 2.0 Protected Resource Metadata by default" is wrong: that's an HTTP-transport SHOULD, and even there it isn't guaranteed - an unaudited server can expose tools with zero auth. ### Q2. A support agent uses one shared, long-lived API key with billing-write scope across CRM lookup, order lookup, and refund tools. Security review flags this. Why? This is the "one shared identity for the whole reachable capability surface" anti-pattern - a compromised key or an unintended chain grants refund-level access to a read-only lookup task. The distractor "rotate the key more frequently" treats the symptom; the fix is short-lived, per-tool, scoped credentials, not faster rotation of one broad key. ### Q3. Which control ensures a disallowedTools rule blocks a tool call even when the session is running in bypassPermissions mode? Deny rules from disallowedTools/settings.json always block regardless of permission mode - a hard floor, not a default that bypass can override. The distractor "canUseTool always overrides disallowedTools" inverts the precedence; deny rules win. ### Q4. An architect wraps a refund tool in a Managed Agents policy but forgets the invoice-lookup tool is a custom, application-executed function. What's the access-control gap? Managed Agents per-tool policies (always_allow/always_ask) govern server-executed pre-built and MCP tools; a custom application-executed tool is not policy-governed by the platform - its access control is the integrator's own responsibility. The distractor "the platform applies the same always_ask default to custom tools" is wrong - custom tools fall outside that governance layer entirely. ### Q5. A staging (dev) API key with elevated read/write scope is found still active and reachable from the production Managed Agents deployment three months after launch, because dev and prod shared one credential from day one. What went wrong, and what's the fix? Dev and prod were never given distinct, environment-scoped credentials - the fix is to re-issue prod-only credentials at promotion time (not copy the dev key forward), narrow the scope to what the prod tool actually needs, and add access-use monitoring that would alert on a dev-issued key touching a prod resource. The distractor "rotate the shared key on a schedule" treats the symptom (an old key) without fixing the root cause (one key spans two environments); CCDVF-D7-O4 specifically tests separate dev/prod credential lifecycle, not just rotation cadence. ### Q6. A refund tool's always_ask approvals are logged, but nobody reviews them and no alert fires when approvals spike outside business hours. Is the access-control design for this tool complete? No - approval gating (who must approve) and access monitoring (is anyone watching the pattern of approvals/denials over time) are two different controls; a logged-but-unreviewed approval trail satisfies neither anomaly detection nor the authorized-access monitoring half of CCDVF-D7-O4. The distractor "logging every call is sufficient for authorized-access monitoring" mistakes passive logging for active monitoring - the objective expects alerting on anomalies (off-hours spikes, unexpected environment/key combinations), not just a queryable log. ## FAQ ### Q1. Is MCP secure by default? No - authorization is optional by spec and transport-scoped; audit which servers actually enforce OAuth 2.0 Protected Resource Metadata rather than assuming it. ### Q2. Does a shared API key across tools satisfy least privilege? No - move to short-lived, scoped, per-agent/tool credentials; a single broad key defeats the reachable-capability-surface analysis this objective tests. ### Q3. Are Agent SDK PreToolUse hooks and Managed Agents always_ask policies the same control? No - PreToolUse hooks are a programmatic, runtime callback in an Agent SDK harness you orchestrate yourself; always_ask/always_allow are declarative per-tool policies set at Managed Agents configuration time and evaluated server-side. They belong to different runtimes and are not interchangeable or stackable on the same tool call. ### Q4. What does CCDVF-D7-O4 actually expect beyond 'use short-lived credentials'? Two concrete practices: distinct, re-issued (not copied) credential sets per environment so a dev key can never authenticate against prod, and active authorized-access monitoring - logging plus alerting on anomalous credential/tool use - not just a log an architect could review if they thought to. --- **Source:** https://claudearchitectcertification.com/concepts/auth-and-access-control-for-agents **Last reviewed:** 2026-05-04 **Evidence tiers**, 🟢 official Anthropic doc / API contract · 🟡 partial doc / inferred · 🟠 community-derived · 🔴 disputed.