Playbook / AI system design / Design identity and access management for AI agents and MCP tools

Design identity and access management for AI agents and MCP tools

Expected question

"Design an IAM system for enterprise AI agents that discover and call tools through MCP. How do you preserve end-user identity, isolate tenants, and prevent an agent from exercising ambient credentials or escalating its own permissions?"

Variant forms

  • "Design a cloud IAM control plane for thousands of non-human AI-agent identities."
  • "Build an MCP gateway that federates internal and third-party tools across many tenants."
  • "How should OAuth delegation work when an agent acts on behalf of a user?"
  • "An agent can see a tool but the user cannot use the underlying resource — where is access denied?"
  • "Design short-lived, least-privilege credentials for autonomous background agents."
  • "How do you revoke one agent, one tool, or one delegated user grant without stopping the fleet?"
  • "Compare agent identity, user identity, workload identity, and tenant identity."
  • "MCP standardizes tool calls; what security and governance does it not provide?"

Where this actually gets asked

Two public question reports make this more than a speculative 2026 topic: Hello Interview lists an AI-agent IAM design question as asked at Google, and lists an MCP tool-discovery and invocation design as asked at Palantir. Those reports establish the archetypes, not the exact combined wording above. The combined prompt is the Staff+/Principal version: protocol mechanics are easy; preserving identity and enforcing authorization across a tool federation is the real architecture problem.

Executive summary

30-second thesis

I'd give agents first-class identities and least-privilege tool grants — MCP standardizes calls, not trust. Federate tools through a broker that can revoke, audit, and scope; never let a connector become ambient admin.

2-minute answer

I'd start with the principal chain: tenant, user/service, agent workload, mission — verified at every hop, never inferred from model text. Effective permission is the intersection of user rights, agent allowlist, tenant policy, mission scope, and resource ACL. An agent doesn't inherit everything its human owner can touch unless the delegation grant says so.

Discovery is an authz surface: filter the catalog before the model sees tool names and schemas. Authorize each call; high impact needs step-up or HITL. Gateway mints a short-lived, audience-bound execution token tied to the call digest — so you can't approve a harmless payload and execute a different one. Downstream resources still enforce their own ACLs; otherwise the gateway is a confused deputy.

Revocation in seconds; side-effect policy failure is fail-closed. Limitation I'll own: MCP onboarding is continuous supply-chain review — a remote server can change descriptions after day one.

What I'd ask them: Which tools are high-risk day one? Per-tenant catalogs? Existing OAuth/OIDC? Kill-switch granularity they need?

Quantitative trade-offs

DecisionTrade-off and reversal evidenceEvidence class
Central broker vs point-to-point MCPBroker gives policy/audit control; point-to-point is faster to demo. Reverse to broker before irreversible production side effects.H
Short-lived tokens vs long sessionsShort tokens reduce theft blast radius; reverse longer TTLs only with continuous step-up auth.H
Per-tool grants vs role bundlesFine grants are safer; bundles are operable. Reverse bundles after over-privilege incidents.H

Numbers and thresholds in interview delivery should be labeled H unless the candidate can defend a measured baseline. Open repositories are O; researched public patterns are R. Do not upgrade O/R into employer P adoption.

Migration and rollout

This is an IAM / broker cutover. Demos love point-to-point MCP; prod needs revocation.

  1. Register agents and MCP servers as identities with owners — no anonymous connectors in prod.
  2. Broker in observe mode: catalog filtering + authorize decisions logged while old direct connectors still execute.
  3. Flip high-risk tools to broker-minted short-lived tokens only. Prove revoke-in-seconds in a drill.
  4. Onboard remaining tools tenant-by-tenant; supply-chain review for remote MCP description drift is continuous, not a day-one checkbox.
  5. Rollback = previous connector allowlist with broker deny-all. Kill switch = revoke server or agent identity.

Org ownership and operating model

  • Identity / IAM owns agent identities, delegation grants, and token audiences.
  • Agent platform owns the MCP broker, catalog authz, and call digest binding.
  • Security owns high-risk tool classification and step-up / HITL policy.
  • Tool / connector owners own downstream ACL enforcement (gateway is not a confused deputy escape hatch).
  • Compliance owns audit retention for who delegated what to which agent.

Requirements

Functional

  • Register agents, MCP servers, tools, and versions as independently revocable identities.
  • Authenticate the human, workload, agent, and tenant; never infer any of them from model text.
  • Show each agent only the tools allowed for its principal, tenant, mission, and risk tier.
  • Exchange a user/agent grant for a short-lived, audience-bound execution token per tool call.
  • Require step-up authentication or HITL before high-impact side effects.

Non-functional

  • Authorization is enforced at the gateway and again by the resource; the model is never a policy enforcement point.
  • Tenant and user context cannot leak through tool catalogs, caches, sessions, logs, or credentials.
  • Revocation reaches new calls within seconds; an already issued token has a very short lifetime.
  • Every decision is attributable to user, agent, tool, policy version, and mission.
  • Control-plane failure is fail-closed for side effects and explicitly degraded for safe reads.

