Capabilities & the surface

An agent’s grant can only contain scopes that already exist. Those scopes come from the capability surface: the set of tools and resource operations your deployment exposes, each with a scope. This page explains where scopes come from. Grants explains how a grant assigns them to an agent.

Two kinds of capability, two namespaces

An agent acts through two different channels, and auth51 keeps them in separate scope namespaces so each answers a different question.

• mcp:tool:<server>:<tool>may this agent invoke this tool?

  A tool-invocation scope. One per tool the agent can call, whether an in-process function it ships with or a tool rented from an MCP server.

• a51:rs:<rs>:<method>:<path>may this token perform this operation?

  A resource-endpoint scope. One per operation on a resource server, e.g. a51:rs:github.api:delete:/repos/{id}. It names the effect, not the tool that causes it.

These are not redundant. A tool is how an agent acts. An endpoint is what happens at the resource. One tool can call several endpoints, and one endpoint can be reached by several tools, so the link between them is an explicit mapping (below), not an equality.

Tool scopes: the installed surface

Every tool your agents can reach is registered as a capability: a (server, tool) pair with its scope and a risk tier. They arrive two ways.

MCP tools, the ones your agents rent from MCP servers, are registered as a batch at CI/CD or install time. Each gets an mcp:tool:<server>:<tool> scope.

In-process tools, functions the agent ships with, have no separate registrar, so they are folded into the surface when the agent registers, under a reserved __inprocess__ server. They are also part of the agent’s identity checksum, because they are part of its code. A rented MCP tool is swappable, so it is not.

Endpoint scopes: the RS catalog

A resource server publishes its OpenAPI, or a plain list of operations, to the Authority. For each operation the Authority derives one a51:rs:* scope, using a fixed, reversible function of (rs id, method, path template). The scope is the operation: you can read the method and path back out of it, and the same function run anywhere produces the same string.

Linking them: tool to scope

Which endpoints a tool actually calls is a many-to-many mapping. auth51 establishes it highest-confidence first:

1. 1.Declared. The registrant states which scopes a tool uses, at registration. This is the governed path and the highest trust.
2. 2.Static. Inferred from the tool’s source: path-like literals matched against the RS’s registered routes. A proposal, at lower confidence.
3. 3.Observed. Learned from what the tool actually calls at runtime.
4. 4.Fail-closed. If none of these establishes a mapping, the tool carries no endpoint scope. auth51 does not invent authority it cannot substantiate.

This happens in the control plane

Registering capabilities, cataloguing a resource server, and mapping tools to scopes are all writes, done ahead of time when your surface changes. None of it happens on the request path. At mint the Authority reads the grant it already derived. At the resource the verifier derives and checks one endpoint’s scope. A live request never changes what can be granted.