Why the agent got a category of its own
For most of the current AI cycle, regulation treated the model as the object of concern. Rules attached to what a system was — a classifier, a generator, a foundation model — and the compliance question was about provenance, accuracy, disclosure and risk classification. That framing holds for software that produces an output a human then acts on. It breaks the moment the software acts on its own: the agent does not return a recommendation, it files the invoice, sends the payment instruction, updates the record, and calls another system to do something else. The object of concern moved from the output to the action, and once an action has a real-world effect, the questions a regulator asks change shape.
That is the mechanical reason the category formed. An agent has authority, and authority is the thing legal systems have always regulated — who granted it, how far it extends, who answers when it is exceeded, and what evidence exists that it was exercised within bounds. None of those questions is answered by a model card. So jurisdictions started writing agent-specific rules rather than stretching model-era ones, and some of those regimes arrived with teeth attached: independent security assessment of covered agent systems, obligations that scale with the autonomy granted rather than the model used. The regulatory unit of analysis is no longer "the AI you deployed" — it is "the agent you authorised".
The board-level reason is the gap. Adoption ran ahead of governance by a wide margin through 2026: agents proliferated in production while the proportion of organisations claiming a governance regime that covers them stayed stubbornly lower. That gap is exactly what made "agent governance is the new cybersecurity" land. Not because agents are a security problem in the narrow sense — but because the shape of the failure is the same one security lived through a decade earlier. An emerging capability spreads faster than the discipline that governs it, nobody owns it at board level, the first serious incident or audit reveals there was never an inventory, and the response arrives as regulation rather than as good practice.
This is a regime, not a control
Three adjacent things get called "agent governance", and buying one of them while believing the category is covered is the most expensive mistake available here. Each is a genuine control. None of them is the regime.
Agent sprawl and lifecycle governance is the operational discipline of the fleet — registry, owner, review date, decommissioning gate — and its concern is the dormant agent with live privilege. Red teaming is a testing technique: adversarial probing of an agent before and after it ships, which tells you how it fails under pressure. Agent identity — the machine-identity and know-your-agent layer — establishes who the agent is and what credential it carries. All three are prerequisites. What sits above them is the regime: the agent treated as a governed entity with a named accountable executive, a documented purpose and scope, an evidence trail a regulator can read, and a mapping from the controls you operate to the frameworks an auditor now cites. Lifecycle governance manages the fleet. Red teaming tests the agent. Identity names it. Only the regime answers the question a regulator actually asks: on whose authority is this thing acting, and can you show me?
| Layer | The question it answers | Who owns it | What it does not do |
|---|---|---|---|
| Agent lifecycle governance | Does every agent have an owner, a review date and a clean retirement? | Platform and security operations | Does not establish board accountability or regulatory evidence |
| Red teaming | How does this agent fail when someone tries to break it? | Security engineering | A point-in-time test, not a standing regime |
| Agent identity (KYA / non-human identity) | Who is this agent and what credential does it hold? | Identity and access management | Names the actor; does not govern the authority it was granted |
| Agent governance regime (this piece) | On whose authority does this agent act, and where is the evidence? | The board, through a named risk sponsor | Assumes the three layers above already exist |
Read the rows together and the design consequence is uncomfortable but clear: an organisation can run a clean registry, red team every release and issue every agent a scoped identity, and still have no answer when a regulator asks who authorised the agent to move money. Those controls produce operational safety. The regime produces accountability — and accountability is what the new rules are written about.
The framework that is forming
What is emerging is recognisably borrowed. It is the governance pattern that model risk management brought to banking and that information security management brought to everything else, re-pointed at an entity that acts. Four moves do most of the work.
One business owner, one technical steward, one risk sponsor per agent
The regime starts with a named human triad, because "the AI team owns it" is not an answer a regulator accepts. The business owner is accountable for why the agent exists and what outcome it is trusted with. The technical steward is accountable for how it is built, evaluated and changed. The risk sponsor — normally an executive with a standing reporting line to the board — is accountable for whether the authority granted is proportionate to the exposure created. Three roles rather than one because they fail differently: an agent can be technically sound and commercially unjustified, or well-justified and operationally unsafe. This is where the regime meets proportional agent governance — the triad's intensity should scale with what the agent can actually do, so a read-only summariser does not get the oversight apparatus of an agent with a write path into a system of record.
An inventory that records purpose, scope and a review date
Every regime that has ever survived contact with an auditor rests on an inventory, and the agentic version has to carry more than a list of names: what each agent is for, which systems and data it reaches, what authority it was granted, who holds the three roles, and when someone must reconfirm that all of it is still true. The operational half of this overlaps with the fleet registry that lifecycle governance already demands — the difference is what the record is used for. The registry exists so you can revoke and retire. The inventory exists so a board committee can review a portfolio of agents by risk, and so an assessor can pick a row and ask for the file behind it. Where the two are the same system, the organisation gets both for one build; where the inventory only exists as a slide, it produces exactly the evidence gap the regime was created to close.
A decision and action trail that stands up as regulatory evidence
The regime's centre of gravity is evidence. When the agent acted, what did it see, what did it decide, which tool did it call, under whose authority, and what changed as a result — captured as a durable, versioned record rather than a log that rotates out in thirty days. This is the same signed, replayable trail that makes a non-deterministic system defensible, promoted from an engineering nicety to the primary artefact of compliance. The test to apply is deliberately unkind: if a regulator asked you to reconstruct one specific agent action from four months ago — inputs, reasoning path, tool calls, approval, effect — could you produce it as a file, or would you produce a narrative? Regimes are graded on the first answer.
A demonstrated ability to intervene and shut down
Every agent-specific rule published so far converges on the same requirement: a human must be able to interrupt. That is easy to assert and surprisingly hard to evidence, because the meaningful version is not a button in an admin console — it is a tested path that halts the agent mid-task, quarantines what it has in flight, revokes the authority it was acting under, and leaves a record that it happened. The organisations getting this right rehearse it the way they rehearse a failover, on a schedule, and keep the result as evidence. Alongside it sits the mapping work: expressing your agent controls against the AI management system standards and risk frameworks assessors have started citing, so the same control set answers several regimes at once instead of being rebuilt per questionnaire — the reusability argument that also drives certification as a procurement gate.
The old question was "is our AI compliant?" The new one is "for each agent we authorised, who owns it, what is it permitted to do, where is the record of what it did, and can we prove we can stop it?" — a named triad so accountability has an address, an inventory so the portfolio is reviewable, a decision trail that survives an assessor, and an intervention path that has actually been tested.
Four ways it goes wrong
The failures cluster into four shapes. Each lets an organisation run agents at scale while believing the governance question is handled, and each surfaces at the worst possible moment — the incident review, the procurement questionnaire, or the first audit that asks for a list.
1. Treating the agent as a product feature rather than a governed entity
The most common failure is categorical. The agent ships inside a product release, inherits whatever governance the product has, and is never registered as a thing that holds authority in its own right. It has a backlog and a changelog but no owner of record, no scope statement and no risk classification. The organisation is not being negligent; it is applying the software lifecycle it already had to something the software lifecycle was never designed to cover. The fix is to make "is this an agent?" a gating question at design review, and to route anything that acts autonomously into the entity regime regardless of which product it ships inside.
2. Shipping to production with no owner, no trail and no kill switch
The second failure is the one that produces headlines. An agent goes live because it works, and the three things that would make it defensible — an accountable human, a durable record of its actions, a tested way to stop it — are all deferred as hardening work for a later sprint that competing priorities keep pushing out. The agent then performs well for months, which is precisely what removes the urgency. The fix is to treat those three as launch gates rather than hardening items, on the same footing as an authentication check: no owner, no trail, no tested stop, no production.
3. Assuming a generic AI policy already covers autonomy
The third failure is a paperwork illusion. The organisation wrote a responsible-AI policy in the model era — covering acceptable use, bias review, disclosure and vendor selection — and assumes it extends to agents by default. It does not, because none of its clauses speak to authority: what an agent may initiate without a human, what value or irreversibility threshold forces approval, what happens when it delegates to another agent. The policy passes an internal review and fails the first external one. The fix is to test the existing policy against a concrete agent scenario — an autonomous action with a financial effect — and write the authority clauses the gap exposes, rather than assuming coverage from a document that predates the capability.
4. Discovering the regime when the assessor asks
The fourth failure is about timing. Everything above is achievable in a quarter of deliberate work and nearly impossible to assemble in the two weeks between receiving a questionnaire and answering it — because the artefacts that matter are historical. An inventory can be written on demand; a decision trail covering the past year cannot be back-filled, and neither can evidence that an intervention path was tested before the incident. The fix is to build the evidence as a by-product of running agents, so that answering an assessor is an export rather than a project — the continuous-evidence posture that replaces the annual scramble.
The trade-off, stated honestly
The tension is real and worth naming: every element of the regime taxes the speed that made agents attractive. Naming a triad, classifying an agent's authority, standing up a durable trail and rehearsing a shutdown path all sit between an idea and production. A team that could put an agent in front of users in a week now spends part of that week on governance artefacts, and pretending otherwise is how vendors lose credibility. There is no configuration in which full accountability arrives free.
What the cost buys is the ability to keep operating. In a market where agent-specific rules are being written and third-party assessment is appearing in the text of them, the constraint on scaling agents stops being engineering capacity and becomes the ability to answer for what they do. The organisation that installed the regime early converts a governance gap into a procurement advantage — its answers to the agent section of an enterprise questionnaire already exist, which is the same reason the firms that prepared for the high-risk deadline early found themselves selling while others were remediating. The honest calibration is proportionality: this regime is overhead for an agent that drafts internal summaries and is the difference between operating and stopping for an agent that moves money, touches regulated records or acts on a customer's behalf. The tell that a leadership team understands the trade is that it can answer three questions about any agent in production without a working group — who is accountable, what is it permitted to do, and where is the record — instead of counting agents it has never classified.
What this looks like for document AI specifically
Document workflows are where the regime gets concrete quickly, because an extraction agent is rarely just reading. It classifies a contract, pulls the figures, posts them into a system of record and triggers what happens next — an action with a financial effect, taken on evidence the agent interpreted itself. Four things change when a document platform is built as a governed entity rather than a feature.
Every agent carries its authority statement, not just its configuration. The agent that processes invoices is registered with what it may do unaided, what value threshold forces a human approval, which systems it may write to, and which named people hold the business, technical and risk roles — so the answer to "who authorised this" is a record, not a reconstruction from commit history.
The trail is the product of the run, not a debugging by-product. Each extraction and each downstream action is captured with the document version, the model and prompt version, the confidence, the human decision if one was taken and the effect it produced — a governance evidence envelope that can be exported for a specific action months later rather than reassembled from logs.
Intervention is a tested path with a receipt. Stopping an agent mid-run halts the queue, quarantines partially processed documents, revokes the write path into the downstream system and records the intervention as an event — so the ability to shut down is something the organisation has evidence of, not a claim about an admin toggle.
Controls map once and answer many. The same control set — authority classification, evidence retention, human oversight, model change management — is expressed against the AI management and risk frameworks assessors cite, so a document pipeline that already satisfies the regime does not get rebuilt for each new questionnaire, and the agent's exposure stays legible to the people who now price the risk of it acting wrongly.
Closing thought
The agent stopped being a feature the day it started taking actions someone has to answer for. Regulation is simply catching up to that, in the order it always does: capability spreads, a gap opens, the gap produces an incident, and the response arrives as a rule with an assessor attached. The organisations that will find the next two years comfortable are not the ones with the fewest agents — they are the ones that can name the owner, the permitted authority and the evidence trail for every agent they run, because they wrote that down before anyone required it.
At Cogneris we treat an agent that acts on a document as a governed entity from the first design review: registered with a named business owner, technical steward and risk sponsor, bounded by an explicit authority statement that says what it may do unaided and where a human must decide, running against a signed and versioned trail that can be exported for a single action months later, and stoppable through a path we test rather than assume. That is what turns the governance gap into something you can show instead of something you argue. If you are working out how to move from "we have agents in production" to a regime you could put in front of a board committee or an assessor, and want to see which of your document agents currently act without a recorded authority, see our product page, read the security page, or talk to our team. We would rather classify the authority — who owns it, what it may do, where the record lives — in the first conversation than help reconstruct it after a regulator has asked.