Connect from your agent app
If your agent lives in an app you do not run — Claude, Claude Code, or any assistant that lets you add a custom MCP connector with OAuth — it can use Regent without code and without keys to paste. You add one URL, sign in, and approve a consent screen. From then on the app’s agent acts under a mandate you set, and every payment it attempts is decided first and leaves a signed receipt.
- Connector URL:
https://gw.regentprotocol.org/gw/mcp - Sign-in: OAuth 2.1 with PKCE; the app registers itself, you never copy a client id or key
- Verified with: Claude.ai (web and desktop) and Claude Code. Other apps with the same connector shape are listed below; we add each one here after running it ourselves.
One connector is one agent. Connecting the same Regent organization from a second app creates a second agent with its own mandate, receipts and history. Disconnecting in the app revokes that agent’s access.
What happens when you connect
Add the connector in the app
Paste the connector URL where the app asks for a custom MCP server. Choose the option that lets the app register itself automatically; leave any client id or client secret field empty. The app discovers Regent’s sign-in through the standard metadata documents, so there is nothing else to configure.
Sign in to Regent
The app opens Regent’s sign-in page in your browser. If you have no account yet, the self-serve signup gives you a sandbox organization (test rail, no identity verification) — enough to connect and see the whole loop. Verify your email before you start the connection; the app’s request waits ten minutes.
Approve the consent screen
The screen says which app wants to act for you and asks for four things, once:
| Field | What it means |
|---|---|
| Agent | A name for this connection; it becomes an agent with its own passport and receipts. |
| Allowance | The amount a single payment may reach before a person is asked. The default is ask me every time. |
| Ceiling | The mandate: per-transaction, daily and monthly limits. A sandbox uses Regent’s defaults; a production organization states its own. |
| Scope (optional) | What it may buy: tool names or resource prefixes, one per line. Empty means the limits alone apply. |
You can also say which model runs the agent (optional, declared, not verified) and what the agent is for. In a production organization the terms are signed with your passkey; that signature is what later proves a person agreed to exactly these limits.
Make the first purchase
Back in the app, the agent lists Regent’s tools and can act. With the default allowance, its first payment is escalated: the agent is told a person must approve, you see the request under Approvals in the console, and after you approve (passkey in production) the agent retries the same request and it goes through. Raise the allowance on the approval card or in the console and smaller payments stop asking.
App by app
Claude.ai
Settings → Connectors → Add custom connector. Give it a name, paste the URL, and leave the OAuth client id and secret empty (Claude registers itself). Click Connect, sign in, approve the consent screen. Claude reads the tool list at connect time: if you add a tool to your catalog later, disconnect and connect again so Claude sees it.
Claude Code
claude mcp add --transport http regent https://gw.regentprotocol.org/gw/mcpThen run /mcp inside Claude Code and choose Authenticate for regent. The browser opens on
the consent screen; the local callback works without a fixed port. Claude Code identifies itself
with a published client metadata document, which Regent accepts as the client id.
No custom connectors in your app?
An agent that can call HTTP with a stored secret but cannot add an MCP connector uses a key bound to one agent instead — see Without MCP: plain HTTP with a key bound to one agent.
Other apps
Any app whose custom connectors take a remote MCP URL and sign in with OAuth 2.1 follows the same four steps — ChatGPT’s custom connectors and Grok Bot’s custom connectors (paid tiers) have this shape. An app that runs on its own cloud computer cannot reach a connector on your laptop, which is why the URL above is a hosted one. We add an app to the verified list only after running the full loop with it; tell us if you did.
What the app receives
- An access token valid for one hour, bound to this one agent; the app refreshes it without asking you again, and a refreshed token replaces the old one.
- The tools in your organization’s catalog, each in two forms:
<tool>_readfor reads and<tool>for writes, so the app can tell them apart and ask before writing. - A decision on every money call before it reaches the provider: identity, mandate, your policy, behavioral checks. Allowed calls run with a credential kept in Regent’s vault; the app never sees it. Refused calls come back with a code the agent can act on, and escalations say what to do next.
- A signed receipt for every allowed payment, in your audit trail, verifiable offline.
The app itself is not asked to sign requests: agents that arrive through a connector hold no key
of their own, and their receipts say so (key_custody). Agents you run yourself can sign with
their own keys — see SDK & Integration.
Sandbox and production
A self-serve signup starts in a sandbox: Regent’s own test rail (Stripe test mode), a hard
ceiling on amounts, real decisions and real receipts labelled environment: sandbox in every
token. Nothing in a sandbox is evidence of a production payment, and the label travels with the
receipt so nobody can present it as one. Going live needs identity verification and a passkey;
the connection, the agent and its history carry over.
What this does not do
- It does not govern the app’s own wallet. An assistant that pays through its vendor’s wallet keeps that vendor’s approval flow; Regent governs the purchases the agent makes through Regent’s tools and rails.
- It does not read the app’s conversation. Regent sees the tool calls, their amounts and the intent the agent states — that is what the decision and the receipt are made of.
- It does not make a consumer agent an enterprise one. The mandate, the approvals and the receipts are built for an organization with a named accountable owner.
For implementers
The connector is a standard OAuth 2.1 protected resource; any MCP client that implements the discovery below can connect without a Regent-specific integration.
| Document | URL |
|---|---|
| Protected resource metadata (RFC 9728) | https://gw.regentprotocol.org/.well-known/oauth-protected-resource |
| Authorization server metadata | https://api.regentprotocol.org/.well-known/oauth-authorization-server |
| Authorization / token / registration | /oauth/authorize, /oauth/token, /oauth/register on api.regentprotocol.org |
Supported: PKCE S256 only; dynamic client registration (RFC 7591) and client id metadata
documents (a public https URL as the client id); none, client_secret_post and
client_secret_basic at the token endpoint; scope tools; the iss parameter in authorization
responses; loopback redirect URIs matched without the port for command-line clients. A client
metadata document is fetched over public https only, without redirects, and is refused if it
does not name itself.
Verified on production: 2026-10-12 (Claude.ai, Claude Code).