MCP Authorization
MCP Inventory answers what exists. MCP Call Evidence answers what happened. MCP Authorization answers the question between them: should this call have been allowed at all?
Note: This release ships MCP Authorization as an API only — there is no screen for it yet, which is why this page carries no screenshot. Grants, resource policies and the convergence state are managed through the API; the console view is a later release, and screenshots will be added with it.
Until this release the answer was only ever computed for agent-owned connections. Every other connection — a person's own credential, or one shared across a tenant — reached its MCP server with nothing consulted. That was not a policy permitting those calls; it was a question nobody asked.
What changed
- Every connection scope is authorized —
agent,userandtenant. A connection that is not owned by an agent is authorized as its owner: the person who created the credential, or the tenant it belongs to. - Credential grants — decide what a principal may reach. A grant binds a principal to a specific credential or server, optionally narrowed to named tools, with an authentication mode and an expiry.
- Resource policies — decide what may happen to a tool, whoever is calling: "require
approval for
close_ticketon ITSM", "never allowdelete_*on Jira". - Per-run tokens — replace the long-lived connection token an agent run used to carry, so a call can be attributed to the run, the agent and the delegating person rather than only to a connection.
Credential grants
A grant answers "may this principal use this credential, for this tool?"
- Principal — an agent identity, a user, or a tenant.
- Subject — one credential, or a whole MCP server.
- Tools — named tools, or every tool the subject exposes.
- Authentication mode — a grant may permit an interactive connection and refuse the same credential used by an unattended run.
- Expiry — optional; an expired grant stops matching.
Note: A grant covers only the server it was created for. Holding a grant for one MCP server never authorizes calls to another.
Four distinct refusal reasons are recorded, because they need different fixes: no grant for this principal on this server, a grant that does not cover this tool, an expired grant, and a grant that does not permit this authentication mode.
Grants start in observe mode
Existing grants were inferred from credentials your agents and people already use. That is the best available evidence of who is entitled to what, and it is an inference rather than a decision anyone recorded — so enforcement is off by default, per tenant.
log(the default, and the state every tenant upgrades into) — the decision is evaluated and recorded, and the call proceeds regardless.enforce— the decision is evaluated, recorded, and honoured.
Nothing is refused on upgrade. Before switching a tenant to enforce, read the recorded counts:
they show exactly which calls would have been refused, for which principal, and how often. A
tenant with no log-mode refusals can be switched with no user-visible change.
Resource policies
A resource policy is a rule about the tool or the server, and it applies whoever is calling.
deny— the call is refused.escalate— the call is refused now, and a pending approval is raised for a person to decide.allow— this policy does not object. It does not widen a principal's authority: the credential grant still has to permit the call.
Patterns are globs — delete_*, jira/*, close_ticket — and the most specific rule wins, so
a narrow exception can be carved out of a broad rule. A policy may carry a business-hours window in
your own timezone.
Note: Unlike credential grants, resource policies take effect immediately. A grant is inferred, so it is observed first; a resource policy is something you deliberately wrote, and a rule that does nothing until a flag is flipped is a rule you believe is protecting you and is not. No policies exist until you create one.
Per-run tokens
An agent run now receives a token that is specific to that run. It carries the agent identity, the delegating person and the declared authority mode, is stored only as a hash, and expires — by default after two hours.
Long-lived connection tokens continue to work, so nothing needs changing on upgrade. Revoking a connection now also revokes the run tokens issued against it, which previously stayed usable until their own expiry.
External servers
MCP servers registered outside the Hub catalogue are being routed through Hub so they inherit the same OAuth handling, network protection, per-call authorization and audit as first-party servers.
Each external server carries a convergence state: converged, exempt, or pending. A server that genuinely cannot be proxied is marked exempt and governed in place — and an exemption must record why, so a deliberate exception stays legible as one.
Every external server starts as pending, so the estate reports honestly on the day you upgrade rather than appearing already finished. Reading the state returns both the counts and the servers still awaiting a decision, because the count alone tells you the work is unfinished without telling you what is left.
| Permission | What it allows |
|---|---|
mcp_servers:read | Read the convergence counts and the list of servers still pending. Included in the analyst and viewer roles. |
mcp_servers:decide | Record that a server was converged or exempted. Not included in analyst or viewer — only an administrator holds it. |
Note: Marking a server exempt is what stops it counting as outstanding, which is why it needs a permission of its own. Somebody who can read the estate cannot make the number of undecided servers go down.
Best Practices
- Read the observed counts before enforcing. The point of
logmode is the number it produces. Switch a tenant only when you understand every remaining case. - Prefer a narrow grant. A grant with no named tools covers every tool the subject exposes; name the tools where you can.
- Use
escalaterather thandenyfor reversible actions. A denial ends the run; an escalation leaves somebody able to say yes. - Give every exemption a real reason. Six months later it is the only thing distinguishing a decision from an oversight.
Related Pages
- MCP Inventory — which MCP servers exist and which credentials reach them
- MCP Call Evidence — the record of every tool call that ran