A list of AI agents does not control them.

Most enterprise AI governance programs can tell you whether an AI system exists.

Far fewer can tell you what it is allowed to do at 10:43 this morning.

That difference is becoming the defining governance gap of agentic AI.

An inventory is a map. A policy is a rulebook. Neither one, by itself, is an operating control.

As AI systems move from answering questions to calling tools, accessing data, coordinating workflows and acting across enterprise software, organizations need to govern a changing system of permissions, dependencies, evidence and consequences.

AI inventories remain essential. They can capture system identity, owner, purpose, provider, model family, data categories, deployment status and risk context. ISO/IEC 42001 and NIST’s AI risk-management work both reinforce the need for lifecycle governance rather than ad-hoc experimentation.

Source context: ISO/IEC 42001:2023 ↗ · NIST AI Risk Management Framework ↗

But an inventory describes a system. It does not continuously decide whether a particular action is authorized.

Consider an agent listed as:

Purpose: customer-service support Tools: CRM, order database, email Owner: Customer Operations Risk: medium Human oversight: required for exceptions

That looks governed.

Now ask:

Can it issue a refund? What amount? Can it send the refund without approval? Can it expose internal notes to the customer? What happens if a web page it reads contains malicious instructions? What happens if the customer account is in another tenant? What happens if the agent’s permission was revoked yesterday?

The inventory does not answer those questions.

Policies define expectations. They can state that sensitive data requires stronger controls, that certain actions need approval, that high-impact uses require review, or that AI-generated content must be disclosed in defined circumstances.

But policy text only becomes operational when systems translate it into enforceable decisions.

A sentence such as “high-value refunds require human approval” needs at least:

• an authoritative refund threshold;
• identity and entitlement context;
• an action classification;
• an approval mechanism;
• a durable record of the decision;
• fail-closed behavior when required state is missing or malformed.

Without that machinery, the policy is a hope.

Agents do not merely produce text. They may call functions, use tools, invoke APIs, communicate with other agents and carry state across multi-step workflows.

OWASP’s 2025/2026 agentic security work reflects this change. Risks include goal hijacking, tool misuse, identity and privilege abuse, supply-chain vulnerabilities and unexpected code execution. Its earlier “excessive agency” category already identified excessive functionality, permissions and autonomy as root causes of damaging behavior.

Source context: OWASP Top 10 for Agentic Applications 2026 ↗

Protocols such as MCP and A2A make integration easier. That is useful—and it increases the importance of governing authority explicitly. Standardized connectivity should not be mistaken for standardized permission.

Source context: MCP · authorization specification · 2026-07-28 ↗ · Agent2Agent · v1.0 specification ↗

A tool can be discoverable without being usable. An agent can be capable without being authorized. A remote agent can advertise a capability without becoming trusted.

The system must know what the agent is permitted to do now, not what someone approved six months ago.

Authority should be scoped by subject, organization, role, data, tool, action, amount, time, jurisdiction and consequence where relevant.

A decision may depend on evidence that is strong, sparse, stale, conflicting or missing. Governance should not turn uncertainty into confidence just because a workflow expects a binary answer.

A €20 customer credit and a €20,000 payment instruction should not require identical controls merely because both are “financial actions.” Higher consequence should not receive less review.

Agents can combine context from multiple tools. The governance layer must prevent sensitive data, secrets and tenant context from crossing boundaries even when the model itself is willing to continue.

Providers update models. Tools change scopes. Regulations evolve. Evidence expires. Employees change roles. An inventory snapshot can become wrong while still looking complete.

This is why we have defined the Operational AI Governance Gap Study 2026–27.

The central question is not “Does your organization have an AI policy?”

It is:

How large is the gap between documented AI governance and the ability to evidence operational control over AI systems, agents, authority, data, changes and outcomes?

The study protocol deliberately separates:

SELF-REPORT what organizations say they do;

DOCUMENTED EVIDENCE what policies, registers, assessments and records show;

OBSERVED OPERATING EVIDENCE what runtime controls, logs, approvals, tests and change records demonstrate.

That distinction matters. UNESCO’s Readiness Assessment Methodology makes a similar methodological point at national scale: it asks not only whether strategies, laws and policies exist but whether their efficacy has been assessed, whether implementation plans exist, whether budgets and monitoring are present, and where data is missing.

A hypothetical organisation has an approved inventory entry for a research assistant. The entry says that it retrieves internal documents and prepares summaries. During a later update, a connector gains the ability to create tasks and invite external collaborators. The inventory may still be accurate about the product's identity while becoming incomplete about its consequences. The important question is which decision now needs review.

A quarterly spreadsheet update is one possible way to detect the change, but it may be too late for the first external invitation. Conversely, collecting every technical event can overwhelm the people expected to respond. A practical design identifies a small set of material changes: new external actions, wider data access, a changed provider arrangement, a different purpose or a new group of affected people. Each has an owner and a response.

