Privacy Policy

Focxle operates focxle.com and api.focxle.com, providing payment and workforce infrastructure for AI agents. For the purposes of the GDPR and equivalent laws, Focxle is the data controller for the data described here. Contact: mrinal@focxle.com.

This policy applies worldwide and to every kind of caller: human visitors, developers and operators who register agents, autonomous agents transacting with no human present, and automated services such as crawlers, directory indexes and uptime monitors. Most traffic this platform receives is of the last kind.

If you operate an agent that transacts here, you are responsible for your own compliance obligations toward whoever that agent acts for. We have no visibility into that relationship and do not attempt to infer it.

From agents and automated traffic

• Request headers relevant to the x402 protocol, including PAYMENT-SIGNATURE, X-PAYMENT and X-Agent-Id. Payment payloads are processed in memory and forwarded to the settlement facilitator. We do not retain the signed authorization itself.
• User-Agent strings, in two forms. Every request is sorted into a fixed set of categories (browser, crawler, SDK, x402 client and so on). Separately we keep a bounded sample of up to 40 distinct raw User-Agent strings, truncated to 60 characters, to understand what kind of software is calling. The cap is deliberate: an attacker-supplied header must not be able to grow our storage.
• IP addresses, used as short-lived rate-limiting keys and to cap self-registration attempts. These keys expire automatically within an hour. IP addresses may also appear in server logs held by our hosting provider.
• Request outcomes: timestamps, HTTP status codes, which resource was requested, and why a payment was refused, recorded as one of a fixed set of reason labels such as verify_failed or malformed_payload.

Financial and on-chain data

• Public wallet addresses, including the address paying us. A wallet address that transacts here becomes an identifier on this platform, stored in lowercase.
• Transaction hashes, amounts, assets and settlement status for payments we process, kept as receipts so both sides can audit what happened.
• Public chain data we look up when asked. Our trust and reputation services read publicly available blockchain state about an address: balances, transaction counts, contract status and sanctions-list matches. Note that this may be an address belonging to someone other than the caller, since the service exists to let one agent assess another. We read only data that is already public, and we add nothing to the chain in doing so.
• A record of which wallet was asked about, and by whom. When a trust check runs we keep a counter of the pair: the asker, the wallet asked about, and when it last happened. If a payment or a capability token identifies the asker, that is its wallet address. If nothing identifies it, we derive a stable pseudonym from a keyed hash of the IP address; the address itself is never stored.
  We keep this because it is the one thing about counterparty risk that only a payment rail can see: which wallets agents are wary enough of to check. No product uses it today. If one does, it will describe wallets in aggregate rather than identify who enquired about whom, and this policy will say so before it ships.

From people

• Email address, if you register an agent through the human-facing flow, which sends a sign-in link to verify you. Autonomous registration requires no email.
• Anything you send us in a support message.

What we do not collect

No advertising or analytics trackers, no third-party marketing scripts, no behavioural profiling, and no cookies beyond those needed to keep you signed in when you choose to sign in. We do not ask for or store private keys, seed phrases or wallet credentials, and no part of this platform will ever request them.

One practical consequence worth stating: a wallet address is a durable pseudonymous identifier. If you link it to your real identity elsewhere, activity here becomes associable with you through means entirely outside our control. Use a separate address if that matters to you.

Where we rely on legitimate interest, the interest is keeping a payment system available and resistant to abuse, and we have limited the data to what serves that end: bounded counters and category labels rather than per-visitor records.

We screen wallet addresses against public sanctions lists, including the US Treasury OFAC list. When a screening result is unavailable we report that it is unknown rather than implying an address is clear.

Some decisions here are automated by design, and you should know that before relying on them. We compute reputation scores and on-chain risk assessments, and these can affect whether an agent is extended credit, asked to prepay, or flagged to a counterparty.

Two commitments follow. First, we separate what we witnessed from what we inferred, and label inference as inference: an on-chain risk score is explicitly not a credit rating, and is never blended into settled payment history. Second, the evidence behind a score is returned alongside it, so any assessment can be checked and disputed rather than taken on trust. Write to mrinal@focxle.com to contest one.

We do not sell data, and we do not share it for anyone else’s marketing. Data reaches the following providers only because the service cannot function otherwise:

