Non-Human Identity Architecture: Diagramming Access Control for AI Agents

A June 2026 Cloud Security Alliance whitepaper put a number on something most security teams already suspected: non-human identities (NHIs) now outnumber human identities by roughly 100 to 1 in enterprise environments. Every AI agent, every subagent it spawns, every scheduled job, and every MCP server connection is a distinct identity that needs to authenticate, hold credentials, and be governed. The same report found that more than half of organizations have no clear owner assigned to their AI-agent identities, and a large share of NHIs have gone unrotated for over a year — standing credentials quietly accumulating blast radius with no one accountable for them.

This is a distinct architecture problem from general identity and access management. Human IAM was built around a slow-moving, interactive population: employees who log in a few times a day, complete MFA challenges, and get offboarded through an HR process. AI agents break every one of those assumptions — they authenticate thousands of times per hour, spawn ephemeral sub-identities per task, and have no interactive step where a human can approve a login. This guide covers how to design and diagram a non-human identity architecture purpose-built for AI agents: the credential lifecycle, the MAESTRO reference layers for placing identity controls, just-in-time sub-identity issuance, and how scope should propagate through multi-agent delegation chains.

Why AI agents caused an NHI explosion

Non-human identities are not new — service accounts, API keys, and OAuth app credentials have existed for as long as systems have talked to each other. What changed with agentic AI is the rate of identity creation. A traditional service account is provisioned once, by a person, through a ticket. An AI agent creates new identity surface area continuously and automatically:

• Per-agent identities: Every deployed agent — a coding assistant, a support bot, a research agent — needs its own identity to call LLM APIs, databases, and internal services.
• Per-subagent identities: Orchestrator agents that spawn subagents for parallel subtasks create a new identity (or should) for each subagent instance, often hundreds of times per day and torn down just as fast.
• Per-tool-call identities: In a well-designed system, an agent doesn't use one broad credential for every action — it requests a narrowly scoped sub-identity for each tool call, meaning a single task can mint dozens of ephemeral identities that live for seconds.
• MCP server connections: Each MCP server an agent connects to typically holds its own credential set (a database connection string, a GitHub token, a Slack bot token) — every one of those is a non-human identity with its own lifecycle to manage.
• Scheduled and event-triggered jobs: Cron-triggered agents and webhook-triggered automations each need an identity that can act without a human present to approve the action.

The result is an identity population that is orders of magnitude larger, shorter-lived, and more dynamic than anything human IAM was designed to govern. Static service-account thinking — one credential, provisioned manually, rotated on a calendar — collapses under this volume. Diagramming this architecture is how teams make the explosion legible: without a diagram, no one can answer "which agent has access to what, and who is accountable for it."

The MAESTRO framework as a reference architecture

The Cloud Security Alliance's MAESTRO framework (Multi-Agent Environment, Security, Threat, Risk, and Outcome) breaks an agentic AI system into seven layers. It was designed for threat modeling, but it doubles as a useful reference architecture for deciding where identity and credential controls need to sit in your diagram — each layer has a different identity surface:

• Layer 1 — Foundation Models: The identity used to call the underlying LLM API (model provider API keys). This is usually the most static NHI in the stack but often the most over-privileged if shared across every agent.
• Layer 2 — Data Operations: Identities used for retrieval, embedding, and data pipeline access — the credentials an agent uses to read from vector stores, data warehouses, and document repositories.
• Layer 3 — Agent Frameworks: The identity issuance and session-management logic itself — the orchestration framework code that decides how an agent authenticates and what sub-identities it is allowed to mint.
• Layer 4 — Deployment & Infrastructure: Workload identities (cloud IAM roles, Kubernetes service accounts) that the agent's runtime environment holds, separate from the agent's own logical identity.
• Layer 5 — Evaluation & Observability: The identity and access boundary around audit logs and monitoring systems — who (or what) can read the record of what an agent did.
• Layer 6 — Security & Compliance: The policy enforcement layer — identity providers, policy engines, and the governance controls that decide whether a given sub-identity request should be granted.
• Layer 7 — Agent Ecosystem: Identity as it crosses trust boundaries — agent-to-agent and agent-to-external-service identities, including third-party agents your system delegates to.

