Security model: what PayCheck does and doesn't do
Lumière PayCheck decides whether an agent's payment should happen. It never touches the money.
What PayCheck does not do
- Hold funds. We never custody, route, or escrow USDC or any other asset.
- Control your wallet. We never see or hold your wallet keys.
- Make payments. Your agent pays the seller directly with x402. We don't sign, send, or settle anything.
- Act as a payment processor or facilitator. Settlement happens between your wallet, the seller, and their facilitator.
What PayCheck does
- Inspects the proposed payment: the endpoint, amount, payout wallet, and network from the seller's 402 quote.
- Evaluates the endpoint: its trust grade from 30-minute monitoring, real test payments, and payout-wallet history.
- Enforces your policy (paid plans): per-agent caps, daily and monthly limits (with time-limited increases), allowed sellers, company blocklists and caps, policy templates, risk rules, and human review for unusual payments.
- Watches what agents actually pay from wallets you register, and flags payments that didn't go through PayCheck.
- Signs its decision: an
allowcomes with an Ed25519 receipt bound to that exact URL, amount, and payout wallet, valid for 5 minutes. - Records every decision with its inputs in a tamper-evident audit trail you can replay and verify.
Where PayCheck sits
| Part | Role |
|---|---|
| x402 | The payment protocol: a seller answers with 402 and a price |
| Your agent and wallet | Decide to pay, sign, and send the payment |
| Facilitator | Settles the payment on-chain |
| Seller | Delivers the API response |
| Lumière PayCheck | Trust, authorization, and audit before the payment |
Advice vs. enforcement
The free check (check_payment over MCP, or POST /v1/check-payment) is advice. It tells your agent whether a payment looks safe, but nothing stops an agent from paying anyway.
Paid authorization (POST /v1/authorize) becomes enforcement when your wallet code requires a valid receipt before it signs. Because each receipt is signed by us and bound to one exact payment, an agent can't reuse it for a different amount or wallet, and a payment PayCheck denied never gets one. Receipts are single-use: checking one with consume: true marks it used, and our payment matching counts one approval for one payment.
Our npm package does this for you: withPayCheck(client, { key }) wraps an x402 client so every payment asks PayCheck first and only approved payments are signed. If PayCheck can't be reached, it doesn't pay (fail closed). Your workspace can allow payments under a small amount you choose (up to $10) to go ahead without a check; that's the only exception, and it's off by default. Agents running the SDK are marked Enforced by SDK.
Detection covers what enforcement can't: when you register an agent's wallet, every x402 payment it makes is matched against PayCheck's decisions, and payments made without asking, after a deny, or for more than approved alert you. Together: the SDK keeps honest agents inside the rules, and detection tells you when anything slips past it. We still never hold or move funds, and we don't co-sign payments.
Agent credentials (opt-in)
When the Owner turns them on, agents can get a 15-minute credential that tells one seller the agent belongs to a verified PayCheck workspace (and, if you choose "named" and have verified a domain, your company name). Each seller sees a different agent ID, so sellers can't track an agent across sites. A credential only works with the agent's registered wallet. Limits, people, other agents and payment history are never included. Turning credentials off, or freezing or revoking the agent, fails every outstanding credential immediately. Credentials are signed with Ed25519; the public keys are at /.well-known/jwks.json.
Sign-in for people
People sign in with their own key, or with your company's identity provider (OpenID Connect with PKCE) on Enterprise. Sign-in domains must be verified by DNS first, only emails your identity provider has verified are accepted, and a sign-in only finishes in the browser that started it. SSO sessions last 12 hours and end immediately when SCIM deactivates the person. The OIDC client secret is encrypted at rest (AES-256-GCM); SCIM tokens and sessions are stored only as hashes. SSO can never grant the owner role, and the owner key remains a break-glass login.
Keys and data
Owner, admin, agent, SCIM and session keys are stored only as hashes. Agents can also sign in with their cloud workload identity instead of a stored key. For agent inventory and risk we record which network range a request came from only as a keyed hash of the range (a /24 or /48), never the IP address. Full details, including current limitations: Security. What we collect and keep: Privacy policy.