DEV Community: Grantor

How one AI agent hands another less than everything

Grantor — Tue, 08 Sep 2026 13:45:00 +0000

A2A and MCP solved how agents talk and what they can call. Neither says
anything about the moment that actually matters in a multi-agent system:
agent A asks agent B to do something on A's behalf. B now needs some of
A's authority — and today "some" isn't on the menu. A shares its
credentials (B gets everything), or B uses its own standing credentials
(which quietly accumulate every permission any task ever needed).

The missing primitive is a delegation: a signed statement that hands
another identity a bounded slice of your authority. Here's the grammar,
one grant:

{
  "res": "mcp://acme/tools/*",
  "act": ["call"],
  "cav": { "exp": 1786015180, "max_uses": 100, "nb": { "tool": "search|fetch" } }
}

A resource pattern, the actions allowed on it, and caveats: an expiry, a
use budget, and named request predicates (nb — the request's tool
argument must be exactly search or fetch). Agent A signs a
Delegation link handing that grant to B's identity:

import { delegationBinding, parentRefHashRoot, delegate } from "@grantor/sdk";

const bindingHex = delegationBinding(tenantId, iss, to, grantsJson, exp,
                                     epochLabelHex, epoch, parentRefHash);
const signatureHex = await sign(bindingHex); // A's own secp256k1/EIP-191 signer
const link = delegate(tenantId, iss, to, grantsJson, exp,
                      epochLabelHex, epoch, parentRefHash, undefined, signatureHex);

B attaches the link to its own deed (its normal login credential) and
presents the pair. The verifying service makes one call —
verifyWithCapabilityAt — and gets back B's proven identity plus the
grants that survived the chain walk, then enforces each request with
CapabilityGuard.authorize.

The rules the verification actually enforces are where this stops being a
JSON convention and becomes a security boundary:

The chain's root must be a registered on-chain key. A delegates because the registry for its tenant says A's key exists and hasn't been revoked. A chain rooted anywhere else fails, period.
Every link must narrow its parent. Subset of the resources, subset of the actions, caveats no looser. B can re-delegate to C — search only, 5 uses — but a link that widens anything is a BadDelegation at verify time, no matter what any broker claimed at signing time.
A pin can't be narrowed — only carried. A grant can also pin the canonical hash of the tool descriptor it was signed for. Predicate equality is exact, so a child cannot hand on a "smaller" pinned set the way it can drop a resource: it inherits the parent's pin verbatim or the link fails to narrow. A descriptor pin therefore travels the whole subtree automatically, and no intermediate agent can quietly drop it.
The last link must name the presenter. The chain ends at B's proven sub; a stolen delegation attached to someone else's deed doesn't verify.

Revocation is the part I'd underline. Each link is signed against a
revocation cohort (epoch_label). One transaction —
GrantorRegistry.bumpEpoch — invalidates every link in that cohort:
A's grant to B, B's narrower grant to C, the whole subtree, everywhere,
on the next check. No calling around to services that cached a token, no
per-child cleanup. Label cohorts per project, per incident domain, per
whatever blast radius you want a single kill-switch for.

And one property with no OAuth analogue at all: anonymous delegation.
A fleet member can delegate without revealing which member it is —
delegateZk authenticates the link with a zero-knowledge membership proof
over the tenant's on-chain registry instead of a recoverable signature.
The verifier learns "a real, current, paid-up member of this fleet granted
this," plus a stable per-tenant pseudonym — and with a per-chain salt, two
delegations from the same member can't even be linked to each other.

Honest edges: max_uses rides in the grant but counting real uses needs
durable state only your app can own, so the guard checks it as a bound and
your service (or the broker below) does the metering; the ZK-delegation
proving path is real but the deeper structure-hiding variant is explicitly
preview-labeled; all of it is an unaudited developer preview.

You can watch this exact arc — grant, delegate narrower, attempt, DENIED,
revoked live on-chain — run in your browser against the Base mainnet
registry: https://chaingrantor.com/playground.html

