Interactive Demo — Simulated, No Signup

See LumoAuth's agent-identity stack in four steps before creating an account: app.lumoauth.dev/demo/agents.

The page walks through a scripted scenario for Northwind Labs, a fictional organization. Its agent, Invoice Copilot, gets a cryptographic identity, hits an MCP server's authorization wall, passes one fine-grained authorization check and fails another, then asks a human for permission to execute a payment. You play the approver.

Every response on the page has the same shape as the real API's — the same claims, the same RFC 9728 metadata document, the same 401 challenge header, the same decision object, the same JIT request and token fields — so what you read there is what your own integration will see.

What is and isn't real

On the page	Real?
Endpoint paths and request bodies	Yes — they are the product's routes and payloads
Token header and claims	Yes — the exact fields the product issues (typ: agent+jwt, cnf.jwk, jit_request_id, …)
Token signatures	No — deterministic filler of the right length. Nothing on the page verifies
The Ed25519 public key	A published test vector (RFC 8037 Appendix A), not a key anyone holds
Organization, people, agent, invoices	Fictional
Audit trail	Illustrative — the event names match what the real pipeline writes

Nothing is provisioned, signed, stored or sent when you use the page. It is static content plus browser-side scripting.

Why the demo is simulated

An earlier version of this page provisioned a throwaway sandbox organization per visitor and ran the steps against the live server. That meant anonymous traffic could reach platform-shared resources — the outbound mailer, the security-alert channels, the audit log and the sandbox cleanup job — and a motivated visitor could degrade them for every customer. The simulation shows the same contract with none of that surface, so it was replaced.

To run the flow for real, create an organization (about a minute) and follow the AAuth Quick Start or the in-dashboard AI Agent + MCP tour. Ephemeral sandbox organizations for your own development stay available through lumo dev on plans with the Developer sandboxes add-on.

The four steps

1. Agent identity. Invoice Copilot has an Ed25519 keypair. Northwind Labs mints an AAuth agent token (AAuth is the agent identity protocol: the agent proves who it is with its own key instead of a shared secret) whose cnf.jwk claim binds it to that key. The page splits the token into header, payload and signature and decodes the first two.
2. MCP authorization. The organization's MCP server (a tool server agents call over the Model Context Protocol) is an OAuth protected resource. You see its protected resource metadata (the public document that says which authorization server guards it) and the spec-mandated 401 + WWW-Authenticate challenge an unauthenticated call receives.
3. Fine-grained authorization. Two Policy Decision Point evaluations for the agent — documents.read allowed through a Zanzibar-style relation tuple, payments.export denied by default — with the deciding engine and reason, as /api/v1/authz/check returns them.
4. Human-in-the-loop. The agent requests payment.execute. The JIT (just-in-time permission) engine scores it high risk, refuses to auto-approve and routes it to the approval inbox. You approve or deny as the finance lead; approving issues a JIT token scoped to exactly that request, valid for ten minutes.

Standards used on this page

Plain name	Standard
Protected resource metadata	RFC 9728
Model Context Protocol (MCP) authorization	MCP Authorization specification
JWK thumbprint	RFC 7638
Ed25519 in JOSE	RFC 8037

See the standards reference for what each one covers and how LumoAuth uses it.