Governing AI agents: a 2026 checklist

What identity and access controls do AI agents need?

Every agent needs a distinct, governed identity, not a shared API key. Access should be least-privilege and just-in-time: an agent gets only the scope a task requires, only while it needs it, with automatic revocation. This is the foundation, and it is the one most often skipped, because handing an agent a broad, long-lived credential is faster than provisioning a scoped identity, right up until that credential is the thing an attacker rides. Identity is where governance either starts or fails, because you cannot attribute, scope, or revoke what does not have an identity of its own.

The reason to insist on this first, before any of the flashier controls, is that every other item on the checklist quietly depends on it. Runtime containment can only halt an agent you can single out; an audit trail can only attribute an action to an agent that has an identity; revocation can only kill a credential that belongs to exactly one thing. Skip distinct identity and you are left governing a crowd, where a shared key is used by many agents and no control can say which one did what. That is precisely the condition behind the over-permissioning failures that dominate 2026 incident reports (OWASP Non-Human Identities Top 10⁴): an agent holds a broad credential it shares with others, reaches something it should not, and because the identity was never distinct, no one can even attribute the action, let alone have prevented it. Distinct, least-privilege, just-in-time identity is unglamorous and it is the single highest-leverage control on this list.

• Distinct, non-human identity per agent, with no shared credentials, so every action is attributable.
• Least-privilege, just-in-time scopes with auto-expiry, so the blast radius is small by default.
• No standing access to sensitive systems by default, so a compromised agent inherits little.

What runtime controls must you require?

Governance has to act in the moment, not in a quarterly review. Anomalous behavior should be isolated and halted at runtime, and every consequential action should be reversible with no silent moves. The distinction matters because an agent operates at machine speed: a control that only reviews behavior after the fact is a control that arrives after the damage. What you need is the ability to stop a misbehaving agent mid-run and to undo what it did, which turns a runaway from an open-ended incident into a bounded one.

It is worth being precise about why after-the-fact review, on its own, is not runtime control. A dashboard, an alert, or a nightly report tells you what an agent already did, which is valuable for learning but useless for prevention, because by the time the signal reaches a human the tokens are spent, the record is changed, or the money has moved. Runtime control means the guardrail sits in the path of the action and can refuse or pause it before it completes, and the kill switch can end a run in seconds rather than after the next review cycle. The "no silent or irreversible actions" clause is the other half: an agent that can take an action you cannot see or undo has, by definition, escaped governance, so high-risk steps, moving money, deleting records, contacting customers at scale, should either be reversible or gated behind a human approval. The test for this section is simple and unforgiving: if your only answer to "what happens when an agent misbehaves at 2 a.m." is "we would see it in the morning," you have monitoring, not runtime control.

• Runtime guardrails that halt out-of-bounds actions instantly, before they complete.
• A kill switch that halts all agents, fast, and reversibly.
• No silent or irreversible actions, with human-approval gates on high-risk steps.

How do you make AI agents auditable and provable?

If you can’t prove what an agent did, you can’t govern it. Require tamper-evident, independently verifiable records, not just logs you’re asked to trust. This is the item that most often separates a governance program that survives scrutiny from one that only looks complete, because an editable log satisfies a checkbox while failing the moment a specific action is challenged. The bar is not "do you have logs"; it is "can someone who does not trust you confirm what the agent did," which is a different and much harder standard that only tamper-evident, independently checkable records meet.

• An immutable, cryptographically verifiable audit trail, where any edit or deletion is detectable.
• Attribution on every action: who (which agent), what, when, and under which policy.
• Records provable independently of the vendor, checkable by an auditor or regulator without trusting the operator.

What resilience and compliance controls belong on the list?

Finally, the controls have to survive the threats and the frameworks that are coming. That means post-quantum protection for sensitive data and alignment with the governance frameworks your board is already asking about. Resilience and compliance are where a governance program either ages well or quietly expires: an agent secured only with today’s cryptography protects long-lived data on a clock, and a program that ignores the frameworks regulators and customers are adopting will be reworked under pressure rather than by design. Building both in now is cheaper than retrofitting them after a deadline or an incident forces the issue. The AI agent security page covers how these controls fit together in practice, while the EU AI Act compliance and NIST AI RMF pages set out the evidence each framework expects you to be able to produce.

The honesty in how you label the compliance items matters as much as having them. Alignment with the EU AI Act², NIST AI RMF³, and SOC 2 should be described as what it is, controls and evidence that support compliance, not a claim that any tool or checklist makes you compliant, because compliance depends on your whole program and is assessed by regulators and auditors, not conferred by a feature. A governance program that overstates its compliance posture is itself a risk, because it invites the reliance that fails under scrutiny. The model-agnostic requirement rounds out resilience from a different angle: models change often, and if your governance, your identity model, your guardrails, your audit trail, is wired to one specific model or vendor, every swap forces you to re-earn control you already built. Governance that sits above the model, applying the same identity, containment, and proof regardless of which LLM is underneath, is what keeps the checklist true a year from now instead of only on the day you signed.

• Post-quantum cryptography (ML-DSA / ML-KEM) for data, context, and credentials, so long-lived secrets stay protected.
• Alignment with the EU AI Act, NIST AI RMF, and SOC 2 controls, honestly labeled as evidence-supporting, never as a guarantee of compliance.
• Model-agnostic governance, so control stays consistent across LLMs rather than being re-earned with each model swap.

Is your AI agent governance production-ready?

Score your current setup, or a vendor’s, against the four sections of the checklist. The questions below take one item from each: distinct identity, runtime containment, verifiable proof, and post-quantum resilience, plus the framework alignment your board will ask about. The gaps this surfaces are the ones that keep an agentic program from shipping.