The CISO’s AI Agent Governance Playbook: From Zero to Audit-Ready in 90 Days

A dated, week-by-week plan for security leaders who have been asked whether their AI agents are governed, and need an answer that survives an audit.

Most CISOs can answer the first question a board asks about AI agents. There is a policy, and it is written down. Few can answer the second: how many agents are running right now, what each one may do without a human, and where the evidence of that lives. Closing that gap is what CISO AI agent governance actually means, and it closes at runtime or not at all.

The gap is measurable. In a survey the Cloud Security Alliance ran in January 2026, 82% of organisations had discovered previously unknown AI agents in their environment during the past year. Of those, 41% had done so more than once. In the same survey, 68% reported high confidence in their visibility into AI agents (Cloud Security Alliance, April 2026, based on 418 responses and commissioned by Token Security).

Both findings cannot be true at once. Confidence is not visibility, and a policy is not enforcement.

This is a ninety-day plan. It sets out what to do each week, which artefact each phase produces, and what you hand an auditor at the end. It assumes no dedicated AI governance function and no budget cycle to wait for.

Why the Deadline Moved and the Work Did Not

The EU’s high-risk deadline moved and the operational work did not. On 29 June 2026 the Council of the European Union gave final approval to the Digital Omnibus on AI. It resets the application date for stand-alone high-risk systems under Annex III from 2 August 2026 to 2 December 2027. High-risk AI embedded in products moves to 2 August 2028.

The amendments were published in the Official Journal on 24 July 2026 as Regulation (EU) 2026/1744, and the text states it enters into force on the third day following that publication (EUR-Lex, Regulation (EU) 2026/1744). Not every date moved outward. The same regulation cuts the grace period for implementing transparency solutions for artificially generated content from six months to three, with a deadline of 2 December 2026.

Sixteen extra months is a longer runway, not a smaller task. The records a conformity assessment wants, what an agent did, who authorised it, and proof the record was not edited afterwards, are produced at the moment of action or not at all. You cannot backfill them in late 2027.

If you operate outside the EU, the same questions arrive through a different door. ISO/IEC 42001:2023 specifies requirements for establishing, implementing, maintaining and continually improving an AI management system (ISO, iso.org). An assessor examining that system will ask what your agents did and how you know.

Days 1 to 7: Inventory Every AI Agent Running in Your Organisation

Week one produces exactly one artefact: a list of every AI agent running in your organisation, each with a named human owner and the system it belongs to. Nothing later in this playbook works without it. You cannot classify, govern, or audit an agent you have not found.

The Cloud Security Alliance survey names where undeclared agents surface. Internal automation and scripting environments accounted for 51% of shadow agent sightings, LLM platforms including custom tools, assistants and plugins for 47%, SaaS tools with built-in automation for 40%, and developer-created workflows for 40% (Cloud Security Alliance, April 2026). Those four are your sweep list.

Work from credentials rather than from teams. Service accounts, outbound API keys and OAuth grants issued in the past eighteen months will surface agents nobody thinks of as agents, because the person who built one inside a SaaS automation does not call it that.

Add a column for agents nobody has switched off. Only 21% of the surveyed organisations had formal decommissioning processes in place, which means retired agents commonly keep their permissions and credentials. An agent with no owner is a finding, not an inventory row.

In OpenBox, an AI agent governance platform, this is the Assess phase of the Trust Lifecycle: Assess, Authorize, Monitor, Verify, Adapt. Registering an agent creates the agent entity, issues an API key for SDK authentication, and sets the initial risk profile that determines how strictly the agent is governed (OpenBox, docs.openbox.ai).

Week one is done when every agent has a name, an owner, a host system, and a decision: govern it, or turn it off.

Days 8 to 21: Classify Each Agent by Risk Using Trust Tiers

Weeks two and three assign every agent a risk classification and let the platform derive a trust level from it. In OpenBox these are two constructs, not one, and conflating them is the most common error at this stage. The Risk Profile Score is what you decide. The Trust Tier is what the agent earns.

The Risk Profile Score comes from 14 parameters across three weighted categories: Base Security at 25%, AI-Specific at 45%, and Impact at 30%. It produces a score from 0 to 100 and a Risk Tier from 1 to 4. A higher Risk Profile Score means lower inherent risk, and the score is static unless you re-assess it (OpenBox, docs.openbox.ai/trust-lifecycle/assess).

Four presets shorten the work. Low Risk covers scores of 85 to 100 and starts an agent at Tier 1 or 2. Medium Risk covers 55 to 75 and starts at Tier 2 or 3. High Risk covers 25 to 45 and starts at Tier 3. Critical Risk covers 0 to 20 and starts at Tier 3 or 4. Those initial tiers assume a clean slate, with Behavioral Score and Alignment Score both at 100.

The Trust Score itself is composite: Risk Profile Score at 40%, Behavioral Score at 35%, and Alignment Score at 25%. The Behavioral Score tracks policy compliance at runtime. The Alignment Score tracks goal consistency. Both start at 100 for a new agent and move with behaviour.

