Authentication & Access Control for Agent Systems.

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.

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.