# 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](guide/mcp-server.md).

## 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](guide/agent-tokens.md).

## 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](ONBOARD.md) and [getting started](guide/getting-started.md).

## 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](/register.html) — 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](guide/fund-with-card.md).

Already holding a different token? Where available, the [register
page](/register.html) 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](sovereign-tier.md).

## 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](guide/user-gating.md) and
[agent tokens](guide/agent-tokens.md).

## 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](guide/wallet-login.md).

## 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](/playground.html). See the
[permission broker guide](guide/mcp-broker.md).

## 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](guide/mcp-broker.md).

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

Paste it into the [Inspector](/inspector.html). 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](guide/errors.md) 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](ONBOARD.md).