The enterprise AI conversation is changing. The first wave was about what a model could say. The next is about what an agent can do.
An assistant drafts an email. An agent can send it. An assistant summarizes a contract. An agent can update the system of record, open a ticket, or trigger a payment workflow. That extra verb changes the risk model.
If an AI system can act inside the business, it needs more than a responsible-use policy. It needs an owner, a bounded identity, explicit authority, and a record of what happened.
Start with the agent, not the model
Model governance still matters, but the model is only one part of an agentic system. A production agent may combine a model with prompts, memory, retrieved data, APIs, browser access, credentials, approval logic, and fallback behavior.
Two agents can use the same model and present completely different risks. A research agent with read-only access to public sources is not equivalent to a finance agent that can change supplier data. Model name alone cannot tell a risk leader what the system can affect.
The useful unit of governance is the deployed agent in its operating context.
For each agent, document:
- —the business purpose and named owner;
- —the people or systems allowed to invoke it;
- —the data, tools, repositories, and environments it can reach;
- —the actions it can take without review;
- —the actions that require approval;
- —the model and provider choices behind it;
- —the evidence retained for each run;
- —the process for suspension and decommissioning.
This is an inventory, but it is also the beginning of an accountability model.
Authority should be explicit
Most access systems were designed around people and predictable applications. Agents blur both categories. They act on behalf of a user, but they also make intermediate decisions and call tools at machine speed.
Treating an agent as a shared service account hides too much. When a consequential action occurs, a reviewer should be able to distinguish:
- —who requested the work;
- —which agent interpreted the request;
- —which policy allowed the next step;
- —which credential or connector performed the action;
- —who approved it, if approval was required.
That chain is what turns a log entry into an accountable record.
Build evidence into the run
Governance cannot depend on reconstructing events from several unrelated vendor dashboards after an incident. The evidence should travel with the run.
A defensible run record captures the prompt or trigger, relevant context, tool calls, policy decisions, approvals, outputs, cost, timing, and final outcome. Sensitive content may need redaction or restricted retention, but the organization still needs enough provenance to explain why an action was allowed.
This is not about recording hidden model reasoning. It is about recording operational facts: inputs, instructions, tools, decisions, actors, and effects.
The control plane comes before scale
Teams often wait until they have dozens of agents before asking for a shared governance layer. That reverses the order.
The best time to define ownership, access boundaries, evidence, and review is when the agent surface is still understandable. A lightweight inventory and a small set of enforced controls will do more than a perfect policy document no runtime system can apply.
Autonomy can expand later. Accountability is much harder to bolt on after the work has already disappeared into production logs.