Agentic AI governance — the controls regulators are starting to ask for.
Agents that plan, call tools and commit actions are a distinct risk class. We at RegCore.AI describe the control primitives supervisors have begun to ask for — action budgets, kill switches, audit trails, agent cards, human-in-the-loop gating — and how they compose into a programme a regulator will accept.
An agent is not a model. The governance has to reflect that.
A model answers a prompt. An agent plans, selects tools, executes, observes, and iterates — often across minutes or hours, sometimes across systems the deployer does not own. The supervisory concern is no longer only accuracy at inference. It is what the agent chose to do, which tool it used, which data it touched, whether a person was in the loop at the moment of consequence, and whether the programme can reconstruct the sequence if it has to. The control primitives that answer this question are different from those that answer it for a classical model, and the deployers that have started early are the ones that designed the agent layer as a governed surface from the outset.
Action budgets — the first-line limit on what an agent can do.
The most consequential control we see work in practice is an action budget. The deployer enumerates the actions the agent is permitted to take — tool calls, writes, external requests, financial commitments, data reads of particular sensitivity — and caps each one against a time window, a value threshold, or a sequence length. The budget is enforced in the orchestration layer, not in the prompt. An agent that attempts to exceed its budget is routed for review. The discipline this imposes is quiet and continuous: it forces the deployer to be explicit about what the agent is for, and it produces a ledger that a regulator can read. It also changes the failure mode. Instead of an agent drifting open-endedly into adjacent tasks, an agent that is unsure of itself arrives at a human reviewer with its context intact.
Kill switches and containment — the posture every supervisor asks about.
Every supervisory conversation about agents we have heard includes a kill-switch question. What does it take to stop the agent, and everything it is doing, within a defined interval? The answer has three parts. A technical stop — an orchestration-level halt that terminates tool calls and holds pending actions. A contractual stop — the ability to suspend the agent’s access to third-party systems without breaching a master services agreement. And a communications stop — a procedure that notifies the owners of affected systems. The deployer that has rehearsed the drill once — and has the runbook, the named owners, and the tested pathways — is in a materially different position to the deployer that discovers the question during an incident.
Audit trails a supervisor can actually read.
The audit surface for an agent is wider than for a model. Prompts and outputs are only part of the record. The deployer has to be able to reconstruct the plan, the tools invoked, the arguments passed, the outputs received, the agent’s interpretation of those outputs, any escalation raised, the reviewer who signed, and the commit at the end. The format matters. A log that only a platform-native viewer can read does not answer the supervisor’s question; the artifact has to be portable, signed and retrievable at the session level. The record is what converts an agent from an opaque decision-maker into a reviewable one. Every regulator conversation we have heard ends at this point.
Agent cards — the portable summary that travels with the system.
Model cards codified what a regulator, auditor and customer needed to know about a classical model. Agent cards extend the idea. They name the agent, describe its purpose, enumerate its permitted tools, define its action budget, state its escalation thresholds, list the data it may read and write, and identify the reviewer on call. They travel with the agent across procurement, assurance and examination. The practice that has started to crystallise is that agent cards are produced once and maintained against change, rather than reconstructed at each audit. The deployers with the tidiest files are the ones that treated the card as a first-class artifact.
HITL gating — where human judgement attaches.
Human-in-the-loop is a governance primitive, not a safety net. Gating has to be designed against specific events — a value threshold, a counterparty flag, an outlier in the agent’s own uncertainty signal, a regulatory red line. The commit gate is the controlled point at which the action leaves the agent and reaches the world; the review at the gate is logged, the reviewer is identifiable, and the rationale is retrievable. Agents that bypass commit gates under exception handling are the failure pattern that shows up at every post-incident review we have seen. The discipline that closes it is not a policy document; it is the gate itself, operating in the orchestration layer.
How these compose into a programme.
The primitives listed above do not stand alone. They compose into a governance programme that reads against ISO/IEC 42001 operational clauses, the NIST AI RMF Manage function, OSFI E-23 validation and monitoring expectations, and the EU AI Act’s high-risk-system controls. The firm operates the agentic AI governance playbook as the walk-through: agent inventory, action-scope and budget design, HITL gating and audit trail, monitoring and rollback. The artifact set is the Agent Card, the action-budget ledger, the kill-switch runbook, and the audit-log schema. The mechanical work is done by compliance agents; the judgement is done by practitioners; the sign-off belongs to the second line. That is the shape regulators have started to read for, and we think it is the shape the next eighteen months will harden.
Stand up the agent governance a supervisor will accept.
The firm ships the playbook, the controls and the agents that produce the evidence — Agent Cards, action-budget ledger, kill-switch runbook, audit-log schema — and maintains the file against change.