Frequently asked questions#

Straight answers about authenticating agents and people with Grantor: MCP server auth, anonymous agent identity, OAuth with no authorization server, and how a caller onboards itself. Grantor is live on Base mainnet (chain 8453) as an unaudited developer preview; a free test path runs on Base Sepolia (84532).

How do I add authentication to an MCP server?#

Install a Grantor deed guard and publish a discovery document — there is no authorization server, no OAuth redirect, and no service to run. Agents authenticate with a deed, a self-certifying credential your server verifies in-process against a public on-chain registry (one eth_call), then treats as identity. Two modes cover the common cases: user-sig gates any wallet-holding caller, and agent-zk gates a fleet you enrolled on-chain. Install with npm i @grantor/verify (also on PyPI and crates.io); the full recipe is in MCP server auth.

How can an AI agent authenticate to an API without revealing its identity?#

Use an agent-zk deed. The agent proves in zero-knowledge that it is an enrolled member of the API owner's on-chain registry without revealing which member — the verifier learns "an authorized agent" plus a stable pseudonym, and a per-use nullifier prevents replay. Because the pseudonym is scoped and the proof discloses only membership, there is no correlation between which agent authenticated and which server it called. Minting and verifying an agent-zk deed both ship in TypeScript, Python, Go and Rust; see Agent tokens.

Can an AI agent pay for and access a gated API on its own, with no human?#

Yes. Becoming a paying tenant is four ordinary contract calls — createTenant, topUp, drawPeriod, then enroll a key — paid in USDC on Base, with no signup, no form, and no server on the other end. An agent that earns USDC (for example through x402 settlements on the same chain) funds its own access with the same asset in the same place, no facilitator or bridge in between. The npx grantor-onboard kit automates every step; the only human moment is funding the wallet once. See self-onboarding and getting started.

Can I pay with a card, or do I need crypto already?#

You can start from a card. The registry itself bills in USDC on Base — a public contract, not a payment processor — but getting from a debit card to a funded tenant is about fifteen minutes, and one asset is enough: buy ETH on any major exchange or through your wallet's built-in onramp, withdraw on the Base network, then register — the register page swaps ETH to USDC on-chain inside the payment transaction, and gas comes from the same ETH. (Buying USDC directly works too; then add a couple of dollars of ETH for gas.) KYC, when it happens, happens with the exchange or onramp — never with Grantor, which has no account to attach it to. The step-by-step walk-through, including the wrong-network mistake to avoid, is Fund with a card.

Already holding a different token? Where available, the register page offers a pay-with-what-you-have flow: it swaps that token to USDC on-chain, inside the same transaction that funds your tenant. The registry itself always bills in USDC — the swap happens in your own transaction, not through Grantor or any off-chain conversion — and paying USDC directly stays the default, always-available path.

What is "OAuth without an authorization server"?#

It is Grantor's model: instead of an issuer that mints and holds tokens, the credential — a deed — self-certifies. The relying app verifies it in-process against the public on-chain GrantorRegistry (the trust anchor and billing ledger) and mints its own standard OIDC JWT that any JOSE library validates. There is nothing to run, trust, or subpoena: Grantor operates no hosted service and holds no keys, so a relying party depends on the chain, not on a company. The full model is in the sovereign tier.

How do I let on-chain members sign in without revealing which member they are?#

Use zero-knowledge membership deeds against a tenant-curated on-chain allowlist: agent-zk for machine callers, user-zk for humans. The holder proves membership in your registry tree in zero-knowledge, so the relying app receives a stable pseudonym and "is a member" — never the specific identity — and revocation works by rotating the tree's root. Both modes use the same Semaphore-based proof over different trees, verified in four languages against a shared conformance suite. See user gating and agent tokens.

Is there an anonymous OAuth — sign in with no email, no account, no password?#

Yes, for both people and agents. A human signs in with a wallet and the relying app receives a pairwise pseudonym scoped to (tenant, origin) — never an email, password, or wallet address — unlinkable across sites. Grantor stores no user secret and runs no server: the key never touches it, so there is no credential database to breach and nothing to leak. See wallet login.

How do I limit what my AI sub-agents are allowed to do?#

Don't hand them your credentials — grant them a bounded capability. The @grantor/mcp permission broker (npx -y @grantor/mcp serve) exposes five MCP tools: grant mints a capability for a child identity (named tools only, a use budget, an expiry), delegate narrows it onward (a child can attenuate authority, never widen it — widened tools are refused at signing and the chain walk re-enforces narrowing cryptographically), check gates each action against a live on-chain read plus a local use meter, and revoke is a real on-chain revocation. No authorization server anywhere; the zero-setup sandbox works in under a minute. Watch the whole mechanism run in your browser — grant, narrow, deny, revoke, live against mainnet — at the delegation playground. See the permission broker guide.

Can I put permissions on an MCP server I didn't write?#

Yes — run it behind the broker's enforcing proxy: grantor-mcp wrap --tools search,fetch --max-uses 20 -- npx that-server. The wrapped server keeps working unmodified; tools you didn't grant are denied before the server sees them, granted tools are metered, resources are denied by default, and an on-chain revocation lands on the next call. No authorization server anywhere. See the permission broker guide.

My deed was rejected — how do I find out why?#

Paste it into the Inspector. It replays the same staged checks a verifier runs — decoding, signature or proof, delegation chain, then the on-chain billing read — and shows you exactly which stage failed, with every stage that passed still visible. No server, no upload: everything runs against public chain reads from your own browser. See the errors guide for what each code means once you know which one you hit.

How does an agent discover it needs auth and onboard itself?#

Every rejection is a machine-followable funnel, not a dead end. A 401 carries WWW-Authenticate: Grantor-Deed plus a learn URL — /.well-known/grantor-onboard.json, identical everywhere — pointing at a schema-versioned onboarding manifest and its narrative twin. An agent parses it, becomes a tenant, and gates its own resources with no human, browser, or consent screen. The protocol surface is the documentation; the walkthrough is self-onboarding: 401 to paying tenant.