This is the gap between knowing that a system exists and governing what it can do. The solution is not necessarily a larger register. It is a connection from the changed fact to the person and control that can change the operating permission. The original inventory remains useful as the place from which that connection begins.

For each consequential action, identify the policy intention, the enforcing component and the observation that would show whether it worked. If the policy says external sharing requires approval, find the actual point where sharing is blocked. A written instruction in a prompt and an independently enforced permission are different controls. Their failure modes should not be presented as equivalent.

Ask what happens when information is missing. Does an unavailable permission service deny the action, queue it for review or assume the previous state? What happens if the subject belongs to another organisation? Can an old approval be replayed against a changed object? These are concrete operating questions that an inventory title or leaderboard score cannot answer.

Keep the map small enough to use. Begin with one workflow and its significant actions. A service team may need read access, draft preparation, customer communication and financial adjustment. Separate those permissions even when one user interface presents them together. That makes it possible to preserve useful assistance while holding a higher-consequence action.

Run a controlled exercise in which one condition changes. Revoke a permission, replace a source with a contradictory version or remove a required document. Observe the actual behaviour. Does the assistant explain the missing condition? Does the external system receive an attempted write? Can an operator identify the affected case and restore a legitimate path?

Next, test a repeated request after an uncertain response. A model may retry because it did not receive confirmation, while the external service has already acted. The workflow should establish the real state before repeating the transaction. Keep the relevant event identity so that observation and recovery refer to the same operation. A successful second response is not evidence that the first action never occurred.

Record the result with configuration and scope. An exercise on one connector does not certify every integration, but it can reveal a class of weakness worth investigating elsewhere. Preserve failures and the correction. The most valuable evidence may be the reason a proposed expansion was postponed, because that reason explains the actual limit of the current implementation.

Monitoring is useful when it can lead to a defined decision. A provider notice about a model retirement matters to the workflows that depend on that model. A changed retention condition matters to the data flows covered by the selected service. An unexplained increase in reopened cases matters to the owner of that process. The signal should arrive with enough context to judge relevance.

Avoid calling every source refresh verification. Observing a new document establishes that a source changed; it does not automatically establish that the service is compliant or unsuitable. A review may confirm that the change has no material effect. Preserve that distinction so that an alert stream does not become an unauthorised decision engine.

Plan the human work as well. Who receives a signal, how is urgency determined and what happens during absence? A system that detects changes but has no responsible recipient does not close the governance gap. Nor does a dashboard that counts alerts without showing whether the underlying question was resolved. Useful evidence includes the decision and the reason, not merely notification delivery.

Assess a bounded workflow through observable properties: required permission is checked, conflicting evidence is preserved, an unauthorised action is denied, a reviewer can intervene and a material change reaches the right owner. These properties can be tested independently. Combining them into a single percentage can hide a critical failure behind many less consequential successes.

Use a clear acceptance statement for the actual deployment. For example, “the assistant may prepare a reply using these sources; sending remains with a named service role.” That is more actionable than “governance maturity 87%.” It tells staff what is permitted and tells testers which boundary to challenge. Changes to the purpose or authority require another decision.

After an unexpected action, reconstruct the chain from request to consequence. Which identity was used, which permission applied, which source informed the proposal and which system established the final state? Preserve the distinction between what the assistant said and what the external system did. This avoids fixing only the explanation while leaving the underlying permission unchanged.

Identify the earliest practical point at which the problem could have been prevented or contained. The answer may be a clearer source, a narrower permission, a better approval interface or an independent state check. It is not necessarily a new model. Assign the correction to the existing owner of that responsibility.

Retest the affected failure and an ordinary successful case. A correction that blocks every useful action may contain the incident but still require operational work. Record the new boundary and tell the people who rely on it. The incident has produced useful learning when the working process changes, not merely when a report is filed.

Use the Good AI Prism for market orientation, then inspect the source-backed profile and comparison. The AI Estate demonstration illustrates how system context can be connected; it is not evidence that an operating control is installed in your organisation. Keep that distinction when discussing the architecture.

An AI Trust Record is relevant to organising one system's evidence and responsibilities. An AI Trust Pilot can frame a controlled use-case test with explicit boundaries. Bring the inventory entry, the action it currently permits and the change that worries you. The next step should make one operating decision clearer, rather than replace an existing register with another disconnected list.

A mature organization should be able to answer questions such as:

Which AI systems and agents operate here? Which Missions do they support? What data and tools can they access? What authority have they been granted? Which actions require approval? What evidence supports important decisions? What changed since the last review? Which incidents or exceptions occurred? What business outcome was intended? What outcome was actually observed? What value was modeled, observed and attributed?

If those answers live in disconnected spreadsheets, policy PDFs and ticketing systems, the next governance challenge is not another document.

It is convergence.

That is the AI Governance Gap.