What an Agent Can Reach Is Not What It Is Authorized to Touch — EAA Part 2

From Roster to Reach

Part 1 of this series established the Agent / Workforce layer: the enterprise has a non-human workforce, and governing it requires the same five things any workforce requires — inventory, identity, delegated authority, lifecycle, and accountability. Knowing who each agent is sets the foundation. But identity without scope is not governance. The moment you ask what an agent is permitted to do, you are asking a different and harder question.

The Capability / Tool layer answers it. Its subject is not the agent as an actor but the surface the agent can touch: the tools it can invoke, the APIs it can call, the data it can read and write. This is the layer that decides whether delegated authority is bounded or unbounded — whether the enterprise has handed an agent a targeted scope or a master key.

The distinction matters because it is the boundary that every adversarial input, prompt injection, and confused-deputy attack tries to exploit. An attacker who can influence what an agent reasons about cannot make the agent reach past its tool registry. But everything inside that registry is reachable by anyone who can influence the agent's input. The tool registry is not an implementation detail. It is the attack surface.

CAN-Reach vs AUTHORIZED-to-Use

The clearest way to see the gap is to look at how tool registries are built in practice. A team integrates an agent with a business system. They hand it the API keys. They load the MCP server. They wire up the tool definitions. And because the agent needs the file tool to do its job, it gets the file tool — all of it: read, write, delete, execute. Because it needs the database tool for one query type, it gets the database tool with the connection string that can also drop tables. Because it needs to send notifications, it gets the messaging integration that can also initiate payments.

None of these decisions feel wrong in the moment. Each capability was added because the agent needed it for something. But the aggregate result is an agent whose tool registry is a superset of any task it will ever legitimately perform. CAN-reach now includes everything. AUTHORIZED-to-use was never defined separately. The two lists are identical — and that identity is the failure.

Field research has documented this pattern systematically. When prompts become shells: the tool registry is the attack surface traces exactly this dynamic: when an adversarial input reaches an agent, it can direct the agent toward any tool already in scope. Prompt injection does not give an attacker new capabilities. It lets the attacker use the agent's existing ones. If those capabilities are over-provisioned, the blast radius of any injection scales with the over-provisioning.

When the Allowlist Is the Vulnerability

The standard response to over-provisioning is an allowlist: enumerate what the agent is permitted to call and block everything else. This is the right instinct. But allowlists can fail in the same direction as the problem they solve.

CVE-2026-40933: The allowlist was the vulnerability documents the failure mode precisely. The allowlist existed. It was documented. It was even enforced. But it had been constructed — and then allowed to expand through incremental additions — until it permitted actions no legitimate task required. The control was real. The scope of the control made it ineffective.

This is a different failure than having no allowlist. An absent allowlist is a known gap. A miscalibrated allowlist is invisible: the control shows green in every audit while authorizing far more than the agents ever legitimately need. The CVE illustrates the second failure mode, and it is the more dangerous one precisely because it passes review.

The lesson is that least privilege is not a one-time configuration decision. It is a question that must be challenged against the actual task set: does this agent, for this purpose, need this specific capability? Not in general — for this task type, today. A capability added speculatively because someone thought it might be useful eventually is not a scoped permission. It is deferred over-provisioning.

The Lethal Trifecta

When you survey agent deployments at scale rather than one configuration at a time, a pattern appears. 98% of agents carry the lethal trifecta: tool access broader than the task requires, no runtime enforcement of scope limits, and no audit trail logging what the agent actually called. Each property is a gap. All three together describe a posture in which an agent with excess capability cannot be stopped mid-execution and cannot be reconstructed afterward.

The trifecta is lethal not because any single component is catastrophic but because the three together eliminate every corrective mechanism. Broad scope means the agent can do things it should not. Absent runtime enforcement means nothing stops it in the moment. Absent audit means you cannot see what happened after the fact. A security model that fails at prevention, detection, and reconstruction simultaneously is not a degraded model. It is no model.

What makes the ninety-eight percent figure striking is that the trifecta is not exotic. Each component is the natural outcome of how agents are typically built: scope expands to cover everything the agent might ever need, runtime enforcement is deferred as a future hardening step that never quite arrives, and audit is treated as a logging concern rather than an architectural requirement. The result is not a configuration that anyone designed to be insecure. It is the configuration you get when capability is added iteratively and governance is added never.

When the Stakes Are Irreversible

The Capability / Tool layer matters most when the tools in scope produce irreversible consequences. And no tool class illustrates this more clearly than the payment rail.

The whole payments industry now co-signs the agent payment rail. Who red-teams it? documents what happens when the financial services sector collectively adds agents to payment workflows without a corresponding capability scoping discipline. The business case is real: an agent that can initiate payments saves time, reduces errors, and scales to volumes humans cannot reach. The governance question is equally real: when that agent can initiate any payment to any payee in any amount, the scope of what a confused or compromised agent can do is the scope of what the payment system itself can do.

The answer is not to remove payment capability from agents. It is to scope it with the same precision you would apply to a human employee who handles funds: specific payee classes, specific amount bounds, specific conditions under which authorization is required before execution. The tool is not the problem. An unscoped tool is the problem. The difference between a scoped payment capability and an unscoped one is exactly the gap between AUTHORIZED-to-use and CAN-reach — and on a payment rail, that gap is measured in dollars and reversibility windows.

What the Capability / Tool Layer Must Establish

If the Agent / Workforce layer is the roster — who each agent is, what authority it holds, who answers for it — then the Capability / Tool layer is the scope attached to that authority. Five questions define it.

Question	What the layer must define
Scope	Which tools, APIs, and data are in this agent's registry — and which are explicitly excluded. Both lists matter; an undeclared exclusion is an implicit permission.
Authorization	Which of those tools the agent is permitted to invoke for which task types. CAN-reach and AUTHORIZED-to-use must be defined as separate, reconciled lists.
Least privilege	Whether the tool scope is the minimum required for the agent's actual task set — challenged against real usage, not against hypothetical future needs.
Audit surface	Whether every tool call is logged with enough context to reconstruct what the agent called, when, with what inputs, and what it received back.
Revocation	Whether a tool can be removed from an agent's registry without redeploying the agent — the ability to tighten scope in real time when a risk is identified.

An enterprise that can answer all five for every agent in its workforce has a defined capability architecture. An enterprise that cannot has an implicit one — and implicit means over-provisioned, unaudited, and unrevocable in the moment it matters most.

The Bridge to Part 3

Define the capability layer tightly and you have something valuable: a precise, enumerated scope for each agent's tools. But a well-defined scope is still a configuration. It answers what the agent is permitted to touch in principle. The Control Plane layer is where that principle meets a live action — the runtime enforcement point that allows, denies, or holds an action at the exact moment it is attempted. That is the subject of Part 3.

About This Series

Michael K. Saleme — Enterprise Agent Architect

Enterprise Agent Architecture is published as a position-paper series — the canonical account of the practice, released one part at a time. Part 0 makes the case that agents are a fifth domain of enterprise architecture, not an application tier. Part 1 takes the first layer: the agent workforce itself. Part 2, above, takes the second layer: the capability and tool surface each agent is authorized to use.

The question this layer addresses — the gap between CAN-reach and AUTHORIZED-to-use — is not new to enterprise architecture. It is the same question that produced IAM, RBAC, and least-privilege access design thirty years ago. Agents have reopened it because the way they are configured and deployed tends to collapse that gap entirely. The discipline is the same. The discipline is also being ignored in the same ways it was before it was formalized the first time.