Security Model
The product is context-first by design: it helps agents understand the world before they act, and deliberately avoids every capability that would make it a custodian or an execution risk.
Read-only, no custody, no signing
Section titled “Read-only, no custody, no signing”- Every service endpoint is read-only. Nothing on this API sends transactions, executes swaps, moves funds, or mutates on-chain state.
- No user funds are ever held. Payments settle via the x402 facilitator model: the buyer signs a payment authorization, the facilitator verifies and broadcasts it, and the server just receives settlement confirmation. The server never custodies buyer funds or keys.
- No transaction signing on behalf of users. Buyer-side signing happens in the client, an agent wallet, or a dedicated wallet flow — never on this server. Do not send private keys to any endpoint.
No accounts, no consumer keys
Section titled “No accounts, no consumer keys”Consumers authenticate with money, not identity: there is no signup, no session, no consumer API key to leak or rotate. The only per-request credentials are the x402 payment headers.
Upstream credentials never touch you
Section titled “Upstream credentials never touch you”The credentials used to reach upstream data sources are held strictly server-side. They are never returned in responses, never required from callers, and never logged in plaintext. You pay a cent; credential management is our problem, not yours.
Your inputs are not stored readable
Section titled “Your inputs are not stored readable”Request logging never persists caller inputs in plaintext. Each request is recorded with its input only as a SHA-256 hash — no addresses, URLs, or queries are stored readable. The hash permits duplicate and abuse analysis without retaining what was asked. Per-source call latency and payment lifecycle events are retained for observability, keyed by requestId.
Fail-closed payment boundary
Section titled “Fail-closed payment boundary”If a deployment cannot accept payment, paid routes return 402 payment_not_configured instead of serving paid content for free. There is no “payments disabled” mode, in either direction: you are never charged without terms you signed, and content is never given away in a way that would make the paid path suspect.
Transport and headers
Section titled “Transport and headers”The server sets standard security headers on all responses, restricts cross-origin access to an allow-list with only GET/POST/OPTIONS, and exposes only the payment-flow headers (Payment-Required, Payment-Response, X-Request-Id) to browsers.
Bounded work
Section titled “Bounded work”Cost guardrails double as abuse guardrails: strict input schemas (unknown keys rejected on web-context routes), hard caps on results/URLs/tokens/content size, bounded block ranges for log analysis, and TTL caching of public data. No endpoint can be steered into open-ended crawling, deep research, or unbounded upstream spend — see Pricing & Guardrails.