Agentic AI Governance and Compliance: A Complete Guide for Security Teams

An auditor, a customer or a board member asks a plain question: which AI agents run in your company, who owns each one, and how do you know what they did last week? A team with excellent technical controls can still fail that question, because the controls exist but nothing proves it.

Governance is what turns controls into something provable. What follows covers scope, frameworks, a shared evidence set, oversight, third parties, a first policy and the dates worth watching. Public sources carry the argument. Vendor claims, secondary reports and our opinions each get a label. Read it as orientation for engineers. It is neither legal counsel nor an audit.

Seven strands of the work

Think of governance as seven strands braided together. First comes a census of agents, each tied to a person and a purpose. Second is a short policy covering permitted actions, approval triggers and the authority to stop an agent. Third is a risk register kept per agent, with scores, linked controls and review dates. Fourth is human oversight that holds up under scrutiny. Fifth is the proof itself: logs, test output, reviews and records. Sixth is the mapping to standards and law. Seventh is control over everything you did not build, meaning vendors, plugins, tool servers and agents from other organisations. A break in any strand loosens the others.

Which source answers which question

Source	What it is	Reach for it when	Our deeper piece
NIST AI RMF plus the generative AI profile	A voluntary risk framework	You need a structure for risk work across four functions	RMF applied to agents
NIST AI Agent Standards Initiative	A standards effort still forming	You track where agent identity and interoperability are heading	The NIST announcement itself
ISO/IEC 42001	A management system you can be certified against	A buyer wants a documented, auditable process	ISO 42001 and agents
EU AI Act, as amended	Binding law	You must classify systems and meet dated duties	The AI Act after the Omnibus
OWASP agentic list, MITRE ATLAS	Risk list and adversary knowledge base	You want shared names for risks and a basis for tests	Crosswalk pieces on this site

On its RMF page NIST describes the framework as voluntary (NIST AI RMF). In February 2026 NIST's Center for AI Standards and Innovation announced the AI Agent Standards Initiative, which aims at agents that act securely for users and interoperate (NIST announcement). One certification guide presents ISO/IEC 42001 as the first international management system standard for AI (CASRAI). None of these documents is a list of technical controls, and none substitutes for another.

One body of proof, several readers

The efficient approach is to gather proof in a shape that each framework can consume. The matrix below is our own synthesis. It is not an official crosswalk and no auditor has checked it.

Proof you hold	NIST function it feeds	EU AI Act link
The register of agents, owners and purposes	Govern, Map	Classification, documentation
A short impact note for each agent	Map	Classification according to purpose
Risk entries tied to specific controls	Map, Manage	Risk management duties for high-risk systems
Who-can-do-what identity records	Manage	Security and robustness
Action logs that resist tampering	Measure	Logging and traceability
Approvals that display the true action	Govern, Manage	Human oversight
Reports from tests and red teams	Measure	Accuracy, robustness, cybersecurity
Reviews of vendors and tool servers	Govern, Manage	Supply chain duties

The fields those logs need are listed in audit log evidence requirements.

A worked example: three agents, three tiers

Consider three agents in one company. A meeting summariser reads calendars and writes notes. A procurement assistant drafts purchase orders and can submit them under a limit. A support agent answers customers and can issue refunds. A first-pass tiering might put the summariser in the lowest tier, because it reads little and writes nothing outside the notes. The procurement assistant lands in the middle: it spends money, but a limit and a human release cap the harm. The support agent sits highest, since it talks to the public and moves funds.

The tier then drives the evidence. The summariser needs a register entry and an owner. The procurement assistant also needs approval records that show the purchase order, and a log of each submission. The support agent needs all of that plus red team results, a tested stop, and a legal view on whether any regulated category applies. The point is proportion: evidence follows authority, and the same template does not fit all three.

Oversight that a regulator could believe

Article 14 of the EU AI Act, aimed at high-risk systems, expects overseers to monitor the system, remain alert to over-reliance on its output, interpret that output correctly and decline to use the system (Article 14 text). Whether your agent counts as high-risk is a legal question. The engineering point holds regardless: an approval is only evidence of oversight if the reviewer saw the real action. An approval dialog that names a script but hides what it does proves nothing. Word the policy so that a person sees the actual action, then test that it happens. More in human oversight in production.

Third parties and unapproved agents

The reach of governance includes each vendor, plugin, tool server and outside agent: assign each an owner, a date for the next review and a fixed version. Buying choices have their own articles on this site. Agents nobody approved require discovery first, because a policy binds only what you know exists. The IBM breach study, as summarised by a law firm, reported that 63 percent of organisations lacked an AI governance policy (Baker Donelson summary of IBM 2025). Check IBM's report directly before repeating that figure.

