The pilot went well. The demo impressed people. And then it stopped — not because the model was not good enough, but because the person who has to sign the deployment off asked a completely reasonable question, and nobody in the room could answer it.
An AI that can do anything is an AI you cannot deploy.
The two doors, and why both are bad
Faced with that question, organisations pick one of two answers.
Give the AI real access. Connect it to the systems that run the business and let it work. This produces something genuinely useful and completely unsignoff-able. No security lead will authorise an autonomous agent with broad reach into the ERP on the strength of a good fortnight in a sandbox. The pilot is a triumph; the production date never arrives.
Give it nothing. Keep it away from anything that matters. This is safe, deployable, and produces an assistant that can summarise a document and cheerfully explain that it does not have access to that. Everyone is disappointed. Nobody is surprised.
Most sites are stranded between the two, having spent a year discovering that the middle ground is not where they assumed it would be.
Access is the wrong thing to give
Both doors share a hidden assumption: that what you hand an AI is access.
Access is a door. Once it is open, what happens next depends on the judgement of whatever walked through — and “the model exercised good judgement” is not a control, it is a hope. That is precisely why access-based AI cannot be governed: the boundary is being enforced by the very thing you are trying to constrain.
A capability is different in kind. It is a specific, named, reviewed thing the business has decided is safe and useful. Not “reach into the system” but “check whether this supplier is approved”. Not “go and find whatever you need” but “tell me what is actually holding this shipment up”.
The AI cannot exceed a capability, because it was never handed the means to. There is nothing left to trust it with.
The question in the room changes
“What might it do?” is an unanswerable question about a probabilistic system. You can gesture at guardrails and testing and monitoring, and the person who has to sign will still, correctly, refuse.
“Which capabilities did we approve?” is a question with a list for an answer. The list was reviewed. It is versioned. It is enforced centrally. It shrinks the moment anyone wants it to.
That is not a rhetorical trick. It is the difference between asking a business to trust a model and asking it to govern a catalogue — and enterprises have been governing catalogues for forty years.
Not everyone should see everything
A capability that is appropriate for one person is not automatically appropriate for another. Approval is therefore not a global switch; it is a decision about audience.
Capabilities should be published to groups — a team, a function, a plant, a project, whatever grouping is genuinely meaningful in your business — so that an AI working for a given person sees only what suits that person. A user in no group sees nothing beyond what was explicitly made public.
- The AI cannot offer someone a capability they were never given. It is not filtering optimistically at the point of use; it was never handed the thing at all.
- Withdrawal is a single act. A capability that should no longer be in circulation is removed centrally, and it is gone for everyone who held it — no sweep of machines, no hoping.
Building and releasing are different acts
The other thing that alarms security teams is a project where creating a capability and making it live are the same motion. Somebody builds a clever thing on Thursday and it is in production on Thursday.
Keep them apart. A capability should be able to exist — be built, reviewed, refined, argued about — without any AI being able to use it. It becomes available when a person publishes it, to a named audience, on purpose. That is ordinary release discipline, and there is no reason AI should be exempt from it.
What to avoid
Avoid the single all-powerful assistant that “has access to everything and will be careful”. Avoid access granted through a service account, where nobody can say afterwards who actually did the thing. Avoid capability that arrives by accident because a component was installed. Avoid a rollout where nobody can produce, on request, the list of what the AI is currently able to do.
If you cannot produce that list, you do not have a governance problem that policy will fix. You have an architecture that cannot answer the question.
Composer turns business know-how into approved capabilities, governs who may use them, and publishes them deliberately — so “what can the AI do?” has an answer with names on it.