Trust Tiers translate that score into how strictly an agent is controlled. There are five bands, not four, and the fifth is the one an auditor will ask about.

Source: OpenBox, docs.openbox.ai/core-concepts/trust-tiers, accessed 24 July 2026.

Transitions are immediate in both directions when the score crosses a band boundary, with no stabilisation period or cooldown. Promotion into Tier 1 additionally requires admin approval. Recovery is earned through clean sessions pushing penalties out of the rolling window, not granted by idle time (OpenBox, docs.openbox.ai).

Weeks two and three are done when every agent has a Risk Profile Score, a predicted Trust Tier, and a written note wherever the owner’s intuition disagreed with the profile. Those disagreements are where your real risk sits.

Days 22 to 45: Configure Governance Decisions for Each Agent Class

Weeks four to seven are where governance stops being a document. For each agent class you configure which actions run, which pause for a human, which are refused, and which end the session. OpenBox returns one of four governance decisions for every operation it evaluates: ALLOW, REQUIRE_APPROVAL, BLOCK, HALT.

ALLOW lets the operation proceed. REQUIRE_APPROVAL pauses it and routes it to a human approval queue. BLOCK rejects the operation while the agent session continues. HALT terminates the entire agent session. Where several rules apply at once, precedence runs HALT > BLOCK > REQUIRE_APPROVAL > ALLOW (OpenBox, docs.openbox.ai/core-concepts/governance-decisions).

Two control types produce those decisions, and they are not interchangeable. Policies are stateless permission checks written in Rego (OPA) that evaluate a single operation on its own and do not track session history. Behavioral Rules are stateful, detecting sequences, frequencies and combinations across a whole session.

The difference matters in a case OpenBox documents. A reporting agent skips its database query and goes straight to writing a file. The model fills in convincing figures from its own knowledge, correctly formatted and entirely fabricated. No single operation looks wrong, so a stateless check passes it.

A Behavioral Rule catches it. Set the trigger to a file write, set the required prior state to a database query, and set the verdict to HALT. If the query never happened, the session ends before the report exists. Rules are evaluated in priority order and stop at the first verdict returned.

This is where most programmes stall. In the Cloud Security Alliance survey, when an agent exceeded its intended scope, 38% of organisations required human approval and 24% required the action to be logged. Only 11% automatically blocked it (Cloud Security Alliance, April 2026). Logging an out-of-scope action is detection, not enforcement, and an auditor will read it that way.

Test both layers before rollout. OpenBox guidance is to validate policies and behavioral rules against known-good and known-bad inputs, which is also the periodic control validation set out in its compliance and audit documentation.

The output of this window is one page. It is the page to take to your board.

Columns one and three are documented platform behaviour (OpenBox, docs.openbox.ai/core-concepts/trust-tiers). Column two is a recommended starting configuration rather than a platform default, and you should expect to tune it. Column four follows the record types in docs.openbox.ai/administration/compliance-and-audit.

Days 46 to 75: Wire Up Real-Time Monitoring and Alerting

Weeks seven to eleven turn enforcement into something a person can watch. Monitor is the third phase of the Trust Lifecycle and covers real-time runtime visibility including drift, cost and latency (OpenBox, docs.openbox.ai). The work in this window is not installing a dashboard. It is deciding which signals wake someone up.

OpenBox documents five alert types, and each maps to a different failure. Trust Tier changes fire when a score crosses a band boundary. Goal drift fires when the Verify phase finds an alignment score below threshold, 70% by default. Policy violations fire on BLOCK or HALT. Approval timeouts fire when a human-in-the-loop request expires, after 24 hours by default. Behavioral rule matches fire on multi-step patterns.

Of those five, the approval timeout is the one to staff first. An expired approval results in the operation being denied. If your queue sits unattended for a day, your governance layer is quietly refusing legitimate work, and the people whose work is refused will find a way around it. That last step is my read rather than documented behaviour, but it is the failure mode I would plan for.

Each alert carries four actions: view the agent, acknowledge it, create a rule, or dismiss it. Create Rule pre-fills a behavioral rule to prevent recurrence. That is the loop worth enforcing internally, because an alert that never becomes a rule is an alert you will see again next month.

Weeks seven to eleven are done when every alert type has a named owner, an agreed response time, and at least one instance that has been converted into a rule.

Days 76 to 90: Assemble Your First Audit-Ready Evidence Pack

The final two weeks assemble an evidence pack, not a report produced by a button. What OpenBox documents is the raw material: a governance event for every evaluation, a trust score history, a per-session Proof Certificate, and an on-demand export of the organisation audit log in CSV or Excel.

Each governance event records a UTC timestamp, the agent, the event type, and the verdict issued, which is one of ALLOW, REQUIRE_APPROVAL, BLOCK or HALT. Alongside it sit the reason for that verdict, workflow and run identifiers, and approval metadata covering who approved or denied and when (OpenBox, docs.openbox.ai/administration/compliance-and-audit).