Core entities

  • Principal chain: tenant → user/service → agent → mission, with verified IDs at every hop.
  • Agent identity: workload identity plus allowed model, tools, risk tier, and owner.
  • Tool descriptor: namespaced server/tool ID, schema digest, version, risk class, and audience.
  • Delegation grant: who delegated what scopes to which agent, for which purpose and duration.
  • Execution token: single-audience, short-lived token bound to agent, user, tool, and call digest.
  • Policy decision: allow / approval-required / deny plus policy version and reason.
  • Audit event: tamper-evident record linking discovery, authorization, execution, and result.

API / interface

POST /v1/agents
{"tenant_id":"ten_acme","name":"refund-assistant","owner":"team_support",
 "tools":["crm.read","payments.refund"],"max_risk":"high"}
→ 201 {"agent_id":"agt_...","workload_identity":"spiffe://acme/agents/agt_..."}

GET /v1/mcp/tools
Authorization: Bearer <user_and_agent_session>
→ 200 {"tools":[{"name":"crm.read","schema_digest":"sha256:...","risk":"read"}]}

POST /v1/tools/payments.refund/authorize
{"mission_id":"mis_...","user_id":"usr_...","amount_cents":4200,
 "call_digest":"sha256:...","idempotency_key":"..."}
→ 200 {"decision":"approval_required","approval_id":"apr_..."}
→ 403 {"decision":"deny","reason":"scope_or_resource_denied","policy_version":"p17"}

POST /v1/approvals/{approval_id}/decision
{"decision":"approve","approver_id":"usr_manager","step_up_proof":"..."}
→ 200 {"execution_token":"et_...","aud":"payments.refund","expires_in_sec":30}

POST /v1/mcp/call
Authorization: Bearer <execution_token>
{"tool":"payments.refund","arguments":{...},"call_digest":"sha256:..."}
→ 200 {"result":{...},"audit_id":"aud_..."}

The execution token is useless for another tool or altered arguments. The gateway injects downstream credentials after authorization; neither the prompt nor the MCP client receives them.

Data Flow

Rendering architecture diagram…

High-level design

Rendering architecture diagram…

MCP standardizes discovery and invocation. It does not establish that a server is trustworthy, that the caller may use every advertised tool, or that a proposed action is authorized. Agent IAM owns those decisions outside the model and protocol adapter.

Deep dive 1: preserve the principal chain

A service account shared by all agents destroys attribution and often over-authorizes every call. Carry four identities separately:

IdentityAnswersMust not be replaced by
TenantWhich isolation and policy domain?Request body tenant_id
User/serviceOn whose authority?The agent's own identity
Agent workloadWhich software actor?A model-supplied agent name
MissionFor what bounded purpose?A reusable global session

The effective permission is the intersection, not the union, of user rights, agent allowlist, tenant policy, mission scope, and resource ACL. An agent cannot gain access merely because its human owner can access a resource; the delegation grant must include that resource and purpose.

Deep dive 2: tool discovery is an authorization surface

Filtering only at execution still leaks tool names, descriptions, schemas, and sometimes sensitive resource metadata into the model context. Filter the catalog before returning it, namespace tools as server.tool, pin a schema digest/version, and repeat authorization at execution. A malicious or changed remote server can alter descriptions or results after onboarding, so registry approval is continuous supply-chain governance, not a one-time install checkbox.

Deep dive 3: credential and confused-deputy defense

The gateway exchanges the verified principal chain for a short-lived token whose audience is one tool/resource and whose scopes are no broader than the delegation. Bind it to the normalized call digest so the agent cannot obtain approval for a harmless payload and execute a different one. Downstream resources still apply row-level/resource-level authorization. That second check prevents the gateway from becoming a confused deputy with universal access.

Deep dive 4: revocation, scale, and failure

Cache positive policy decisions only for low-risk reads and key them by principal chain, tool version, resource, and policy version. Do not cache side-effect approvals. Push revocation events to gateways, keep execution tokens short-lived, and maintain kill switches by tenant, agent, server, tool, and mission. Under policy-store failure, deny writes; a documented stale-read mode may serve low-risk tools only if the resource independently enforces current ACLs.

Staff+/Principal signal rubric

  • Mid-level: API keys, roles, and a tool allowlist.
  • Senior: separate user and agent identities; short-lived scoped tokens; tenant isolation.
  • Staff+: principal-chain intersection, catalog filtering, argument-bound authorization, resource-side enforcement, and revocation.
  • Principal: treats MCP as protocol rather than security; designs delegated identity, confused-deputy defenses, tool supply-chain governance, policy-versioned audit, and explicit fail-closed/degraded behavior.

Follow-up questions to expect

  • "Why not let the MCP server authorize everything?" — It can't enforce fleet-wide agent, mission, and tenant policy. Keep resource ACLs there; centralize cross-tool governance at the gateway.
  • "Can one agent delegate to another?" — Only via a new, narrower grant with preserved lineage. Never forward the first agent's bearer token.
  • "What if a remote MCP server changes after approval?" — Pin identity/schema/version, quarantine on drift, treat output as untrusted. One-time install is not governance.
  • "How do you keep this out of the 45-minute weeds?" — Draw principal chain, catalog filter, authorize/approve/execute, credential broker, resource ACL. Defer IAM UI.
← Design enterprise hybrid retrieval with access-aware rankingDesign a real-time fraud and risk decisioning system →