If you'd rather not hand-roll the signing, npx -y @grantor/mcp serve
packages exactly this arc — grant, delegate, check, revoke — as five MCP
tools with the key custody handled for you (and grantor-mcp wrap makes
it enforcing for any stdio MCP server); that's what post #1 walked
through: https://dev.to/grantor/give-your-ai-sub-agent-a-budget-not-your-keys-2e7h
Full grammar and verification docs:
https://chaingrantor.com/docs/guide/capabilities

MCP standardized what agents can call. A2A standardized how they talk.
Delegation is what authority looks like when it moves between them — and
it should only ever get smaller.

Auth for your MCP server, without running an authorization server

Grantor — Tue, 01 Sep 2026 00:05:19 +0000

You built a remote MCP server. It's useful, so now strangers' agents want
to call it, and you need to answer the question every remote server hits:
who's allowed in?

The MCP spec's answer is OAuth 2.1: put an authorization server in front,
register clients, issue tokens. Which is correct, and heavy. An
authorization server is a stateful, security-critical service with a user
database — you run it or you rent it, and either way it's now load-bearing
infrastructure for what might be a weekend project. It also assumes your
callers can do an OAuth dance, and that you want accounts.

Here's the shape with no authorization server anywhere: the credential —
called a deed — certifies itself. An agent mints one locally by signing
a challenge you issued (or by proving fleet membership in zero knowledge —
more below). Your server verifies it with a library: local crypto plus one
eth_call to a public registry contract on Base, served by any RPC
provider. No token service, no client registration, no user table. Your
whole auth stack is three routes:

import { DeedVerifier, sessionJwt } from "@grantor/verify";
import { grantorExpress } from "@grantor/verify/express";
import { Registry } from "@grantor/verify/registry";

const verifier = new DeedVerifier(
  RPC_URL, Registry.canonical(), CHAIN_ID, TENANT_ID,
  AUDIENCE, ORIGIN, MAX_TTL_SECS, CACHE_TTL_SECS,
  false, Math.floor(Date.now() / 1000),
);

const g = grantorExpress({
  verifier, app,
  challengeEndpoint: "/auth/challenge",
  chainId: CHAIN_ID,
  modes: ["user-sig", "agent-zk"],
  vouchSignature: VOUCH_SIGNATURE, vouchEpoch: VOUCH_EPOCH, vouchExp: VOUCH_EXP,
});
app.get("/auth/challenge", g.challenge);

That one call also auto-publishes GET /.well-known/grantor-deed — a
discovery document naming your tenant, chain, modes, and challenge
endpoint — and self-checks it at startup, so a misconfiguration fails your
boot, not your first user's login.

The second route exchanges a deed for a session, the way a token endpoint
would — an MCP client authenticates once, not per request:

app.post("/auth/token", async (req, res) => {
  const { deed, challenge } = req.body;
  const claims = await g.guard.verify(JSON.stringify(deed), challenge);
  // claims.sub is a verified, pseudonymous subject — recomputed by the
  // verifier, not read from the deed. Mint YOUR session from it:
  res.json({ session_jwt: sessionJwt(claims.sub, AUDIENCE, BigInt(TENANT_ID),
    SIGNING_KEY_PEM, BigInt(now), BigInt(TTL), { iss: ORIGIN }) });
});

sessionJwt mints a plain ES256 JWT with your key — any JOSE library
verifies it without ever importing this SDK. The third route is your
existing MCP transport, gated on that session. That's the entire surface.

Three properties you don't usually get from a weekend auth setup:

