# What Your Boundary Actually Covers: Enumeration Comes Before Strength > Source: > Published: 2026-10-02 13:55:13+00:00 After the first few pieces went out, three questions came back. They don't look related: `tool` the right unit for an AI's actions? I can't answer any of them completely. But they're all asking the same thing: **What does your boundary actually cover?** And the answer to that matters more than how strict the check is. When a boundary gets challenged, the reflex is to add. More rules, more confirmations, more logging, a finer-grained check. All of that helps. All of it applies only to actions the boundary already covers. A minimal comparison: `delete_customer`), has a tier (R5), a policy can block it You can't put a gate on the second one. Not because the policy isn't strict enough, but because there is nothing to attach it to. So the order should be: enumerate first, harden second. To put a gate on something you need three things: **a name, a set of arguments, a risk tier.** A discrete action surface has all three. A function call, an MCP tool, an OpenAPI endpoint — each has a name, arguments, and can be assigned a tier. With those three in place, everything the earlier pieces described becomes possible: risk classification, human confirmation, an audit trail, revocation. All of it rests on those three. A non-discrete action surface has none of them. A computer-use agent is clicking around a screen. An agent with a shell is typing commands. A long-running autonomous agent leaves a trajectory. None of that has a name. You can't say which tier it belongs to, which means you can't put a gate anywhere on it. It isn't that the policy is too loose. There is **nothing to attach it to**. Three kinds of action surface, three different states: | Action surface | Enumerable | What the boundary can do | Our status | |---|---|---|---| | Tool calls (MCP / OpenAPI / function calling) | Yes | Tier, confirmation, audit, revoke | Implemented | | Non-discrete (computer-use / shell / long trajectories) | No | **Nothing to attach to** | **Not implemented, and out of scope** | | Physical actuators (gates / reactors / vehicles) | — | Not a business runtime's job | A different safety regime | The middle row needs to be said plainly, because it's a **scope statement, not a todo**. What we build is AI calling business systems. The action surface is tool calls, which are enumerable. Non-discrete action surfaces we don't intend to cover. It's written here so people know where the boundary stops, instead of assuming it extends indefinitely. The consequence, stated properly: **if you wire an agent to a shell, this boundary is worth zero for it.** Not weaker — absent. The third row, since it came up: dam gates, reactor safety systems, self-driving. Those aren't a business runtime's work. They belong to industrial functional safety, with its own standards and its own methods. Answering that with an enterprise application's governance layer is answering the wrong question entirely. Instead of asking how strong your governance is, ask something more basic: **Can you list every action this agent can take?** If you can — there's a list, things have names, each entry is describable — then you can go on: assign tiers, require confirmation, add auditing. Everything the earlier pieces described starts to mean something. If you can't, don't add rules yet. **The actions you can't name are outside the boundary.** And what happens outside the boundary is not reachable by any rule, however strict. A shorter list that's exhaustive is a real boundary. When the list is incomplete, hardening only makes the inside stricter. It doesn't make the outside controllable. Back to the three questions. I still can't answer them completely. But there's one idea that's more useful than an answer: **A boundary isn't drawn. It's listed.** The actions you cover are the list. Outside the list, there is no boundary. *Drafted with an AI assistant. The system, the positions and the mistakes are mine.*