Mapping your NHI architecture diagram onto these seven layers forces a useful discipline: it prevents the common failure of drawing a single undifferentiated "agent identity" box and instead makes you show exactly which layer holds which credential, and which layer is responsible for issuing, rotating, and revoking it.

Just-in-time sub-identity issuance

The core architectural pattern that separates well-governed agent identity from a liability is just-in-time (JIT) sub-identity issuance. Instead of an agent holding one broad, long-lived credential that can perform every action it might ever need, the agent authenticates once to an identity provider with its own base identity, then requests a narrowly scoped, short-lived sub-identity for each task or tool call.

The flow looks like this in a diagram: the agent authenticates to the identity provider using its own workload credential (a certificate or signed token, not a shared secret) → the agent requests a scoped credential for a specific action, e.g. "write access to this one S3 bucket for the next 5 minutes" → the identity provider consults a policy engine to check whether the request is within the agent's allowed scope → if approved, a short-lived credential (often a signed JWT with a narrow audience and a TTL measured in minutes) is issued → the agent uses that credential for the single action → the credential expires and is discarded, never reused.

This is architecturally different from how service accounts have traditionally worked. A static service account is provisioned once with a fixed permission set and used indefinitely; a JIT sub-identity is minted per use and expires by default. The advantage for AI agents specifically is that a compromised sub-identity — leaked in a log, or exfiltrated by a prompt injection — has a blast radius bounded by both scope and time, rather than granting standing access to everything the agent could ever touch.

Credential lifecycle architecture for agents vs. humans

Diagramming agent credentials requires abandoning several assumptions baked into human-identity diagrams. Agent credentials have no interactive step: there is no MFA prompt, no "approve this login" push notification, no human in the loop who can eyeball a suspicious request and decline it. That absence has to be compensated for elsewhere in the architecture:

• Automated rotation, not calendar rotation: Human passwords get rotated on a 90-day policy enforced by nagging emails. Agent credentials need programmatic rotation triggered by the identity provider itself — short TTLs by default, with rotation baked into the issuance flow rather than a separate manual process.
• Policy enforcement points (PEPs): Every place an agent credential is checked — API gateway, database proxy, MCP server, internal service mesh — is a policy enforcement point that should be drawn explicitly. A credential that is valid but unchecked at the point of use is not actually enforcing anything.
• Machine-readable audit trails: Human audit logs are written for a security analyst to read later. Agent audit logs need to be structured and machine-readable from the start, because the volume of agent actions makes manual review infeasible — the audit sink needs to support automated anomaly detection, not just storage.
• Revocation as a first-class operation: Because there's no human to notice something is wrong and stop using a credential, the architecture needs a fast, reliable revocation path — a kill switch that can invalidate an agent's identity and every sub-identity it has issued, immediately.

Identity propagation through multi-agent delegation chains

The pattern that breaks most non-human identity architectures is delegation. When an orchestrator agent spawns subagents, or calls another agent or service on behalf of a user, the naive approach is for the orchestrator to simply hand its own credential — or the original user's credential — down the chain. This is the agentic equivalent of the confused deputy problem: a subagent doing narrow, low-risk work ends up holding the same broad permissions as the orchestrator that spawned it.

A correctly diagrammed delegation chain shows scope narrowing at every hop, not identity inheritance. The orchestrator holds the broadest identity; each subagent it spawns receives a sub-identity scoped down to only what that specific subtask requires, and that sub-identity should itself be able to delegate only an equal or narrower scope if it spawns further subagents. This is typically implemented with a token-exchange pattern (e.g., OAuth 2.0 Token Exchange, RFC 8693) where each hop in the chain trades its current token for a new one with a reduced audience and scope, plus an actor claim that preserves who is actually acting — so an audit log can reconstruct "subagent C, acting on behalf of orchestrator A, on behalf of user U" rather than collapsing the whole chain into a single anonymous service identity.

This matters most when a delegation chain crosses a trust boundary — for example, an internal orchestrator calling a third-party agent over the A2A protocol. The identity that crosses that boundary should never be the orchestrator's full internal credential; it should be a purpose-issued, minimally scoped token that the external agent can use for exactly the delegated task and nothing else.

Prompt templates for diagramming non-human identity architecture

JIT credential issuance for a coding agent

Multi-agent delegation chain with scoped identity propagation

