# 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).

## 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 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).