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.

DEV Community: Grantor

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