Privacy policy

Agent402 has no accounts. Pages run a first-party page counter (PostHog, served from our own domain). It records page views, page leaves (time on the page and how far you scrolled) and page load timings (web vitals), with your browser, user agent string, operating system, device type, screen and window size, browser language and time zone, the page address with any query string cut to its utm_* campaign parameters, and the address of the page that linked you here, cut the same way. It keeps a random per-visit id in session storage, never a cookie; our server relays the events and forwards only their body and content type, so your IP address is not passed on to the analytics provider. It keeps no session replay: nothing you click, type or see on a page is recorded. Pages also run Google Analytics (advertising features off) to count visits and see how people find the site. It sets a measurement cookie (_ga) and Google receives your IP address and browser details under Google's privacy policy. Advertising features, ad personalization and Google signals are off. If your browser's time zone is in Europe, the cookie is off until you choose "Allow" in the strip at the bottom of the page, and Google only receives cookieless pings before that; your choice is kept in your browser. Wherever you are, you can make or change that choice at any time with "analytics choices" at the foot of the page. If your browser sends the Global Privacy Control signal, the cookie stays off, you are not asked, and the page counter does not load. Pages whose address is itself a private link (a paid report, a receipt, a shared answer, a signed alert or manage link) do not load Google Analytics. Free email alerts are the form that takes an address, and it says so where you enter it; a card purchase gives us the email you enter at checkout. Everything we keep, and for how long, is listed below, including the backups of it. The entire server is open source, so every claim below is verifiable in code.

What we process, and why

