Permission gates
Four checks stand between the question and the answer. Any one of them ends it.
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.
A gate that can also grant is not a gate. None of these four can give anybody anything.
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 |
Who decides
Two of those gates are yours. And we cannot reach past either of them.
"Your administrators, under a ceiling" is the row above that most needs explaining, because it is the line between what we can do for you and what only you can do. Unlocking a capability and switching it on are two different actions taken by two different people, and we only have the first.
| Action | Who | What it does, and what it does not |
|---|---|---|
| Unlock a capabilityraise the ceiling | Us | Turns nothing on. It raises the ceiling of what your administrators are allowed to switch on, which is a commercial action rather than an access one. Nobody gains access to anything at the moment we do it. |
| Switch a tool onper environment | Your administrator | Decides which tools exist at all on which environment. This is gate 3, and it is a setting inside your own console that we have no path to change on your behalf. |
| Write a grantper person | Your administrator | Names one person, one project and one set of skills. This is gate 1. Nothing else creates one, and there is no route that reaches a tool a grant does not carry. |
| Let a licence lapseand come back | Either | Your configuration survives it. When the ceiling drops, the tools above it stop being offered and the settings stay exactly where they were, so renewing restores what you had rather than asking you to rebuild it. |
The uncomfortable version of this claim, stated plainly. We operate the service, so "we cannot" here means the console has no such function and no support process uses one, not that physics prevents it. What is structural rather than procedural is narrower and worth naming separately: the console is a separate assembly that cannot reach a client database at all, and that is asserted by a test rather than promised.
Lifecycle
A grant is a row. So it has a beginning and an end.
-
01
Created by a named person, and the record says who
Grants are not inherited from a group or derived from a job title. Somebody at your company decided this person may read this environment with these tools, and the row carries their name.
-
02
It can carry an end date
A consultant on a six-week engagement gets a grant that stops on its own. Grants approaching their expiry are swept into findings your administrators acknowledge themselves, alongside configuration approved by the person who wrote it and approvals that have gone stale.
-
03
Revoking takes effect on the next question
Not at the next token refresh, and not after a cache expires. The token a person holds carries no permissions of its own, so the decision is taken fresh on every call and there is no standing access to withdraw separately.
-
04
Leaving the company is your process, not a second one
Sign-in runs through your own directory, so somebody disabled there cannot get in regardless of what their grant still says. The grant is the second thing to tidy up, not the first thing to remember.
Which is why your identity provider stays the only list of people.
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.