There is no account to breach.
Most of what a security review looks for — the credential store, the session database, the customer balance ledger — does not exist here. Not as a hardening measure, but because paying per request with a signature made the whole category unnecessary.
This page covers how BlockRun handles funds, credentials and infrastructure. How data is handled is governed by the Privacy Policy. BlockRun holds no third-party security certification, and this page is not an attestation — it is a description of the system, with the parts we cannot claim listed at the bottom.
The attack surface that isn't there
No API key, password or session
There is nothing to issue, rotate, or leak. A request authenticates itself with a signature made on your machine, for that request.
No identity record
No signup, no email, no phone number, no government ID. A wallet address is the only thing that identifies a caller, and you bring your own.
No stored balance
You do not pre-load credit with us. There is no float to drain — the addresses that receive settlement can receive, and nothing else.
No key custody
Your private key never reaches our servers. x402 sends a signature, not a key, and verification is signature recovery.
Payment is the credential — and it expires
A paid request starts with a 402 quoting a price. Your client signs an authorization for that amount — an EIP-3009 transfer authorization, signed under EIP-712, on your machine. We verify it by recovering the signer, check that it falls inside the validity window you signed, and settle it through the Coinbase facilitator to an address that only receives.
The authorization is single-use, so a spent one cannot be replayed. Which makes the interesting question a narrow one: what does a stolen payment header actually buy? One request, for that amount, inside that window. It is not a credential and it does not become one.
If BlockRun were fully compromised
The useful way to read a security page is to assume the company loses. Here is where that stops.
- Move funds from your wallet
- Claim more than the amount you signed for
- Claim outside the validity window you signed
- Replay an authorization you already spent
- Steal a reusable credential — there isn't one
- Recover an identity we never collected
- Serve responses for requests we are processing
- Claim the payment authorizations presented to us
What we decline to list
Plenty of upstream providers offer a free tier whose terms permit training on the prompts sent to it. Those models are cheap to list and they make a catalog look bigger. We keep those out of the published catalog, and publish the 7 free models whose terms we are willing to stand behind.
To be exact, because the distinction matters: withheld means omitted from the published model list, not that the id stops resolving. What we decline to do is put a model in front of someone who did not choose it. Separately, ids we have retired for upstream reasons are redirected to an equivalent, so a caller who addresses one deliberately is answered by a different model — the response says which.
This is a procurement posture — a statement about what we route to, not a guarantee about data handling.
Platform and supply chain
- The application container runs as a non-root user, on a multi-stage, minimal base image.
- HSTS is set on page routes.
- The framework identification header is removed from responses.
- The image optimizer is restricted to an explicit allowlist, narrowed from an open proxy.
- No secrets live in the repository; local environment files are excluded from git, from the Docker context, and from build uploads.
- Telephony, sandbox and shared-pool credentials are held in Google Secret Manager and injected at runtime.
- Every change runs lint, type checking, a production build and the full test suite in CI. Dependency updates are automated.
- Deploys are blue/green behind a health gate with automatic rollback, and refuse to ship uncommitted source.
Abuse controls
Payment authorizations use single-use nonces, and settlement is claimed once so a request cannot be charged twice. Payers found abusing the gateway can be denied at the edge of the payment path. Internal service endpoints are gated behind a shared secret and are not reachable from the public API surface.
Reporting a vulnerability
Mail hello@blockrun.ai. We aim to acknowledge within two business days.
If you are acting in good faith — you stay within your own wallet and your own requests, you do not degrade the service for anyone else, and you give us a reasonable window before publishing — we will not pursue you for the research.
Machine-readable contact: /.well-known/security.txt
What we don't claim
Security pages tend to be read for what they assert. This is the part worth reading for what it doesn't.
- No SOC 2, no ISO 27001, no third-party penetration test or audit of BlockRun. Where our documentation references an audit, it belongs to someone else: Trail of Bits audited USDC's transfer-authorization standard, and the SOC 2 in that section is Coinbase's, for the settlement facilitator. Neither is ours.
- No uptime commitment, no SLA and no status page. Our Terms say so directly, and this page is not going to say otherwise.
- No per-tenant isolation and no dedicated instances on the standard service.