AI Agent Governance: The Checklist a Room Full of CISOs Actually Agreed On

Quick answer: Treat every AI agent like a service account with its own scoped identity, enforce guardrails at the tool/API layer instead of only in the prompt, and require a human-in-the-loop approval gate for high-impact actions. Map your controls to NIST AI RMF, ISO 42001, and the OWASP Top 10 for Agentic Applications, and use the vendor scorecard below before you approve a new agent for production.

Bruce Schneier ran a closed-door roundtable for senior security leaders on the one governance question nobody has fully solved: what do you do when your AI agents are doing real work, and something goes wrong? The room didn't leave with a finished framework. It left with sharper questions - and a surprising amount of consensus on where to start. Here's what the CISOPlatform community can take from it.

Why this is urgent now

The room agreed on one thing immediately: liability is settling on the organization, not the vendor or the model. Recent rulings point the same direction - a German court treated an AI Overview as the search engine's own statement and issued an injunction after it falsely linked two publishers to scams; a Canadian tribunal held an airline responsible for its own chatbot's bad advice, rejecting the argument that the bot was somehow a separate party. "The agent did it, not me" is holding up about as well as "the employee did it" always has - and a mistake that would be a one-off human error becomes, at machine speed, a mistake repeated ten thousand times before anyone notices.

What the room put on its risk register

Accountability sits with you. The legal answer is arriving faster than the operational one - build the evidence trail now.

Agents are privileged identities. Give each one its own identity and the least privilege needed for one job - the same discipline you'd apply to a network engineer holding the keys to everything.

Non-determinism breaks auditability. Ask an agent the same question twice, get two different answers - that's a control problem, not a quirk.

No explainability, no training. Security-awareness training only works if a user can see the downstream consequence of what they asked an agent to do.

Shadow AI compounds. Approve ten agents, discover fifty - an agent can spin up more agents, so a small gap multiplies fast.

Hallucination is dangerous exactly where you can't verify. FireCompass's own pentest agents fabricated vulnerabilities early on - recoverable because a finding can be tested. Most enterprise outputs can't be checked that cheaply.

What the room converged on as controls

Inventory first. Know which agents exist, who owns them, what they can access - and write down the intended non-use cases as explicitly as the use cases.

Enforce identity at runtime, deterministically. ISO 42001 and the NIST AI RMF are the bars auditors are starting to apply - neither is an identity standard, but both expect documented governance and full auditability.

Human-in-the-loop is a supervisor, not a scalable control. A human reviewing every action becomes the bottleneck. Useful, but don't mistake it for a finished system.

Consider adversarial agents. A council of agents that check and challenge each other may govern better than trying to teach one model to reason cautiously - anything built on language can be socially engineered.

Run your existing controls, faster. Asset inventory, data classification, RBAC, drift checks - mostly the same discipline you already have, just on a much faster cadence.

Watch for eroding oversight. As agents get more reliable, the humans watching them get worse at catching the rare failure - not enough fires to keep the firefighters sharp. Re-validate on a schedule, don't wait for the near-miss.

How FireCompass applies this to its own pentest agents

One rule anchors the whole system: never let one probabilistic model police another for anything critical. That produces a hybrid, not a purely AI, system - deterministic, rule-based guardrails sit alongside the AI rather than more AI layered on top to supervise it. Disruptive actions are removed at the tool level, not "discouraged" at the prompt level: if an agent can't reach the tool, it can't do the damage, no matter what it plans.

Put this into practice: Verified CISOPlatform members can request a free AI-powered pentest of their own attack surface from FireCompass - a hands-on way to see where your own agentic exposure already stands before you write the policy. Join the community to redeem yours.

Forum seed question: Where is your organization on agent governance right now - inventory and policy on paper, or actually enforced at runtime? What's the one control you haven't gotten to yet?

The frameworks catching up to this problem

