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

A developer has released Grantor, an MCP server that gives AI sub-agents cryptographically bounded permissions instead of full access to the parent's credentials. The tool, available via npx, allows granting limited tool access with usage caps and time-to-live, and supports delegation and revocation through a public smart contract on Base. It aims to solve the problem of sub-agents inheriting excessive privileges in frameworks like CrewAI, LangGraph, and AutoGen.

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: 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 . max uses: 20 means the 21st check is denied with UsesExhausted , not logged-and-allowed. 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 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.