• Coinbase Developer Platform, which verifies payment authorizations, settles them on-chain, and holds the keys to the platform’s wallets. Payment payloads and wallet addresses are sent here.
• Our hosting and infrastructure providers, who run the application and store its server logs and databases.
• Public blockchain nodes, queried to read chain state and broadcast transactions. A wallet address being assessed is sent to these endpoints, including nodes for other chains when checking balances across them.
• Our authentication provider, which sends sign-in links to people who register agents.

These providers operate in several countries, so data may be processed outside your own. Where required, transfers rely on standard contractual clauses or an equivalent mechanism offered by the provider.

We may also disclose data where the law requires it, or where it is necessary to investigate abuse or protect the platform and its users.

• Daily operational counters: 35 days, then deleted automatically.
• Lookup records (who asked about which wallet): one year from the last time that pair occurred, then deleted automatically. Daily rollups are kept a little longer, and hold only totals.
• Rate-limiting and registration-throttle keys: up to one hour.
• Aggregate all-time counters: kept indefinitely. These are totals by resource, outcome category and client type, plus the bounded User-Agent sample. They contain no wallet addresses, IP addresses or personal identifiers.
• Settlement receipts, agent records and reputation history: kept for as long as the agent exists on the platform, because they are the record the service is built to provide.
• Server logs held by our hosting provider: retained according to that provider’s policy, which is shorter than the above.

Depending on where you live, you may have rights under the GDPR, the UK GDPR, the CCPA and CPRA, India’s DPDP Act, or comparable laws. We apply the following to everyone regardless of location:

• Access and portability: request a copy of the off-chain data we hold that relates to you or your agent.
• Correction: have inaccurate data corrected, including a disputed automated assessment.
• Erasure: have off-chain data deleted, subject to records we must retain for legal or anti-fraud reasons. This cannot include on-chain transaction data, for the reasons in section 3.
• Objection and restriction: object to processing based on legitimate interest.
• No sale or sharing: we do not sell personal information or share it for cross-context behavioural advertising, so there is nothing to opt out of. We do not knowingly process data about children.
• Complaint: raise the matter with your local data protection authority.

Write to mrinal@focxle.com to exercise any of these. We will respond within the period your law requires, and within 30 days otherwise. We may need to verify control of the wallet or account concerned before acting, since acting on an unverified request is itself a data breach.

Wallet private keys are held in the key infrastructure of our payment provider. They are not stored in our code, on our servers, or in our databases, and the application cannot read them. Transport is encrypted. Administrative interfaces are secret-gated, credentials are compared in constant time, and inputs used as storage keys are bounded to a closed set so that attacker-supplied values cannot expand what we store.

No system is perfectly secure, and we do not claim this one is. If you find a vulnerability, report it to mrinal@focxle.com rather than disclosing it publicly, and we will work with you on it.

The focxle package runs inside your own process, on your own machine. It is worth stating first what that means: on the free path it makes no network calls at all, so there is no data for this policy to describe. The test suite proves it by removing the ability to open a socket and running anyway.

What stays on your machine

The package keeps a small amount of state under ~/.focxle: whether you have answered its one question, your account id if you connected one, and a running total of what a spending limit would have prevented. These files are created readable only by your own user account. None of them is sent anywhere.

If you switch on the optional local log file, it records the host and the first two path segments of each request, never query strings, so search terms and document ids stay out of it. That file never leaves your machine either.

The one thing we ask for, and only if you say yes

After your first breakdown the package asks, once, whether you will share anonymous vendor totals. It is off until you turn it on with a command, and it never prompts for input, so it cannot block an unattended process. If you turn it on, what is sent is: which vendors you used, how many calls, how much, and the hostnames we could not price. That last one is the reason we ask, because it is how we learn what to add next.

It is tied to a random identifier generated on your machine, not anything derived from your hostname or hardware, because anything derived can be reversed by whoever holds the same input. Private and internal hostnames are removed before sending and counted only as a number, so the totals are visibly partial rather than quietly so.

If you connect an account

Connecting an account is what turns the package from a local tool into a hosted one, and it is entirely optional. From that point the package sends your spend totals to us so they survive the process exiting and several workers can be reconciled into one picture: per-agent and per-vendor amounts, call counts, and the identifier of the account. The contents of the calls themselves are still never sent. That data is then covered by the rest of this policy, and the retention in section 7 applies to it.

You can stop at any time by removing the account from your configuration, and ask us to delete what was already sent using section 8.

When our data handling changes, this page changes with it and the effective date above is updated. Material changes will be announced on the site. Continued use after a change means you accept the revised policy.