API Governance Was Built for Systems. Agents Need Capability Governance.

The Predictability the Model Assumed Is Gone

That question was built for systems. An agent is not a conventional integration client, and its most consequential failures do not occur at the level that question can see.

A traditional integration is designed around a relatively stable, declared flow. It calls known endpoints in expected patterns for an established business purpose, and API governance was built around that predictability. An agent may have a declared role or goal, but it selects its action path at runtime, assembling tools in response to changing context. Every call it makes can be authorized, within rate limits, and individually compliant — and the composed outcome can still be one the enterprise never intended.

That is the gap. API governance is typically enforced call by call. The harm an agent can cause may emerge across a sequence of calls, each of which is allowed.

Two Compliant Calls, One Outcome Nobody Approved

Consider an agent with read access to customer records and permission to send email. Both capabilities are legitimately granted; both may be necessary for its job. An endpoint-centric gateway can see two compliant calls. Without shared task context and sequence state, however, it cannot determine from those calls alone why the second followed the first — or whether the two calls together converted ordinary access into data exfiltration. The missing question is not merely whether the next call is permitted, but whether this agent, acting for this task under this delegated authority, should be making it now.

API governance asks whether the call is allowed. Capability governance asks whether the agent should be making it.

More precisely: whether this agent may exercise this capability for this task, given what it has already done and the constraints that still apply.

The Unit of Control Has to Change

This is why the unit of control has to change. An API is an endpoint. A capability is what an agent can do when it composes endpoints, tools, and data toward an outcome. A major part of the attack surface is not any single API; it is the set of tools you expose to the agent, because every tool you grant widens what the agent can be talked into doing with the authority it already holds. Least privilege stops being a question of which APIs a client may call and becomes a question of which capabilities an agent may compose, for which task, for how long.

You cannot solve this by adding more endpoint rules alone. The gateway traditionally governs the channel. Capability governance must evaluate the delegated task, the authority available to the agent, the actions already taken, and the next action proposed. It is scoped to an execution and enforced at runtime.

Already Showing Up in Enterprise Platforms

This shift is beginning to appear in enterprise platforms. MuleSoft, for example, positions Omni Gateway as a common control point for API, MCP, LLM, and agent traffic, with security and compliance policies applied to agent-to-agent and agent-to-tool interactions and identity propagated throughout. That makes the gateway a plausible enforcement point for capability governance. But protocol coverage and per-interaction policy are not yet the same as task-scoped, composition-aware control. The location of the control is emerging; the governing model still has to mature.

API governance kept our systems talking to each other safely. The agentic enterprise needs governance over what a worker is allowed to do with those systems, not just which doors it may knock on.

The Bridge to Part 4

About This Series

Cite the Position Paper

@misc{saleme2026eaa,
  author    = {Saleme, Michael K.},
  title     = {Enterprise Agent Architecture: The Case for a Fifth Architecture Domain for the Agentic Enterprise},
  year      = {2026},
  publisher = {Zenodo},
  doi       = {10.5281/zenodo.21105314},
  url       = {https://doi.org/10.5281/zenodo.21105314}
}