Credentials and the Capability Ladder
Access is controlled by a credential and the capability it carries. The capabilities form a ladder, not a set of independent flags: each level includes everything below it.
Where to find it
Credentials and their capabilities live in the MCP datastore, opened from All Datastores. Issued tokens are visible and revocable at Architect Panel → Integration & Connections → OAuth Tokens.
The four rungs
- None — no access at all. The default, and what an unrecognised credential gets.
- Read — look things up.
- Write — create and change records, and everything Read allows.
- Admin — everything above, plus administrative operations.
Because it is a ladder rather than a set of checkboxes, a credential with Admin can read without Read also being granted. The corresponding OAuth scopes are mcp:read, mcp:write and mcp:admin, and a broader scope implies the narrower ones — which is what the specification requires, and what client libraries expect.
Capability is a ceiling, not a grant
This is the most important thing to understand, and the thing most often misread.
A credential carrying Write does not thereby gain access to every datastore. It still reaches only what its underlying permissions allow. The two combine and the more restrictive wins.
That is what lets you issue a credential for one narrow purpose without it becoming a general key to the system: grant Write at the capability level, then grant the credential's identity rights to exactly one datastore, and that is all it can touch.
Issuing credentials
One credential per client and per purpose. A shared credential used by three integrations cannot be revoked without breaking all three, and its call log tells you nothing about which of them did what.
Name them for what they are for, not who set them up. "Service desk assistant — read" survives a staff change; "Dave's test key" does not.
Start read-only
Give a new client Read and watch what it does with it for a while. Most genuinely useful AI integrations are read-heavy — answering questions, summarising, finding things. The ones that truly need Write are worth thinking about deliberately rather than granting by default because it seemed simpler.
Dynamic client registration
The server supports the standard dynamic registration flow, so a client can register itself rather than being configured by hand. That is convenient and worth a deliberate decision: it means a client you have not individually configured can obtain a credential. Decide whether self-registration suits your risk appetite before enabling it, and review OAuth Tokens regularly if you do.
Worked example
A finance team wants an assistant that answers questions about the ledger but must never change it. A credential is created with the Read capability, and its identity is granted rights to the ledger datastores only. Even if a future change raised its capability to Write by mistake, it still could not touch casework — because the permissions, not the capability, decide what it can reach.
Revoking
Revoke through OAuth Tokens rather than deleting the credential row — revocation is immediate and leaves the history, whereas deletion loses the record of what that credential did.
Recommendations
- One credential, one client, one purpose.
- Read first, always. Escalate on evidence of need.
- Constrain by permissions, not by capability alone. Capability is the ceiling; permissions are the walls.
- Review issued tokens quarterly and revoke anything you cannot account for.