Permission gates
Four checks, and none of them can grant.
Access is decided by four separate questions asked in sequence. Every one of them can remove a tool from what an assistant is offered. Not one of them can add a tool back.
That single property – narrowing only, never widening – is what makes the system reasonable to audit. It means the answer is the intersection of four independent decisions, so no layer can quietly undo another, and reasoning about the result does not require holding all four in your head at once.
The gates
What each one actually asks.
| Gate | The question | Who controls it |
|---|---|---|
| 1The grant | Does this person hold this tool, on this project, at all? | Your administrators |
| 2Ownership | Was this tool written for this client, and is it running on that client's project? | Structural |
| 3Availability | Is this capability switched on for the organization at all? | Your administrators, under a ceiling |
| 4A system present | Does this project have a readable connection of the kind this tool needs? | Reality |
Gate four
The gate that exists because the other three all said yes.
The fourth check was added after a connector was serving eleven tools of which five could actually answer. The grant was right, ownership was right, availability was right – and none of the three was asking whether there was a system on the other end.
What that looked like
Health checks reported fine. Tools were offered, accepted the call, and dead-ended at the first read, because one credential had expired and another sign-in had never been configured. Every journey the client's own handbook described stopped at step one.
Why it is a gate and not a warning
A warning is something somebody reads. A gate means the tool is never offered, so the assistant does not have the option, and nobody spends an afternoon establishing that a capability they were promised does not work.
A tool that needs no connected system is never narrowed by this gate. Reading your own handbook, or asking which environments you have, works for a client who has connected nothing at all – which is what keeps a first-day client a serving client rather than an empty one.
Order
The order cannot change the answer. It does change the reason.
Because every gate only removes, the final set is the same whichever order they run in. What the order decides is which refusal you are told about first, and that is a usability decision rather than a security one.
| gate 3 | capability_not_enabled | your administrator can switch this on | actionable |
| gate 4 | no_connection_of_kind | nothing is connected to answer it | true, but later |
Gate three runs first on purpose, so "your administrator has not switched this on" wins over "nothing is connected". Both are true; only one of them is something somebody at your company can go and fix in the next five minutes.
Defaults
Every unknown is a refusal.
The gates decide what happens when the answer is known. This is what happens when it is not.
No grant, no access
An empty skill list grants nothing. An unrecognised profile expands to nothing.
An unknown tool needs a database
If the system cannot tell whether a tool touches your data, it assumes it does. The safe assumption is the restrictive one.
Unreachable control plane, no service
If the permission store cannot be reached, nothing is served. The failure mode is refusing everybody rather than admitting anybody.