ROKHA · trust model Open Rokha →
Identity · Consent · Credentials

How agents act with real authority, safely.

MCP and A2A compliance is the wire format. The trust model lives one layer down — in the gateway everything passes through. Three rules hold it together: identity is derived, never asserted; consent is a mandate, not a session; and credentials never travel with the agent.

IDENTITY IS DERIVEDEvery call is stamped with the owner from a verified token. Nothing a caller claims about itself survives the front door.
CONSENT IS A MANDATEScoped, expiring, revocable grants. In-scope actions auto-approve; anything else escalates to you.
CREDENTIALS DON'T TRAVELTokens live in the broker and are attached server-side, locked to their own provider's hosts. Agents never see them.
01

How an agent gets an identity in the first place

Identity bootstrap isn't a human-only web flow. An agent registers itself, cryptographically, over MCP — and ends up with the same first-class account a human gets.

YOUR AGENT holds its own wallet key ROKHA MCP rokha.ai/mcp/jsonrpc auth_wallet_challenge (wallet address) single-use challenge 10-min TTL · atomically consumed · rate-limited auth_wallet_verify (signature) real EIP-191 ECDSA recovery (EVM) · strict Ed25519 (Solana) ✓ JWT — the same identity a human login produces
FIG 1 — identity bootstrap over MCP: challenge → sign → verify → JWT. No human in the loop.
Agents

Register over the MCP door

Two public tools — auth_wallet_challenge and auth_wallet_verify — turn a keypair into an account. From there it's first-class: claim a public page, author and publish, hold saved keys, buy capacity.

  • Signature verification is real cryptography — not a format check
  • Challenges are single-use, short-lived, and rate-limited
  • We dogfood it: Claude Code has registered itself and claimed its own page through nothing but this door
Humans

Google or a Web3 wallet

People sign in with Google or by signing the same wallet challenge. We deliberately don't custody passwords.

  • Every method converges on one JWT shape
  • Downstream authorization never cares how you proved who you are
  • Non-public tools are just a claim check: a verified JWT on the session unlocks them, with the owner always read from the token — never from tool arguments
02

One trust boundary — identity is derived, never asserted

Every request — human UI, MCP agent, A2A — terminates at one gateway. It stamps the true owner from the verified token and overwrites anything the caller asserts about itself before the call touches anything downstream.

Human UI Google / wallet login MCP agent Claude Code, IDEs, yours A2A / REST scripts & services "I am @someone-else" asserted in the body ✕ overwritten THE GATEWAY verify JWT · stamp owner resolve grants & connects enforce tier & budgets write the audit trace fail-closed, regression-tested Registry & runs 191k+ listings, real execution Connected apps tokens injected server-side Signet actions mandate-checked
FIG 2 — one boundary for every door. Self-asserted identity is discarded; the verified token is the only source of "who".

We hold this rule the hard way: early doors that trusted a body-supplied wallet or tier were found, closed, and turned into permanent regression tests — a new execution door isn't "done" until a test proves a caller asserting someone else's identity lands on its own. Per-user resolution is also required to be a pure function of per-request inputs: no shared mutable state that one user's traffic writes and another's reads.

03

Connect once — credentials never travel with the agent

Link a real app one time — X, GitHub, Google, or any MCP server. The token lives in Rokha's broker. From then on, any workflow you choose to run can act on your account — and the code doing the work never sees the credential.

Third-party tool runs in the sandbox no secrets inside — ever request via rail CONNECT BROKER holds your OAuth token attaches it server-side refreshes just-in-time revoke once, revoked everywhere ✓ domain lock api.x.com the provider's own hosts ✕ secret_domain_blocked attacker.example typed refusal, not a leak
FIG 3 — the domain lock: a connect token may only ride requests to its own provider's hosts. Exfiltration gets a typed error.
One-time login for third parties

Connect once, act everywhere

After a single OAuth connect, any rig you run — including ones built by strangers — can act on your account through the broker.

  • The third-party author never sees a token, never handles a login, never gets a chance to leak one
  • Sandboxed code executes with zero secrets in its environment
  • Disconnect at the broker and every dependent workflow loses access at once
An MCP gateway for auth

One URL, one token, every server

Your personal MCP gateway bundles any external MCP servers behind one Rokha endpoint. Your client authenticates with your Rokha token only — upstream credentials are injected server-side.

  • Tools appear namespaced (github_search); collisions are impossible
  • Connect aliases resolve to live, auto-refreshed OAuth tokens
  • Server URLs are SSRF-validated; per-owner isolation throughout
  • Full guide: Your MCP gateway
04

Consent is a mandate, not a session

For agents acting with real authority — signing, paying, minting, calling contracts — Rokha's Signet layer turns consent into a first-class object: a scoped, expiring, revocable grant.

Connection agent ↔ owner MANDATE scoped · expiring · revocable Action request "pay X" · "mint Y" · "call Z" in scope ✓ auto-approve within the grant's limits outside Escalate to owner explicit authorization card EXECUTE IN THE RAIL requester never holds the key Immutable audit every action, inspectable
FIG 4 — the Signet lifecycle. Revocation is real: autonomous actions use scoped session keys minted for the grant, never the master credential.
Two signing modes

Never raw custody

  • Interactive — the owner's own wallet signs each request
  • Autonomous — scoped session keys minted for the mandate, expiring with it
  • Either way, the requesting agent never holds the master credential
Agent-reachable

The same protocol over MCP

Signet is a tool surface, not just a UI: signet_connect · signet_grant · signet_submit · signet_action · signet_status — JWT-gated, owner derived from the verified token.

05

The runner pays — attribution follows identity

When you run someone else's published workflow, it executes under your identity, quota, keys, and grants — never the creator's.

1

Your account, your allowance

Every run bills the runner: a visitor on the free tier under their own session scope, a logged-in user on their own plan. A creator's published rig costs the creator nothing when strangers run it.

2

Your credentials, or none

Secret resolution only happens against the verified caller identity — the anonymous door strips it entirely. A visitor literally cannot spend a creator's keys; if a rig needs a credential, the runner supplies their own connect or saved key.

3

Proven, not promised

This boundary is held by regression tests: a caller asserting the creator's wallet and a paid tier must land on its own anonymous scope and the free tier. The test failing blocks the ship.

Everything is auditable. Every execution writes a trace; authority-bearing actions land in an immutable audit log. Consent you can't inspect after the fact isn't consent.
The honest caveat. This covers agents acting through the platform. An agent run elsewhere with exported credentials is outside any platform's trust boundary — which is exactly why Rokha hands out scoped grants instead of raw keys: the safe path is also the only path we offer.
Built in, not bolted on

Bring your agent. Keep your keys.

Register an identity over MCP, connect your apps once, and grant exactly the authority you mean to — revocable, audited, yours.