A team makes a new API available to check the status of a case. They publish it on the gateway, update the documentation, and notify the relevant colleagues about the release. For an AI agent to use it as well, additional information is needed: what the capability is for, in which situations it is relevant, whether it can discover it, and which process it must follow to gain access.

In traditional integrations, some of this information is reconstructed through interactions between people. When agents also participate in processes, that knowledge needs to be made available in a structured, up-to-date format that is consistent with the organization’s rules.

This is where AI adoption meets the operating model: who publishes the available capabilities, who maintains their information, who can discover them, and who authorizes their use.

Agents Enter the Organization in Two Roles

An API Governance operating model defines responsibilities, rules, and processes to make digital products available and usable throughout their lifecycle. The arrival of AI agents extends this scope in two directions.

Agents are new actors in the ecosystem: they search for information, use services, and can participate in operational processes. They need to be identified, associated with an accountable owner, and governed according to which information they can access and which actions they can perform.

They are also digital products that need to be governed, alongside APIs and MCP servers: they must have an owner, identifiable versions, terms of use, and a managed lifecycle through to decommissioning.

These two perspectives complement each other. Registering an agent makes it possible to know that it exists and who is accountable for it. Including it in operational processes makes it possible to govern its participation in the ecosystem.

Three Changes to Governance Processes

1. Extend Roles and Processes to New Actors

Publication, discovery, access requests, and subscription processes must also account for agents as participants.

For each process, it should be clear which steps can be performed by a non-human actor, under which profile, and with whose accountability. Required approvals must remain identifiable and traceable even when a request is generated automatically.

For example, an agent could be authorized to browse the products available to a business unit and request their use. Enablement would then follow the process defined for those products, with approval from the responsible owner—or automatically, if organizational rules allow it.

This makes it possible to maintain a shared operating model while introducing the specific requirements of non-human actors, without creating separate procedures for every AI initiative.

2. Make the Catalog Accessible to Agents

To support discovery, the catalog must contain information that allows users and agents to understand the capabilities available: purpose, operations offered, data required and returned, terms of use, lifecycle status, and ownership.

The quality of this information becomes part of the publication process. Ambiguous or outdated descriptions make it difficult to identify the relevant capability, even when the API is technically available.

An active catalog connects this information to the processes and systems that keep it up to date, making it accessible according to the profile of the party querying it. In this way, it can also support agents in finding the capabilities relevant to their tasks.

Returning to the initial example, the new case-status verification capability becomes discoverable to authorized agents through the catalog. The ability to discover it remains distinct from authorization to execute it: the latter depends on access conditions and the controls applied by the systems involved.

3. Govern APIs, MCP Servers, and Agents Throughout Their Lifecycle

Management must account for the relationships between different digital products. If an MCP server exposes tools that use specific APIs, these dependencies are essential for assessing the impact of a change or decommissioning.

The process must establish who updates the information, who assesses the impact, and how affected parties are managed. The same level of attention applies when the visibility of a product changes or an authorization is revoked.

For example, a new version of the case-status verification API might require an update to the tool that exposes it. Understanding the relationship between the two products makes it possible to involve the right owners and coordinate the update.

The catalog therefore supports precise operational activities: publishing, enabling, modifying, and retiring digital products while keeping responsibilities and dependencies traceable.

From API Governance to Operational AI Governance

This is the path that ApiShare identifies as Operational AI Governance: making knowledge, digital products, and business processes accessible to agents as well, within a governed organizational context.

The operating model defines responsibilities and rules; the unified catalog makes information available and supports processes; integrations with gateways, identity systems, and other enterprise technologies enable their implementation. Supporting services help teams adopt and evolve the model.

The starting point depends on the maturity of the existing API Governance framework. Clearly defined ownership, reliable information, and consistently applied access processes provide reusable foundations that can also support MCP and AI agents.

An assessment can determine which of these foundations are already in place and which require further work. This analysis can then provide the basis for a concrete roadmap: consolidate what is needed today to make the extension to new actors and digital products sustainable.