AI Security / Governance

Frameworks and practical guidance for securing AI systems — starting with identity.

AI Identity

I think about enterprise identity as three separate planes now, not one. People, AI agents, and APIs/service accounts each authenticate differently, fail differently, and need to be reviewed on a different clock. Most IAM programs were built around the first plane and are only now catching up to the fact that the other two have quietly become the larger population in most environments — machine and agent identities now routinely outnumber human accounts by a wide margin. A framework built for onboarding and offboarding employees doesn't hold up well once you point it at an autonomous agent that spins up, acts, and disappears in minutes.

Identity Plane Overview

Identity Plane	Entity Type	Auth Mechanism	Lifecycle	Risk Profile	Governing Standard
👤 People	Employees, admins, vendors	MFA, passkeys, FIDO2, SAML/OIDC	Joiner-Mover-Leaver	Credential theft, insider misuse	RBAC / ABAC + PAM
🤖 AI Agents	Autonomous agents, orchestrators, sub-agents	DIDs, verifiable credentials, mTLS	Ephemeral, scoped to a task	Hijacked goals, escalation, runaway delegation chains	Agentic IAM + Zero Trust
🔌 APIs / NHIs	Service accounts, bots, workload identities	API keys, OAuth 2.1, service tokens	Provisioned once, rarely cleaned up	Over-broad grants, key sprawl, no offboarding	CIEM + secret rotation

Criticality Tier Model

Not every identity deserves the same scrutiny, so I sort all three planes into one shared tier system — a single risk ladder that a human account, an agent, and a service account can all sit on side by side. It's what lets a policy engine treat "how risky is this identity" as one question instead of three separate ones.

A person, an agent, and a service account can all land on the same rung — and the auth control tightens the same way regardless of which of the three planes got them there.

Tier	Label	Example Identities	Access Scope	Auth Control	Review Cadence	Blast Radius if Compromised
T0 — Critical	Crown jewel	Root/admin accounts, agents with production write access, core infrastructure APIs	Full / unrestricted	PAM + just-in-time + hardware token	Continuous	Catastrophic
T1 — High	Privileged	Agents touching finance or HR data, senior admins, cross-tenant service accounts	Elevated but scoped	MFA + short-lived certs + RBAC	Weekly to monthly	Severe
T2 — Medium	Standard	Everyday employee SSO, read-only agents, typical API consumers	Role-scoped	SSO + OIDC + ABAC	Quarterly	Moderate
T3 — Low	Minimal	Public read-only APIs, sandbox/test agents, external partner tokens	Minimal, sandboxed	API key + rate limits	Twice a year	Low

Design Architecture by Identity Plane

👤 People IAM — the plane we already know how to run

Human IAM is mature, but it still needs to be wired into the newer controls below.

Passkeys over passwords — FIDO2/WebAuthn removes the credential-theft attack surface almost entirely, rather than just making passwords harder to guess.
One federated identity provider — Entra ID, Okta, or Ping as the hub, with SCIM/OIDC/SAML handling provisioning and de-provisioning automatically instead of by ticket.
PAM for anything tier T0/T1 — admins and security operators go through a privileged-access vault with recorded sessions and just-in-time elevation, not standing admin rights.
Step-up auth driven by risk signals — an unfamiliar device, location, or login time should trigger re-authentication automatically rather than waiting for a human to notice.

🤖 AI Agent IAM — the plane the old playbook doesn't cover

Agents are autonomous and short-lived, and permissions can cascade across a chain of sub-agents in ways a static role model was never designed to track.

Every agent has a named human sponsor — someone accountable for what it's allowed to do and how it behaves. An agent with no owner is a liability, full stop.
Verifiable credentials instead of long-lived tokens — decentralized identifiers and short-lived, cryptographically verifiable credentials keep a traceable record through multi-agent delegation chains, which a static OAuth token can't provide.
Govern the action, not just the access grant — a role-based permission list tells you what an agent is allowed to touch, not what sequence of actions it's actually attempting. Runtime policy needs to evaluate intent, not just static scope.
Keep a bill of materials per agent — what it can reach, what it reads and writes, which tools it can invoke, which model it runs on, and what tier it's been assigned.
Revocation has to be instant — an agent can act at machine speed, so a kill switch that runs on a nightly batch job is effectively useless.

How those controls typically scale by tier:

Control	T0 Agent	T1 Agent	T2 Agent	T3 Agent
Human approval gate	Before every action	Before writes/deletes	Only for sensitive data	Not required
Credential lifetime	Minutes	Hours	Days	Days to weeks
Audit logging	Every action, full delegation chain	Writes and external calls	Summarized	Sampled
Network egress	Locked down, micro-segmented	Allowlisted destinations	Standard policy	Open, rate-limited
Tool/API scope	Narrow, pre-approved list	Scoped to the task	Broad read access	Public APIs only

🔌 API & Non-Human Identity IAM — the plane nobody's watching

Service accounts and API keys are usually the largest identity population in an environment and, in my experience, the least reviewed — many outlive the project they were created for, and few teams have a real process for retiring them.

No standing secrets — replace long-lived API keys with short-lived OAuth 2.1 tokens or workload identity federation (GitHub Actions OIDC, AWS IAM Roles Anywhere, and similar).
CIEM as an ongoing discipline — keep scanning for service accounts with more access than they use, unused grants, and entitlements that have quietly piled up.
Token exchange for delegated calls — when an agent calls an API on a user's behalf, RFC 8693 token exchange keeps both identities — the human and the agent — visible in the resulting token, so the audit trail doesn't lose the thread.
Segment the network around agent-facing APIs — so a compromised agent can't use that foothold to reach systems it was never meant to touch.

Zero Trust Principles Across All Tiers

The same "verify, don't assume" posture should apply whether the identity is a person, an agent, or a service account.

Verify continuously — network location or an existing session shouldn't count as proof of trust on their own.
Grant the minimum, revoke it fast — access matches the task at hand and disappears the moment the task ends.
Judge the sequence, not just the request — for agents especially, what matters is the pattern of actions it's taking, not whether any single call was technically permitted.
Feed identity signals into detection — human and agent behavior baselines belong in the same SIEM/SOAR pipeline, so deviations trigger a response automatically.

Why the Old Standards Don't Cover Agents

OAuth 2.1, SAML, and OIDC assume one entity authenticating at a time, with coarse-grained, relatively long-lived permissions. That model doesn't have a way to represent a chain of delegation across several agents, doesn't handle credentials that need to expire in minutes rather than months, and was never designed for something acting on its own initiative at machine speed. It's less that these standards are broken, and more that they were solving a different problem than the one multi-agent systems now present.

The Cloud Security Alliance's MAESTRO framework, published in 2025, is one of the first serious attempts to model multi-agent threats directly — supply-chain risk in the identity tooling itself, one agent escalating privilege through another, and agents pursuing a subtly wrong goal in ways that abuse otherwise-valid access.

The job has shifted from proving who someone is to accounting for what an identity — human, agent, or machine — actually did, and why.