Skip to main content
Are you an AI agent, or building one?Start with Authentication for AI agents — it points to the machine-readable manifest an agent can fetch and follow on its own.
Every agent-callable Nevermined endpoint is authenticated by a single bearer token. The full mechanics — the exact header, the per-tier base URLs and key prefixes (sandbox:… / live:…), what a Nevermined key actually is, and how to read a 401 — are the canonical, always-current auth.md manifest. This page covers the decisions around that ceremony: which path to use, which credential each yields, and the per-tier discovery quirk.

​
Which path do I use?

SDK key

You can run an SDK and manage your own identity. The simplest path — the SDK mints a key directly. See Get a Nevermined API key.

Device flow (RFC 8628)

You’re a headless agent with no browser, but a human can approve for you. Approval is collected without a browser on your side — typically ending in an NVM API key bound to the approver. See Device flow.

Authorization Code + PKCE

You’re a browser-based MCP client (Cursor, Claude). The user approves in a browser — typically to obtain an x402 payment permission for a specific agent. See Authorization Code.
The credential you receive is chosen by the requested resource, not by the grant. A resource (RFC 8707 audience) matching this API’s host mints an NVM API key; any other resource mints an x402 payment permission. An account_access consent always yields an API key; with no resource, a delegation-backed binding yields an x402 permission and a plan-only binding yields an API key. The two grants differ only in how the human approves — Authorization Code in a browser, the device flow without one — so pick the grant by your environment and the resource by the credential you need.

​
Discovery

Everything the ceremony needs is advertised in standards-based OAuth metadata — the RFC 8414 authorization-server document, the RFC 9728 protected-resource document, and the JWKS. See auth.md for the endpoint list and what each returns. If a capability is absent from these documents, it does not exist — don’t infer it.

​
Each tier is its own issuer, and its authorize URL says so

Sandbox and Live are separate authorization servers with separate discovery documents (https://api.sandbox.nevermined.app/.well-known/oauth-authorization-server and https://api.live.nevermined.app/…), but both send the human to the same web app for consent. That app cannot tell from a bare /oauth/authorize link which issuer it is acting for, so the human-facing endpoints carry the tier as a query parameter:
network is sandbox or live — the same parameter the embeddable widgets take, and distinct from the x402 request body’s network field, which names the settlement rail (eip155:<chainId>, or stripe / braintree / visa — details), never a tier. The device flow’s verification_uri carries it too. Keep the query string when you append your own parameters (RFC 6749 §3.1 requires it). Not every client does: the official Python MCP client (mcp, every release through 2.2.0) concatenates a second ?, producing …?network=sandbox?response_type=code&… — the consent page tolerates that shape, taking the tier from the head and recovering the one swallowed parameter, so such clients still work; but do not rely on it for a client you control — extend the query with &. A discovery-driven client gets the right value for free; if you configure an OAuth provider by hand — a connector’s “authorization URL” form field, say — copy the endpoint from the tier’s discovery document, query string included. The endpoint must end up as …/oauth/authorize?network=sandbox or …?network=live; if the document you fetch carries no network, append it yourself. An authorize link without network is served on whichever tier the user’s browser last used (Live by default), and a connector registered only on Sandbox is then refused as “Connector not authorized” until the user switches manually.

​
What needs a human

Three things require a person in the loop — card enrolment (the card is tokenized in-browser, never reaching Nevermined), first-account creation, and creating a provider=visa delegation (a per-delegation FIDO/passkey device-binding ceremony). You can use an existing Visa delegation, and Stripe, Braintree, and crypto delegations you create yourself. auth.md documents each, and why, in full.

​
Next steps

Authentication for AI agents

The machine-readable manifest an agent fetches and follows.

Device flow (RFC 8628)

Get an API key with a human’s approval, no browser on your side.

Authorization Code + PKCE

Browser-based MCP clients paying for a specific agent.

Connected agents

List and revoke the agents a user has authorized.