Ask a room who is accountable for what the AI is allowed to do, and watch the pause. IT assume the business decided. The business assume IT configured it. Security assume somebody wrote it down. The vendor assumes the customer knows. Everybody is being reasonable, and the answer is still nobody.
If the boundary has no owner, it is not a boundary. It is a default.
The missing owner
This is not a failure of diligence. It is a consequence of how AI has been introduced almost everywhere: as a tool that is connected to things. Once the connection is the unit of decision-making, the boundary becomes a side-effect of an installation rather than a decision anyone made.
You can see it in the questions people ask. “Does it have access to the ERP?” is a question about wiring. “Is the finance team allowed to have it prepare that?” is a question about the business. Only one of those has an owner in your organisation today, and it is not the important one.
Make it a decision, not a setting
The fix is to make approval an explicit act: a person, deciding that a specific capability is appropriate, for a specific audience, and saying so.
That sounds like bureaucracy and it is the opposite. It is what lets you move quickly — because once the boundary is a decision somebody owns, extending it is also a decision somebody can make, in an afternoon, without reopening the entire question of whether AI is safe.
Projects that cannot name an approver end up asking for permission to do everything, every time. That is why they never ship.
Approval has an audience
“Approved” is not a global state. A capability that is entirely reasonable for a buyer may be inappropriate for a contractor, and irrelevant to a plant supervisor.
So the unit of approval is not the capability alone; it is the capability and the group it is published to. Groups are whatever grouping is genuinely meaningful in your business — function, team, site, project, seniority, customer. Not a technical artefact borrowed from somewhere else, and not a role you inherited from a system that had its own reasons.
The AI then works for the person in front of it, within what that person's groups allow, and nothing more.
The boundary has to live in identity
This matters more for AI than for ordinary software, and the reason is worth stating plainly.
A conventional application shows a user the screens they are entitled to. The interface is the boundary. But an agentic AI is not given a screen — it is given an outcome to achieve, and it works out the path itself. There is no interface to constrain it with.
So the boundary cannot live in the front end. It has to live in identity: one place that knows who the user is, what groups they are in, and therefore what the AI may do while working on their behalf. If there is a second place a user can exist, or a component that can be reached around, you do not have a boundary at all.
Withdrawal is the real test
Anyone can grant. The question that separates a governed deployment from a hopeful one is: how do you take something back?
If withdrawing a capability means visiting machines, editing files, or trusting that everyone re-reads a policy, it will not happen — not on the afternoon when it needs to. Withdrawal must be one act, centrally, effective for everyone who held it.
Ask any prospective AI rollout how it would remove a capability in five minutes across every user. The quality of the answer tells you everything about the quality of the governance.
The conversation worth having
Bring three things to the person who has to sign, and the conversation changes:
- A list. The capabilities that exist, in business language, not technical description.
- An audience for each. Which groups can use it, and why that is appropriate.
- A way to take it back. Demonstrated, not promised.
None of that requires them to trust a model. That is the point.
Composer makes approval an explicit act with a name on it: capabilities are created, governed, published to the groups you choose — and withdrawn centrally when they should be.