The dates, and which source says what

A client alert from Gibson Dunn dated 27 May 2026 described a provisional deal on the Digital Omnibus on AI. Under it, Annex III high-risk duties slip to 2 December 2027 and Annex I duties to 2 August 2028, with Article 50 transparency largely staying on its first date of 2 August 2026. The firm noted that nothing took legal effect before the act was adopted and published (Gibson Dunn). A later Cloud Security Alliance note, published 1 August 2026, says the act was published in the Official Journal on 24 July 2026 as Regulation (EU) 2026/1744 and entered into force on 27 July 2026 (Cloud Security Alliance).

We could not confirm the publication from the Official Journal itself, because EUR-Lex refuses automated fetches. Treat the secondary reports as likely and verify on the primary source with counsel before you plan against any date.

A later deadline is not a reason to wait

A postponed deadline invites a postponed programme. That reading is a mistake. The Cloud Security Alliance title says it plainly: deferred, not cancelled. More to the point, the people asking you for evidence do not follow the EU calendar. Customer security questionnaires, insurers and your own incident reviews all ask the same thing today: who owns this agent, and what did it do?

The better use of the extra time is to build the inventory, the register and the log evidence now, while it is cheap, and to map them to the AI Act later when classification questions are answered. Work that serves every framework should not wait for the one with a moving date.

The call has a limit. If your organisation has no EU market nexus, no use case in the regulated categories and no customers who ask, the date genuinely lowers the priority of AI Act specifics. Even then the inventory and the stop authority still pay for themselves. Whether any of this applies to you is a question for counsel.

Order of work for the first quarter

Start with the census and name an owner for every row. Next, publish a one-page policy that names who may stop an agent without asking anyone. Third, open a risk register for each agent, beginning with the highest tier. Fourth, put controls in a sensible order, and keep the proof as you go. Only then map the proof to frameworks, because the mapping needs something to point at. Finish the quarter with an incident playbook and one rehearsal.

Who holds which pen

Assign each duty to a named role. The executive sponsor sets the appetite for risk and accepts what remains on high-impact agents. Each agent owner answers for purpose, scope and that agent's register rows, and signs off any change to its tools or data. The security lead runs the programme, testing and incident response, and grants exceptions. The platform team builds identity, checkpoints, isolation and logging. Legal and compliance map the work to law and contracts and judge classification. Procurement runs vendor and tool intake and negotiates contract terms for data, incidents and leaving.

A policy short enough to read

A workable policy covers eight points. Its scope is any agent that touches company data or systems, purchased or installed by a user. Production access requires a register entry with an owner and a purpose. Each agent authenticates as itself, with narrow credentials that expire. Outbound data, record changes, spending and permission changes go through approval screens that show what will really happen. Tool servers, plugins and external agents pass review and run at fixed versions. Records live where the agent cannot rewrite them. The security lead and each owner hold stop authority with no extra sign-off. A quarterly review, plus one after any incident, keeps the register honest.

What an auditor will ask

Prepare for questions that files can settle. Which agents exist, and who is accountable for each? How were the high-risk ones chosen, and what does one assessment look like? What do the logs show for a recent action, and for whom was it done? When was the stop last exercised, and when did a red team last report? What is the route for approving a new tool server? What guidance did staff get on approved and unapproved agents? Documents and logs answer most of what frameworks later ask. Opinions do not, and they call for more proof before any mapping.

Mistakes we see repeated

Mapping to a framework before an inventory exists maps nothing. Teams that use different words for "agent" and "approval" produce reports nobody can compare. A click-through approval is not oversight. A certificate for a management system proves a process exists. It says nothing regarding any single agent's behaviour. A register refreshed only by the calendar drifts from reality, so trigger updates from changes in tools, data and users.

Five numbers for the leadership pack

Report production agents grouped by tier, the portion with an owner and a distinct identity, how many top-scoring risks are overdue, when the stop was last rehearsed, and how many unapproved agents turned up and were resolved in the quarter. Add a short note on what changed and what you need from leadership.

Open points

• How regulators and standards bodies will treat agent-specific evidence. NIST's work is still in progress.
• Whether ISO/IEC 42001 will support a presumption of conformity under the EU rules. We have not confirmed it.
• Our evidence matrix is a synthesis and awaits expert validation.

This guide does not replace legal advice or an audit. Ask qualified counsel and assessors about your own obligations.

Questions about agentic AI governance