Rejections teach the caller. Every 401 carries WWW-Authenticate: Grantor-Deed … plus discovery/learn fields pointing at your discovery document and a machine-readable onboarding manifest. The guard also serves RFC 9728 protected-resource metadata, so an MCP-spec OAuth client discovers what your server needs the standard way. A capable agent that gets rejected can read its way to authenticated — no human writes an integration ticket. (All of it opt-out with one flag if you want silent 401s.)
You can authenticate a whole fleet without an allowlist. With agent-zk in modes, any agent enrolled in your tenant's on-chain registry proves membership in zero knowledge — no per-agent config on your server, and you learn a stable pseudonym per agent, not a wallet address. Membership answers who may call; it does not answer what they may do. For consequential tools, pair it with a capability grant — a resource plus caveats, narrowed at every delegation hop and checked locally per request — so a valid subject doesn't silently gain reach as you add tools. npx -y @grantor/mcp wrap puts that in front of any stdio MCP server without code changes.
Billing is enforced where verification happens. The verifier checks the tenant's on-chain status during the same read, and fails closed if the chain is unreachable. Nobody can verify deeds against a lapsed tenant.
A session is a bearer token, and behaves like one. sessionJwt mints from verified claims with your key and ignores the deed's own expiry — so an already-issued session outlives a tenant lapse or a revoked grant until it expires. Deed verification is a library call plus one eth_call, not a round trip to an introspection service, so re-verifying per call on consequential routes costs you a chain read, not an architecture. Short sessions for cheap reads; re-verify where it matters. Full timing model: https://chaingrantor.com/docs/guide/revocation-latency.html

What it costs, honestly: you need a tenant on the registry (createTenant
plus USDC funding on Base — a few contract calls, no signup form, because
there is no server to sign up with) and a signed origin vouch for wherever
your server runs, which is what lets a well-behaved agent refuse to
authenticate to a hostile origin impersonating you. The whole thing is an
unaudited developer preview. The guard ships in TypeScript, Python, Go,
and Rust, so this isn't an Express-only story.

Full guide, transcribed from a runnable reference server:
https://chaingrantor.com/docs/guide/mcp-server — and #1 in this series
covers the other direction, gating what your own sub-agents may do
(including wrapping any third-party MCP server so enforcement is
structural, not voluntary):
https://dev.to/grantor/give-your-ai-sub-agent-a-budget-not-your-keys-2e7h

OAuth told us auth needs an authorization server. For agents, it needs an
authorization — the server part turns out to be optional.

Update: two corrections above, prompted by a good question in the comments.
The fleet bullet originally read "membership is the authorization," which is
true of identity and false of authorization; and the post didn't state that a
minted session outlives on-chain revocation. Full timing model, including what
is and isn't cached:
https://chaingrantor.com/docs/guide/revocation-latency.html

Give your AI agent GitHub access that expires in an hour

Grantor — Tue, 25 Aug 2026 21:16:33 +0000

You set up an agent to triage issues overnight. It needs GitHub, so you do
the obvious thing: create a PAT, drop it in the environment, go to bed.

Now inventory what you actually deployed. The token is in the environment —
so it's in the environment of every sub-agent the orchestrator spawns, every
tool process they exec, every log line that dumps env on a crash. It's
valid for however long you set at creation (days, realistically — nobody
regenerates a PAT per task). And if one worker goes sideways at 3am, your
revocation story is "delete the token", which also kills every other
agent, pipeline, and script using it.

GitHub's own answers help less than you'd hope. Fine-grained PATs scope
nicely but you mint them by hand in a web UI — there's no "create a
one-hour token for this sub-agent" API call. GitHub Apps do mint
short-lived installation tokens, but now you're operating token-minting
infrastructure, and the token still doesn't subdivide: two sub-agents under
one installation hold the same authority.

Here's the reframe that makes this tractable: the sub-agent never needed
the token. It needed permission to perform three specific GitHub actions,
for an hour. Those are different things, and conflating them is the whole
problem.

So separate them:

