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-level policy evaluates each invocation on its own terms and sees 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. A concrete rule at this level of granularity looks like: an agent may read a customer record and send a case update, but the send must be bound to the active case, an approved recipient on that case, and a permitted set of data fields — not merely "read access" and "send access" as two independent grants.

Capability, in this note, means one bounded unit of what an agent can do — a tool call, an API invocation, a data operation — evaluated together with the task and prior actions that make exercising it appropriate right now. That's narrower than "business capability" in EA usage, and distinct from a cryptographic capability token.

The Unit of Control Has to Change

This is why the unit of control has to change. An endpoint-level policy evaluates a particular invocation. What needs governing is the composition: the sequence of capabilities an agent chains together toward an outcome. Harmful composition of individually-permitted actions is not unique to agents — conventional systems and human operators can chain compliant calls into an outcome nobody approved too. What changes with an agent is degree: it selects and sequences that composition at runtime, across a much larger space of possible action paths, without a human choosing the specific sequence in advance. 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 must also address which capabilities an agent may compose, for which task, for how long — not only which APIs a client may call.

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 — which means the enforcement point needs access to the relevant task state, not just the current call, and needs to sit on every consequential execution path an agent can reach, not only the ones that happen to route through a given gateway. 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, documents its Omni Gateway policy documentation 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 the documentation describes policy coverage at the gateway, not demonstrated task-aware enforcement of the kind this note argues for — protocol coverage and per-interaction policy are not yet the same as evaluating a proposed action against the task, prior actions, and remaining authority. 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}
}