• Tool inputs. The data you send to a tool (text to hash, a URL to render, …) is processed in memory to compute the response. It is not stored, except in these cases:
  • the /api/memory tools, whose purpose is storage (see below);
  • some tools that read public data cache their answer for between one minute and one day, keyed by the input that produced it (a domain, an address to geocode, a URL), so a repeat call is faster; identical repeat calls to the AI gateway, identical retries carrying an Idempotency-Key (or the x402 payment-identifier), and the JSON answer of a call paid with a signed EVM x402 payment (keyed by that payment's nonce, so a re-sent copy is answered without a second settlement; not on identity-bound routes such as memory, on routes with a lasting effect, or for streamed calls) are cached for up to 10 minutes;
  • a search on /api/find or the connector's catalog.find that finds no matching tool, and a request sent to /api/wish, is kept as text on our demand board together with a hash of your IP address combined with the day (never the address itself); an entry leaves the board after 30 days without a repeat, and each request's text and hash are deleted 180 days after it was sent, leaving only its counts, kept under a keyed hash of the text (never the text);
  • for a decision bought on /api/decide, we keep the task you describe, the plan we returned, the paying wallet and any feedback you report on its steps, for 30 days;
  • for a paid call, the sales ledger keeps the tool's name and a SHA-256 hash of the response we served, so a receipt can prove what was delivered; the response itself is not kept. It also keeps how the call arrived: through our hosted MCP connector, from one of our client packages (its name and version, the first word of the User-Agent it sends), or as any other HTTP request;
  • a verdict you leave on a paid call through /api/feedback, including the reason you write, is kept with that call's transaction id and is never published;
  • the first-call allowance (a wallet's first paid call on an eligible tool served without charge, so each wallet gets one free first call) keeps the address of each wallet granted one, without expiry, so the same wallet is never granted twice, and a daily count of grants per client address, kept under a keyed hash of the address (never the address itself) and deleted after two days;
• IP addresses. Used for rate limiting and in standard operational logs (request path, status code) for abuse prevention and debugging. When the onchain data service cannot answer an onchain-sql query, the text of that query is written to the same operational log so the failure can be reproduced; it is kept with the log and not used for anything else. Most rate-limit counters are kept in process memory for up to one hour. The free trial's counters (the ?trial=1 allowance on the pure-CPU tools, see the terms) are kept in our Redis store, with the address (for IPv6, its /64 prefix) in the counter's key, for one hour, or 24 hours for the per-client daily allowance. We also keep keyed hashes of addresses, never the addresses themselves: in daily traffic statistics (request classes, paths and User-Agent product names; each day is deleted after 90 days), in the record that limits how often a dropped connection is excused from payment (24 hours), and on the demand board (combined with the day). The tollbooth waitlist form is closed, and every record it collected has been deleted from our database; those records were never part of our offsite backups.
• AI gateway inputs. Prompts and inputs sent to the /v1 endpoints (chat in the OpenAI, Anthropic and Gemini wire formats, embeddings, images, speech and transcription, including the audio you upload) and other AI-proxy tools are forwarded to the upstream model provider (OpenAI, or the model operator serving the request via OpenRouter) to generate the response, subject to that provider's own privacy terms. We don't store gateway inputs or outputs beyond short-lived caches (minutes) that make repeated identical calls cheaper. For requests served via OpenRouter, our account keeps its optional prompt and completion logging off, routes only to endpoints that do not train on or publish request data, and does not let OpenRouter use inputs or outputs to improve its product. Request metadata such as the model, token counts and cost is still recorded for billing and monitoring, without the prompt or completion text.
• On-chain payments. For x402 and MPP payments there are no card numbers, names, or emails. Payments settle in USDC on the public Base blockchain (or the other chains listed at /pricing, USDG on Robinhood Chain, or MPP on Base, Celo or Tempo) via the x402 or MPP protocol; for a payment settled on chain, wallet addresses, amounts, and timestamps are public on-chain by the protocol's design, not collected by us. Circle Gateway batched payments are verified and settled by Circle Gateway off chain; the sales ledger keeps Gateway's transfer id for them. Payment verification for every other payment is performed by the payment facilitators (Coinbase CDP and per-chain facilitators, or Tempo's relay) and we keep a sales ledger of settled payments (wallet address, amount, chain, transaction id) for accounting and for refunding a call that was charged but failed.
• Card purchases (reports, monitors and prepaid credits). Card details are entered on Stripe's hosted checkout and processed by Stripe; we never see card numbers. Stripe gives us the email address you entered, a customer and session id, and the payment status. A delivered report is private to its link unless you choose "Make public" on it, which gives it a second, unguessable address that anyone can read and search engines may index (you can make it private again any time, and the report never contains your name or email). We use the email to deliver what you bought and, after a one-off report, for at most two follow-up emails about that purchase (the monitor for the same subject two days later, other reports a week later), each carrying a link that stops them; if a report fails we email you about the refund. The report link, monitor reports and alerts are sent through a transactional email provider (ZeptoMail, with Resend as a fallback). Stripe keeps the email address with your payment; the report record on our server holds the session id, your input and the finished report, not the email. The email is kept in the follow-up and monitor records described here, and a failed report is counted against a SHA-256 hash of the address (never the address) for 24 hours so repeated failures for one buyer stop further charges. Prepaid credits are not currently sold; for each key we keep a hash of the key (never the key), its balance and the calls it paid for, and from its purchase the email, the billing country, state and postal code, any business tax ID you enter, your answers to the checkout's business-use and terms questions, and Stripe's fingerprint of the card (a token, never the card number). We use the billing address to apply sales tax, the tax ID to sell to a business in the EU or the UK, and the email and card fingerprint to enforce the daily purchase limit. For a monitor we also keep the subject you asked us to watch (a domain, ticker, fund, token or query), your email and the most recent 12 reports we generated, for the life of the subscription. The input you give a report (a ticker, a domain, a research question) is stored with the paid session so the report can be generated once and served back to you; the finished report is served at an unguessable link and is not published.
• Operational telemetry. The server records service events (tool called, payment settled, errors) with metadata - tool name, HTTP status, price, settlement chain, the paying wallet address (already public on-chain) and, on a settled payment, the first word of the caller's User-Agent - in a server-side analytics tool (PostHog). This is used to run the service: reliability, abuse prevention, and knowing what sells. It does not include tool inputs, prompts, outputs, cookies, or browser fingerprints, with these exceptions: a tool call can carry a keyed hash of one declared input field (for example the ticker), so repeat use is countable without the value; a refused payment carries the resource URL the payment names and a coarse balance bucket for the paying wallet; and an error event carries our error message (at most 200 characters), which can name the input value that was refused.
• Payment metadata. Beyond what the payment protocol needs to verify and settle a payment, our code reads these fields of a payment: the signed payer wallet address (already public on-chain), the scheme and network it settles on, the optional payment-identifier (used as an idempotency key and kept with the cached answer for up to 10 minutes), the payment's nonce and network (as an idempotency key for a re-sent payment, held with the cached answer for up to 10 minutes), a digest of the payment's network, signed payer and nonce as a replay mark (kept about an hour after a settled call; for a grant that was not settled, a forgiven hang-up or a served first-call allowance, whose authorization is still live on chain, until the authorization's own validBefore plus 10 minutes, which can be long when the client signs a long validity window), the signers of a Solana payment (stored only as a keyed hash), the source address of a Tempo credential, the payer the settlement receipt names, and, on a refused payment, the resource URL it names (see telemetry above). The optional description and reason annotation fields are not read, logged or retained. The machine-readable list is in /.well-known/x402 under payment.dataHandling: readsOnly names the fields read, and readsAnnotationFields: false states that the annotations are not.
• Memory tools. Data written via /api/memory is stored on our server keyed to the paying wallet, readable only by that wallet (or wallets it explicitly grants), until the owner deletes it or its TTL expires. A tamper-evident audit log of accesses is kept for the namespace owner: each entry records the paying wallet, the key name and the action, and for counters and compare-and-set the values involved. Each entry is deleted 90 days after it is written. Within 10 minutes of a key or document being deleted or expiring, the entries that name it lose the key name and values (the wallet, action and time stay, so the log still verifies), and a namespace with no keys, documents or grants left loses its whole log.
• Free email alerts. If you enter an email on a free report page to be told when a company, fund, domain or product changes, we store that address, the subject you chose and the dates we checked and emailed, and we send you a confirmation link first: nothing is watched and nothing else is sent until you click it. Alert emails go out at most once a day, only when something changed, through the same transactional provider, and every one carries a one-click unsubscribe link that ends the alert and stops all email. We do not use the address for anything else and do not share it.

Third parties

• Tools that fetch external URLs (extract, render, screenshot, …) contact those sites from our server with the URL you provided. Tools that read a third-party data source send it what the lookup needs (a ticker, a token or wallet address, a domain, a query).
• /api/search and the other web search tools forward the query to the Brave Search API to produce results. /api/exa-search, /api/exa-answer and /api/exa-contents send it to Exa, whose model writes the /api/exa-answer response. The /api/x-* tools send the handle, post id or query to the X API.
• The /api/code-run tools run the code you send in a sandbox operated by E2B.
• /api/route, /api/route/execute and /api/decide may send the task text you give them to a judgment model operated by TypeSafe to choose among candidate tools; /api/decide also sends it to AI models via OpenRouter and to an OpenAI embedding model to build the plan. When route-and-execute or a decision's execution buys from an outside seller to resell the result to you, that seller receives the request it needs to answer, sent and paid for by us.
• Card payments and subscriptions are processed by Stripe; transactional email (report links, monitor and free alerts) is sent through ZeptoMail, with Resend as a fallback. Report products read public sources named in each report (for example SEC EDGAR, openFDA, DNS and certificate-transparency logs, public blockchain explorers, and web search) and are synthesized by third-party AI models via OpenRouter, which receive the report's inputs and source material, not your email. When the optional Stripe ledger mirror is on, settled on-chain payments (wallet address, transaction id, amount) are recorded in Stripe for bookkeeping; no email or card data is involved in that mirror.
• Hosting is on Railway, and the nightly backups described below are stored in object storage there. On-chain settlement is on Base (Coinbase CDP facilitator) and the other per-chain facilitators; Circle Gateway batched payments settle off chain at Circle Gateway.
• On Robinhood Chain, the facilitator that settles the payment (Roundhouse AI Ltd., x402.roundhouseai.io, its privacy policy) publishes each settlement it relays on its public index: payer and payee wallets, amount, time, transaction hash, the service name, and the endpoint host and price paid. It also keeps a page for each seller that lists that seller's frequent payers. Entries on that index are permanent and outside our control, and the data sent to it is processed where that facilitator operates. Pay on another chain to keep a payment off that index.
• We do not sell or share data with anyone for advertising, or for any purpose beyond what this list describes.

The MCP connector (https://agent402.tools/mcp)

The hosted connector is anonymous: requests carry no identity beyond the connecting IP, which is used for rate limiting and the hashed records described above. Tool calls made through it are processed exactly like the HTTP API.

Retention

Operational logs are kept for our hosting platform's default log retention. Rate-limit counters expire with their window (one hour, or 24 hours for the free trial's daily allowance). Memory-tool data persists until deleted by its owner or TTL expiry. Card-purchase records (session id, input, the finished report) are kept while the report link or subscription is live and for accounting afterwards. A prepaid credits key's record (the purchase details listed above and the calls it paid for) is kept for the life of the key and three years after its last use, the period sales tax records must be kept, and is deleted on request after that; within that period a deletion request removes what tax records do not need. Free-alert records keep your email until you unsubscribe, when the address is removed; an unconfirmed signup is deleted after three days. Follow-up email records delete the address as soon as the last follow-up is sent, when you stop them or buy again, or after 5 failed deliveries in a row, and in any case 14 days after the purchase; the rest of the record (the product and the subject you asked about) is deleted 30 days after the purchase. Memory audit-log entries are deleted 90 days after they are written, and demand-board request text 180 days after it was sent. Decisions bought on /api/decide are deleted after 30 days. You can ask us at the address below to delete your email from our alert, follow-up and subscription records; the card processor's copy is deleted through Stripe. The sales ledger keeps wallet addresses and transaction ids, which are already public on-chain (for a Circle Gateway batched payment, it keeps Gateway's transfer id instead). Aggregate, non-personal counters (total calls served per tool) are kept for the public /api/stats page.

Backups. Each night we copy the stored records above (the state database, including the email, memory and ledger records) to separate object storage, and each copy is deleted after 14 days. A deletion you ask for therefore reaches the last backup that still holds the record within 14 days.

Your rights (EU and UK)

If you are in the European Economic Area or the United Kingdom, the controller of the data described on this page is Cardhavok LLC, doing business as Havok Holdings LLC (see /company). Our legal bases are: the contract you enter by paying, for a paid call or a purchase; our legitimate interest in running and protecting the service, for the operational logs, rate limiting and abuse control above; and your consent, for the analytics cookie and for email alerts, which you can withdraw at any time ("analytics choices" at the foot of the page, or the unsubscribe link in every alert). Where your browser reports a European time zone, the cookie waits for your choice; elsewhere it is set until you say no, and the choice is yours to make either way. You have the right to ask for access to your data, to have it corrected or erased, to receive it in a portable form, to object to processing based on our legitimate interest, to withdraw consent, and to complain to your supervisory authority. To exercise a right, email [email protected]; we answer within one month. The service is operated from the United States, and the data described here is processed and stored there.

Children

The service is for people 18 and older (see the terms) and is not directed at children. We do not knowingly collect anything from anyone under 13; if you believe a child has sent us an email address or other information, write to the address below and we will delete it.

Abuse & legal requests

Wallet addresses associated with terms violations may be blocked and retained on a blocklist for as long as needed to enforce the block. We disclose information and preserve records in response to valid legal process, and report content where the law requires it. Requests and abuse reports: [email protected].

Operator & contact

Agent402.Tools is operated by Cardhavok LLC, doing business as Havok Holdings LLC. Contact: [email protected], GitHub issues, or @Agent402Tools on X.