AI Governance After Approval: Who Controls the Authority an Agent Accumulates?

22 July 2026 · 7 min read

AI governance processes are typically designed to approve a defined use case. An agent is proposed for a particular purpose, its access is reviewed, its risks are assessed, and the business agrees the conditions under which it can be used. The difficulty is that this is rarely the agent that exists six or twelve months later. Once an agent is in the operation, people improve it: they add skills, connect new systems, widen its access to business data, refine its instructions and let it carry out more steps in the workflow. Each change may be reasonable, and few will feel significant enough to justify a fresh governance process, yet together they can alter the agent's role considerably.

An agent that began by helping a sales team prepare proposals may later be connected to the CRM, pricing data, approved legal terms and document-generation tools. It may gain a skill for comparing commercial options, another for checking policy, and permission to update the opportunity record once the proposal is complete. At that point it is no longer simply assisting with drafting; it is interpreting customer information, selecting commercial content, applying pricing logic and making changes inside a live system. The original use case may still be described as proposal support, while the agent's actual authority is now much broader. That is the governance gap, and governing an evolving agent takes more than an approval record: it takes a current view of the authority the agent holds, clear decision rights over how that authority can expand, and defined thresholds for when change requires reassessment.

Agents accumulate authority through use

In conventional technology a material change is usually visible: a feature is designed, developed, tested and released, and the release itself creates a point at which governance can intervene. The development of an operational agent is often less distinct. A connector is added because the agent needs better context, a new skill is introduced because part of the process is still manual, a permission is widened because employees are still copying information between systems, an instruction is adjusted because the output has to reflect a new policy. None of these necessarily looks like a major change, and the organisation may approve each one locally or not treat it as a governance matter at all. Yet every addition can expand one or more forms of authority: the information the agent can see, the judgements it is permitted to make, the systems it can interact with, the actions it can take, the number of people or customers affected, and the point at which a human is expected to intervene. The risk sits less in any individual skill, connector or permission than in the combined operating position that emerges from them. An agent with access to customer records may present limited risk, and an agent with pricing logic may too, but an agent with both, plus the ability to generate a customer-facing document and update the CRM, has acquired a different level of operational consequence. Governance has to see the combination.

Approval records quickly become historical

An organisation may keep a record of the use case originally approved, showing the intended purpose, the initial data sources, the risk classification, the accountable sponsor and the agreed controls, and that record can create the impression the agent is still governed because the documentation is complete. The problem is that the documentation may describe an earlier version of the agent, not the skills currently available to it, the connectors added since deployment, the data it can now retrieve, the systems it can update, or the extent to which human review has been reduced. The record stays valid as a record of what was approved; it becomes less useful as a description of what is operating. This matters because leaders are rarely exposed to the agent in its full operational form. Individual teams see the parts relevant to them, technology sees the platform and permissions, risk sees the control framework, the business sees the output, and process owners see the workflow improvement, while no one may be looking at the authority the agent has accumulated across all of them.

Ownership is not enough without limits

Assigning an owner to an agent is necessary but does not solve the problem on its own. An owner may be accountable for the use case while having little visibility of changes to the agent's skills, access or configuration; a technology team may control permissions without understanding the operational decisions the agent now influences; a business team may refine how it works without noticing that it has expanded beyond its original risk classification. The more useful question is not simply who owns the agent, but who has the authority to expand its authority. Who can add a new skill, approve a connector, widen access to data, allow an additional action, or decide that a human review step is no longer required, and who determines when the combined effect of several small changes requires a broader reassessment. These are operating-model questions about decision rights, not only accountability, and without clear decision rights an agent can become more capable through a series of sensible local choices while no one considers the cumulative change in its role.

Governance needs a current operating view

A static inventory is not enough. It can show that an agent exists, who uses it and what broad purpose it serves, but not what the agent is currently capable of doing. For material agents the organisation needs a current view of the business process the agent operates in, the decisions it supports or makes, the skills and instructions shaping its behaviour, the connectors, tools and systems available to it, the data it can retrieve or update, the actions it can complete without human approval, the controls that apply at each stage, the people authorised to change any of these, the measures used to assess its performance, and the conditions that would require restriction, review or withdrawal. The purpose is not a larger register for its own sake; it is to make the agent's real operating position visible, and to keep it current, because a point-in-time assessment ages quickly when the agent keeps developing through everyday use.

Material change has to be defined differently

Deciding which changes require governance attention is the practical difficulty. Treating every prompt adjustment or new skill as a formal release creates needless friction; letting all changes pass as routine configuration leaves the organisation blind to increasing authority. The threshold should rest on operational consequence: a change is material when it alters what the agent can know, decide, access or do in a way that increases the consequence of error, which may include access to a new category of sensitive data, connection to another system of record, permission to write, submit, approve or send, the removal of a human review point, application to a larger population, use in a regulated or financially significant decision, increased speed, volume or autonomy, or combination with other capabilities that changes the agent's overall role. That is a more useful test than asking whether the underlying model or platform has changed, because the technology can stay exactly the same while the agent's operational authority changes substantially.

The unit of governance has shifted

AI governance has often focused on platforms, models, vendors and approved use cases, and those controls still matter, but they are no longer sufficient. The unit of governance has shifted from the use case approved at one point in time to the operational agent as it continues to evolve, the combination of model, instructions, skills, connectors, data, permissions, workflow position and human controls that determines what it can actually do. That does not mean every change needs a new approval; it means the organisation has to be able to see when changes to skills, access, permissions or oversight have materially altered the agent's authority. In AIVOM™ this is the Design dimension, where governance is part of how the work is designed rather than a gate at the start. The practical test is straightforward: for any agent doing meaningful work today, can the organisation describe what it can access, what it can decide, what it can change and who has the right to expand those boundaries? Where the answer still depends on the use case originally approved, governance is describing the past rather than controlling the present.