The PAT lives in exactly one process — the tool server that actually calls the GitHub API (your GitHub MCP server, running in the parent's trust domain). It never enters an agent's context window or environment.
Sub-agents get a capability: a signed, bounded permission to invoke named tools on that server. The tool server checks the capability before every call.

The broker that does step 2 is an MCP server you run locally:

npx -y @grantor/mcp serve
# or wire it into Claude Code:
claude mcp add grantor-mcp -- npx -y @grantor/mcp serve

(Want to watch a denial happen before wiring anything real?
npx -y @grantor/mcp demo — thirty seconds, zero setup, and the refusal
happens in your own terminal.)

The overnight-triage grant looks like this:

grant    {tools: ["issue_read", "search_issues", "add_issue_comment"],
          max_uses: 50, ttl_secs: 3600}
         → {child_id: "…", sub: "…"}

Those are GitHub's official MCP server's real tool names
(ghcr.io/github/github-mcp-server). Any stdio MCP server wraps the same
way — the broker doesn't care what's behind the --.
The sub-agent gets the child_id (never a key; the broker holds those),
and the tool server gates every invocation:

check    {child_id, tool: "add_issue_comment"}
         → {allow: true, remaining_uses: 49}

check    {child_id, tool: "merge_pull_request"}
         → {allow: false, code: "CapabilityDenied"}   # never granted

An hour later the grant's expiry caveat has passed and every check on
that child is denied (CapabilityDenied, naming the failed caveat) — with
the PAT untouched. If the triage agent spawns its own worker to draft comments,
it can pass down a strictly narrower slice:

delegate {parent: child_id, tools: ["add_issue_comment"], max_uses: 10}
         → {child_id: "…"}

Asking for a tool the parent doesn't hold is refused before anything is
signed; asking for more uses or a longer expiry silently clamps to the
parent's bound.

And if your GitHub tool server speaks MCP, you don't even need it to call
check voluntarily — put it behind the enforcing proxy and the boundary
is structural. Don't know what your server exposes? Ask it:

npx -y @grantor/mcp tools -- docker run -i --rm \
  -e GITHUB_PERSONAL_ACCESS_TOKEN ghcr.io/github/github-mcp-server
# lists its 44 tools, marks the write-shaped ones, and prints a
# ready-to-paste wrap suggestion (a name heuristic — review it)

Reviewing is not optional theater: the suggestion holds add_issue_comment
back as write-shaped — correctly — and the triage bot's whole job is
commenting, so you add that one back on purpose. The heuristic proposes;
you decide. Then wrap:

grantor-mcp wrap --tools issue_read,search_issues,add_issue_comment \
  --max-uses 50 --ttl-secs 3600 -- docker run -i --rm \
  -e GITHUB_PERSONAL_ACCESS_TOKEN ghcr.io/github/github-mcp-server

(Note where the PAT lives: -e GITHUB_PERSONAL_ACCESS_TOKEN with no value
forwards it from your shell into the server's container — the one process
from step 1 — and nowhere an agent can read. The official server also has
its own --read-only and toolset flags, and they compose fine; what the
wrap adds is the part flags can't: per-sub-agent budgets, expiry,
delegation that only narrows, and one-call revocation.)

Now the server never sees a request that wasn't authorized, and the
sub-agent's tool list only contains what you granted. When the agent
reaches for the merge button anyway, this is what lands in your terminal:

┌─ DENIED ───────────────────────────────────────────────────────────────────┐
│  requested      merge_pull_request                                         │
│  grant allows   issue_read, search_issues, add_issue_comment               │
│  refused as     CapabilityDenied — tool not granted                        │
│                                                                            │
│  Denied by the grant, not by a prompt — the server never saw the call.     │
│  revoke everything:   grantor-mcp revoke --child 7c9e12aa-triage           │
│  what just happened:  https://chaingrantor.com/docs/guide/first-denial.html│
└────────────────────────────────────────────────────────────────────────────┘

And this isn't a policy file the broker consults — the
delegation chain is cryptographically signed link by link, and every
check re-verifies the narrowing math, so a child can't widen its slice
even if the broker's pre-check drifted.

The 3am story is one call:

revoke   {child_id}

In your own tenant that bumps a revocation epoch on a public smart contract
on Base, and every capability in that cohort — the triage agent and the
worker it delegated to — fails its next check, no matter which process
holds it. The PAT keeps working for everything else you own. That's the
inversion worth noticing: revocation used to be the expensive, blast-radius
operation, and now it's the cheap, surgical one.

Honest limits, same as last time: this is an unaudited developer preview;
the zero-setup run points at a live shared sandbox tenant on the production
registry (real chain, real verification, a publish-on-purpose demo key that
controls nothing outside the sandbox); use-metering is local to your broker
process. And the capability bounds access to your tool server — GitHub
itself still sees one PAT, so the tool server remains the enforcement
point. That's the design, not a gap: one place holds the secret, everything
else holds bounded, expiring, revocable permission to use it.

Production is one contract call away (USDC on Base, no signup — the
register page even takes ETH or any liquid token and swaps it on-chain
inside your own transaction). The 60-second walkthrough of everything
above, ending in a mid-flight revocation:
https://chaingrantor.com/docs/guide/first-denial — broker docs:
https://chaingrantor.com/docs/guide/mcp-broker — or watch the whole
grant → narrow → deny → revoke arc run live against mainnet in your
browser at https://chaingrantor.com/playground.html. The first post in
this series covers the general budget model:
https://dev.to/grantor/give-your-ai-sub-agent-a-budget-not-your-keys-2e7h

Your agents don't need credentials. They need permissions with an expiry
date.

Give your AI sub-agent a budget, not your keys

Grantor — Fri, 21 Aug 2026 19:06:18 +0000

Spawn a sub-agent in CrewAI, LangGraph, AutoGen, or a Claude sub-agent
setup and check what it actually holds: your credentials. The parent's
keys, at full scope, forever. The throwaway agent you created to summarize
three PDFs can call every tool your orchestrator can, and the only
"revocation" is rotating keys everywhere at once.

We accept this because handing a child less than everything has been
genuinely hard: OAuth scopes need an authorization server someone runs;
role systems need an admin; API keys don't subdivide. So the ecosystem
quietly standardized on "copy the parent's environment" and moved on.

Here's a different shape, as an MCP server you run locally:

npx -y @grantor/mcp serve
# or wire it into Claude Code:
claude mcp add grantor-mcp -- npx -y @grantor/mcp serve

That gives any MCP-speaking framework five tools. The whole model fits in
one transcript:

grant    {tools: ["search","fetch"], max_uses: 20, ttl_secs: 3600}
         → {child_id: "…", sub: "…"}          # a bounded child identity

check    {child_id, tool: "search"}
         → {allow: true, remaining_uses: 19}   # gate EVERY action on this

check    {child_id, tool: "write"}
         → {allow: false, code: "CapabilityDenied"}   # not granted → denied

delegate {parent: child_id, tools: ["search"], max_uses: 5}
         → {child_id: "…"}                     # a narrower grand-child

revoke   {child_id}
         → revoked                             # authority withdrawn

The interesting properties are in what you can't do:

A child can never widen its slice. Asking delegate for a tool the parent doesn't hold is refused before anything is signed. Asking for more uses or a longer expiry silently clamps to the parent's bound. This isn't a policy file the framework consults — the delegation chain is cryptographically signed link by link, and verification re-checks the narrowing math on every check.
Budgets actually run out. max_uses: 20 means the 21st check is denied with UsesExhausted, not logged-and-allowed.
Revocation is real. In your own tenant, revoke bumps a revocation epoch on a public smart contract; every capability in that cohort fails its next check no matter which process holds it.

And the part that makes this different from every "policy engine" you've
seen: there is no server. No authorization service, no policy backend,
no vendor API in the hot path. Authority anchors to a public registry
contract on Base; verification is a local computation plus one eth_call
that any RPC provider can serve. The broker runs on your machine, next to
the framework it guards, and holds the child keys so your agents never see
key material at all.

The zero-setup run above works because the package ships pointed at a
live shared sandbox tenant on the production registry — real chain, real
verification, publish-on-purpose demo key that controls nothing outside
the sandbox. Honest limits: it's an unaudited developer preview, the
sandbox broker self-issues its anti-replay challenge (it's holder and
verifier in one process), and use-metering is local to the broker.

Production is one contract call away (USDC on Base, no signup — your
agent can even read the machine-readable onboarding manifest and do it
itself). Docs: https://chaingrantor.com/docs/guide/mcp-broker

MCP standardized what agents can
call. A2A standardized how they talk. Nobody standardized what they're
allowed to do — that's the layer this fills.