The trust score history records the score before and after each change, the tier before and after, what triggered the change, the reason given, and whether a system or a user evaluated it. For an assessor testing whether controls operated rather than merely existed, that table is worth more than any dashboard screenshot.

Attestation is what makes the pack hold up. When a session completes, each governance event is hashed with SHA-256. The hashes are combined into a Merkle tree using sorted-pair hashing, so the tree is consistent regardless of processing order. The session root is then signed with ECDSA NIST P-256 through AWS Key Management Service by default, or through an external attestation endpoint such as a Trusted Execution Environment.

Each session produces one Proof Certificate holding the Merkle root, the signature and the event count. Be precise about what that buys you. The certificate does not prevent anyone editing a record. It makes an edit detectable, because the recomputed root stops matching the signature. The property is tamper-evident, and tamper-evident is the claim to make.

Verify is where you go when someone asks what happened. The phase covers goal alignment and Proof Certificates, and Session Replay sits under it, letting you replay and audit a session after the fact (OpenBox, docs.openbox.ai). The governance decision at each operation is visible on that timeline.

One caution, because this is where playbooks oversell. No export satisfies an audit on its own. ISO/IEC 42001:2023 certifies a management system rather than a product, and the assessor evaluates your processes, not your vendor’s. The evidence pack answers the evidence questions. Running the management system remains yours.

Day ninety is not the end of the lifecycle. Adapt runs continuously, surfacing violation patterns, tier changes and suggested policies, and each suggestion is accepted, rejected or modified by a person before it becomes a rule. Governance that rewrites itself without a human signature is not governance you can attest to.

The Four Questions Your Board Will Ask and How to Answer Each One

Boards ask four questions about AI agents, and each is really a question about evidence. Answer each with an artefact and a date rather than with an assurance. The four artefacts this playbook produces map onto them directly, which is why it is built in this order.

How many AI agents do we run, and who owns each one?

Answer with the inventory and the date it was last refreshed. Then concede the discovery rate honestly: 82% of surveyed organisations found previously unknown agents in the past year, and 41% found them more than once. A board trusts a number that arrives with its own error bar more than one that does not.

What can each agent do without a human?

Answer with the control map by Trust Tier and one ratio: how many operations returned REQUIRE_APPROVAL last month, and how many of those were approved. That ratio shows whether the controls are calibrated or decorative. A queue that approves everything is not a control.

If an agent caused harm last Tuesday, can we prove what happened?

Answer with Session Replay for the narrative and the Proof Certificate for the integrity. State the claim precisely: the records are tamper-evident, so an alteration would be detectable through the Merkle root and its signature. Overstating this to a board is the fastest way to lose the room later.

What is governance costing us?

Answer with approval queue latency and the timeout rate. Approvals expire after 24 hours by default, and an expired approval denies the operation. If that rate is climbing, your controls are taxing delivery in a way nobody has priced, and engineering teams will begin routing around them.

Ninety Days Buys You Answerability, Not Compliance

Ninety days does not make an organisation compliant. It makes it answerable, which is the harder and more useful thing. At the end you hold an inventory with owners, a risk classification per agent, a decision map per class, five alert types with names against them, and a signed evidence pack. That is what CISO AI agent governance looks like when it is real rather than declared.

OpenBox, an AI agent governance platform, runs this shape of programme directly: Trust Scores and Trust Tiers for classification, four governance decisions enforced at runtime, real-time alerting, and tamper-evident cryptographic audit trails. The canonical documentation sits at docs.openbox.ai if you want to check the mechanics against what you have just read.

Frequently Asked Questions

How do I identify AI agents my teams have deployed without formal approval?

Sweep the four environments where they most often appear. In the Cloud Security Alliance’s January 2026 survey, respondents found shadow agents in internal automation and scripting environments (51%), LLM platforms including custom tools and plugins (47%), SaaS tools with built-in automation (40%), and developer-created workflows (40%). Start from issued credentials, not from team headcount.

What is the minimum governance setup required to satisfy a SOC 2 or ISO/IEC 42001 audit?

No configuration satisfies an audit on its own. ISO/IEC 42001:2023 certifies an AI management system, and an independent assessor evaluates your processes rather than a vendor’s product. A workable minimum is an agent inventory with named owners, a documented decision map per risk class, retained governance events, and signed per-session evidence.

How does a Trust Score differ from a traditional risk score, and why does the distinction matter for auditors?

A traditional risk score describes what an agent could do. The OpenBox Trust Score also reflects what it has done, combining Risk Profile Score at 40%, Behavioral Score at 35% and Alignment Score at 25%. The two runtime components matter to auditors because they evidence operating effectiveness rather than design intent.

Can a small security team run this playbook, or does it require a dedicated AI governance function?

A small team can run it if one person owns the agent inventory and another owns the approval queue. The part that does not compress is the queue. Approvals expire after 24 hours by default in OpenBox, and an expired approval denies the operation, so an unattended queue blocks work silently.