Enterprise agent identity governance platform

MCP server credential isolation

Identity type reference

What a good non-human identity architecture diagram must show

Given the scale and churn of agent identities, a diagram that just draws boxes for "Agent" and "Database" with a line between them is useless for governance or audit. A complete NHI architecture diagram makes the following explicit:

• Identity provider: The system of record that issues and tracks every agent identity — shown as a distinct node, not implied.
• Credential issuance flow: The path a request takes from "agent wants to act" to "agent holds a usable credential," including where the policy engine sits in that path.
• Scope boundaries per agent and tool: What each agent — and each sub-identity it can request — is actually allowed to do, not just what it's connected to.
• Audit log sink: Where issuance, usage, and revocation events are written, and who (or what automated system) consumes that log.
• Rotation and expiry policy: The TTL for every credential type in the diagram, and what automatically happens when a credential expires or is revoked.
• Human-owner mapping: Which person or team is accountable for each agent identity. This is the single most commonly missing element, and the one the Cloud Security Alliance whitepaper flags as the biggest governance gap — over half of organizations surveyed have agent identities with no assigned owner.

Common mistakes in non-human identity architecture

These are the failure patterns that show up repeatedly in both real-world incidents and in NHI architecture reviews:

• Sharing one long-lived API key across dev, staging, and production agents — a leak or bug in one environment compromises all of them
• No owner assigned to an agent identity — when something goes wrong, there is no one to page, and the identity often outlives the project that created it
• Standing, broad-scope credentials instead of JIT scoped ones — an agent holding permanent write access to everything it might ever need, rather than requesting narrow access per action
• No expiry or rotation — credentials that were valid on day one and are still valid, unchanged, a year later
• No audit trail of which agent or subagent took which action — delegation chains that collapse into a single anonymous service identity in the logs, making incident reconstruction impossible
• Treating agent identities like human identities in the IAM system — bolting agent accounts onto a human-oriented IAM tool that assumes interactive MFA, seat-based licensing, and manual quarterly access reviews, none of which scale to thousands of ephemeral identities
• Orchestrators handing subagents their own full credential instead of a narrower delegated one — the confused-deputy pattern that lets a low-risk subtask run with high-risk permissions

Frequently asked questions about non-human identity architecture

What is a non-human identity in the context of AI agents?

A non-human identity (NHI) is any credentialed identity that isn't a person — service accounts, API keys, OAuth app credentials, and increasingly, the identities AI agents and subagents use to authenticate to systems on their own. What makes agent NHIs distinct from traditional service accounts is volume and lifespan: an orchestrator agent can mint dozens of short-lived sub-identities per task, whereas a traditional service account is provisioned once and used for months. Architecting this well requires the same rigor applied to zero-trust architecture — verify every request explicitly, regardless of where it originates — applied to a population of identities that never stops growing.

How is agent identity different from general IAM or zero-trust architecture?

General IAM and zero-trust models were designed around a relatively stable population of human users and static services, with interactive verification steps like MFA as a core control. Non-human identity architecture for AI agents has to work without any human in the loop, at a scale and churn rate — thousands of new sub-identities per day, most living for seconds — that breaks calendar-based rotation and manual access review. It is a specialization of zero-trust principles for a machine-speed identity population, and it should be diagrammed and threat-modeled separately from your human IAM system. For the broader threat surface AI agents introduce beyond identity, see our guide to agentic AI security architecture and threat modeling diagrams.

How do I diagram identity for a multi-agent system?

Start with the identity provider and policy engine as central nodes, then draw each agent and subagent as a node that requests scoped credentials from that identity provider rather than holding one standing credential. Show the delegation chain explicitly — when an orchestrator spawns a subagent, the diagram should show a narrower scope being issued to the subagent, not an arrow implying the subagent inherited the orchestrator's full permissions. For the orchestration patterns this identity model sits on top of, see our guide to multi-agent orchestration patterns, and for the credentials individual tool connections hold, see the MCP architecture diagram guide. If you need to document this for a compliance audit, our SOC 2 architecture diagram guide covers how to present access-control evidence to auditors.

Related guides: Zero-trust architecture diagrams, threat modeling diagrams, multi-agent orchestration patterns, MCP architecture diagrams, and agentic AI security architecture.