A server that exposes tools to an agent — over the Model Context Protocol or any similar arrangement — has an authorisation problem with an unusual shape. The caller is software, acting for a person, choosing at runtime which tools to invoke and in what order. Nobody wrote that sequence down in advance, so the permission model cannot assume a known call pattern.
The temptation is to issue one credential that can reach everything, because the agent might need anything. That is the design that makes an incident unbounded, and it is also the design that makes the consent screen meaningless, since a person asked to approve full access has been given no information at all.
Name scopes after outcomes
Scopes derived from your internal structure — one per endpoint, or per table — produce a consent screen that is a list of implementation details. The person reading it cannot map any of it to something they care about, so they approve everything, and the screen has become a formality that protects nobody.
Name them after what the software will be able to do in terms the account holder already understands: read the customer directory, send messages on my behalf, change billing settings. Fewer scopes, each meaning something to a non-engineer, is a better outcome than a precise taxonomy nobody reads. Then map tools onto those names, and accept that one scope covers several tools.
- One scope per capability a person would recognise, not one per endpoint
- Read and write separated always; they are the distinction users understand best
- A separate tier for destructive and irreversible actions, never bundled with write
- Spending money, changing access and altering security settings each stand alone
- No scope that means everything, including for your own first-party tools
Read and write is not a fine enough cut
Two operations that both write can differ by orders of magnitude in consequence. Updating a record and deleting an organisation are both writes. Sending a message to one colleague and sending a message to every contact are both writes. An agent that misreads an instruction will happily perform the larger one, and the scope model is the only thing standing between an error and a consequence you cannot reverse.
Split by reversibility and by blast radius rather than by verb. What is undoable can sit in an ordinary write scope. What is irreversible, externally visible or financial deserves its own scope and, for the sharpest cases, a confirmation at the moment of use rather than a permission granted once at connection time. The agent then holds the ability to propose the action, and the person retains the decision.
Split scopes by what cannot be undone, not by whether the verb happens to be a read or a write.
The confused deputy is the failure mode to design against
A tool server usually holds credentials of its own to reach the systems behind it, and those credentials are typically broader than any individual caller should have. If the server executes a request purely on the strength of having received it, the caller has borrowed the server's authority, which is the classic confused deputy.
The invariant is that every call carries the identity of the person on whose behalf it is made, and every access check runs against that person's rights and not the server's. Where the server calls onward, it should exchange the incoming credential for a narrower one bound to that user and that purpose, rather than reaching for its own. Audit entries then record both identities: which person, and which software acting for them.
- Check authorisation against the end user, never against the service credential
- Exchange downward when calling onward; never widen scope during a hop
- Record both the human and the software on every event, as separate fields
- Bind the credential to a specific resource where the protocol allows it
Consent that can be inspected and withdrawn
Approval granted once, months ago, in a dialogue nobody read, is not a control. What makes it one is the ability to look afterwards at what is connected, see what each connection is permitted to do and when it last did anything, and remove one without disturbing the others.
Keep the grants short-lived and refreshable so an abandoned integration expires on its own, and make revocation take effect quickly rather than at the next token expiry. And give the organisation an administrator's view of the same thing, because in a business account the question is not only what did I approve but what has anybody here approved, and that question arrives in a security review whether or not you built a screen for it.
Everything here, already built
Sign-in, enterprise SSO, directory provisioning, roles and an audit trail behind one API. Start with the quickstart and have a working sign-in this afternoon.