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

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 will rarely be the agent that exists six or twelve months from now.

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 allow it to carry out more steps in the workflow. Each change may be reasonable. Few will feel significant enough to justify a fresh governance process.

Taken together, however, 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”. The agent’s actual authority is now much broader.

That is the governance gap.

Governing an evolving agent therefore requires more than an approval record. It requires 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 new feature is designed, developed, tested and released. The change 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 remains manual. A permission is widened because employees are still copying information between systems. Instructions are adjusted because the output needs to reflect a new policy.

None of these necessarily looks like a major change. 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 by its work;

• the point at which a human is expected to intervene.

The risk does not sit only in any individual skill, connector or permission. It sits in the combined operating position that emerges from them.

An agent with access to customer records may present limited risk. An agent with pricing logic may also present limited risk. An agent with access to both, together with 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

Organisations might maintain a record of the use case originally approved.

That record may still show the intended purpose, initial data sources, risk classification, accountable sponsor and agreed controls. It can create the impression that the agent remains governed because the documentation is complete.

The problem is that the documentation may describe an earlier version of the agent.

It may not reflect 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 governance record remains valid as a record of what was approved. It becomes less useful as a description of what is operating.

This distinction 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. Process owners see the workflow improvement.

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 it 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 system permissions without understanding the operational decisions the agent now influences. A business team may refine how the agent works without recognising that it has expanded beyond its original risk classification.

The more useful governance question is not simply who owns the agent. It is who has the authority to expand its authority.

Who can add a new skill?

Who can approve a connector?

Who can widen access to data?

Who can allow the agent to take an additional action?

Who decides that a human review step is no longer required?

Who determines when the combined effect of several small changes requires a broader reassessment?

These are operating-model questions. They concern decision rights, not only accountability.

Without clear decision rights, agents can become more capable through a series of sensible local choices while no one considers the cumulative change in their role.

Governance needs a current operating view

A static agent inventory is not enough.

An inventory can show that an agent exists, who uses it and what broad purpose it serves. It may not show what the agent is currently capable of doing.

For material agents, the organisation needs a current view of:

• the business process in which the agent operates;

• 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;

• the conditions that would require restriction, review or withdrawal.

The purpose is not to create a larger register for its own sake. It is to make the agent’s real operating position visible.

That view also needs to be maintained. A point-in-time assessment will age quickly when the agent continues to develop through everyday use.

Material change has to be defined differently

One of the practical difficulties is deciding which changes require governance attention.

Treating every prompt adjustment or new skill as a formal release would create unnecessary friction. Allowing all changes to pass as routine configuration would leave the organisation blind to increasing authority.

The threshold should be based on operational consequence.

A change becomes material when it alters what the agent can know, decide, access or do in a way that increases the consequence of error.

That may include:

• access to a new category of sensitive data;

• connection to another system of record;

• permission to write, submit, approve or send;

• removal of a human review point;

• application to a larger customer or employee population;

• use in a regulated or financially significant decision;

• increased speed, volume or autonomy;

• combination with other capabilities that changes the agent’s overall role.

This is a more useful test than asking whether the underlying model or platform has changed.

The technology may remain 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.

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.

That does not mean every change requires a new approval process. It means the organisation must be able to see when changes to skills, access, permissions or human oversight have materially altered the agent’s authority.

The operational agent is the combination of model, instructions, skills, connectors, data, permissions, workflow position and human controls that determines what it can actually do.

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.

The Power of AI. The Potential of People.

Envisago specialises in AI Operating Model Design. We help executive teams translate AI investment into operating impact and measurable enterprise value.

Start with the free AI Operating Impact Briefing to identify where governance, ownership and operating-design gaps sit across your AI activity.