NIST launched an AI Agent Standards Initiative in February 2026, explicitly acknowledging the governance gap agentic systems created - voluntary guidelines are expected to cover identity and authorization, security and risk management, and monitoring and logging, with an AI Agent Interoperability Profile targeted for Q4 2026. Until then, the Cloud Security Alliance's NIST AI RMF Agentic Profile extends the original Govern/Map/Measure/Manage functions with agent-specific controls, and the newest guidance (May 2026) organizes agentic risk into five categories worth knowing by name: privilege risks, design and configuration risks, behavioral risks, structural risks, and accountability risks. OWASP's companion Top 10 for Agentic Applications (2026) covers the attacker's side of the same problem - uncontrolled autonomy, delegated identity abuse, and cross-agent prompt injection chief among them. ISO 42001 rounds it out on the management-system side: if you're being audited, expect assessors to ask for your AI risk assessment methodology, your Statement of Applicability, and evidence of an impact assessment for every AI system that touches people - employees, customers, or third parties.

Is your organization actually ready to deploy AI agents? A readiness checklist

Do you have a living inventory of every agent in production - what it does, who owns it, and what it can access?
Does each agent run under its own scoped machine identity, or does it share a service account with broader privileges than it needs?
Is least privilege enforced at the tool-call level (the agent literally cannot invoke a disruptive action) rather than only "discouraged" in a system prompt?
Can every agent action be reconstructed after the fact from an immutable log - not just the final output, but the reasoning and tool calls that produced it?
Do you have a documented answer for what an agent is not allowed to do, as explicit as your list of what it is allowed to do?
Have you mapped which agents can create or invoke other agents - and put a hard limit on that chain?
Is there a human-in-the-loop approval gate for a defined class of high-impact actions, with a named owner for that approval?
Have you red-teamed your own agents for prompt injection and cross-agent manipulation, not just the underlying model?
Do you re-validate agent behavior on a fixed schedule, rather than waiting for a near-miss to trigger a review?

Questions to ask any AI agent platform vendor

How is identity and authorization enforced per agent - scoped tokens and OAuth, or a shared credential across all agents?
Can permissions be scoped per tool, per agent, per task - or is it all-or-nothing access to a toolset?
What's logged, is the log immutable, and can it export to our SIEM in a format we can actually query during an incident?
How does the platform contain a compromised or malfunctioning agent so it can't cascade into other agents or systems?
Where are human-in-the-loop approval gates configurable, and by whom?
Have you red-teamed your own product for prompt injection, tool misuse, and cross-agent manipulation - can we see that report?
What's your incident response process and notification SLA if an agent takes a harmful action in a customer's production environment?
Do your controls map to NIST AI RMF, ISO 42001, or the OWASP Top 10 for Agentic Applications - can you show us the mapping, not just claim alignment?

RFP criteria for agentic AI platforms

Criterion	What "good" looks like
Identity model	Unique scoped identity per agent, not a shared credential
Guardrail enforcement layer	Enforced at the tool/API layer, not only via prompt instructions
Audit and logging	Immutable, exportable, includes reasoning path and tool calls
Human-in-the-loop configurability	Admin-configurable approval gates for defined high-impact actions
Agent-spawning controls	Hard limits and approval requirements on agents creating other agents
Red-team history	Vendor discloses their own adversarial testing results, not just marketing claims
Framework mapping	Documented mapping to NIST AI RMF, ISO 42001, OWASP Agentic Top 10
Incident response SLA	Defined notification and containment timelines in the contract
Data residency and handling	Clear answers on where agent context/data is processed and stored

Vendor evaluation scorecard

Weight identity model and guardrail enforcement highest - the room's consensus was that both matter more than any single feature, because they're what determines whether an incident stays contained or cascades.

One more thing worth knowing

If any part of your business touches the EU, agentic AI systems doing autonomous decision-making may land in a higher EU AI Act risk tier than the underlying model would on its own - the autonomy itself is a risk factor regulators are now scoring separately from model capability. Loop in legal before, not after, you scale an agent from pilot to production.

All Articles