Privacy policy

This policy explains how Verdifax handles personal data: what we collect, who receives it, how long we keep it, and what you can ask us to do. It applies to the Verdifax website (verdifax.com), the dashboard, the documentation site (docs.verdifax.com), and the API (api.verdifax.com).

Summary

This policy describes how the system works today, including its current gaps. Our API receives the content you send in readable form. We keep hashes of your payload and of any AI output text, but we store the metadata you include exactly as you send it. Our hosted service sends AI output text to Anthropic for a governance review. Our API and database are hosted in the United States. Nothing is deleted automatically, and some data cannot currently be deleted at all.

Who we are

The Verdifax service is operated by Verdifax, LLC, a Delaware limited liability company ("Verdifax", "we", "us"). You can reach us about privacy at privacy@verdifax.com.

We decide how the personal data in access requests, accounts, logs and website use is handled. For content that our customers send through the API, the customer decides what to send and why. [Pending review by counsel: whether Verdifax acts as a controller or as a processor for personal data contained in customer content sent through the API.]

What we collect

Access requests

The access request form at verdifax.com/request asks for your name, email address, organization, role, use case, and a message. The form has no country field. Our server also gives each request a priority label based on your email address and organization.

The form is processed by a Cloudflare Pages Function. It emails the submission to our access@verdifax.com inbox through Resend, with your email address as the reply-to address, and it sends the submission to our API, which stores it in our database. We use this information to evaluate your request and, if we approve it, to create your API key.

If we approve your request, we email you a one-time link to claim your API key. The link expires after 72 hours. This email is sent through Resend and contains your name, your organization, and the link. It does not contain the key itself.

Accounts and API keys

For each API key we store: a name made from your organization (or from your email address if no organization was given); a SHA-256 hash of the key, never the key itself; when the key was created and last used; how many runs it has made; its tier and expiry date; whether it has been revoked; a Stripe customer id if you pay us through Stripe; and a signing key pair, described under Security below.

API requests and sealed records

When you call the API, our servers receive the payload you send, any AI output text you include in the ai_output_text field, and any metadata you include, all in readable form. Our server reads the payload to process the request, which includes our Malicious Code Defense check: it scans the payload for known code-attack signatures in four categories, prompt injection, dangerous API use, supply-chain attacks and filesystem escape.

We store a SHA-256 hash of the payload, not the payload itself. We store a SHA-256 hash of the AI output text, not the text itself. There is one exception: if the AI governance review returns output that our server cannot parse, the error message we store and log can contain that output.

We store the metadata you include exactly as you send it, as part of the sealed record of the run. This can include actor identifiers (often email addresses), approver names and comments, decision notes, and any raw prompt text, model output, IP address, user agent, affected-entity identifiers or policy text that you choose to include. You decide what goes into these fields, so please leave out personal data that the record does not need.

Each sealed record also contains a hash of the IP address and a hash of the user agent that made the request. From run 245 on, these are keyed hashes (HMAC-SHA256 under a secret that only the Verdifax server holds, written with the prefix hmac-sha256:): nobody without the secret can recover the address from its hash or test a guess against it. The keyed hash is the same every time for a given address and user agent, so anyone holding several records can tell which of them came from the same address and user agent, without learning the address. Verdifax, which holds the secret, could also recover an address by trying every possible one. From run 247 on, the server always computes these two hashes itself and refuses a request that supplies its own; before run 247, a request could supply its own values, which were sealed in place of the server's. Records sealed up to run 244 contain unsalted SHA-256 hashes, from which anyone can recover an IP address by trying every possible address; a sealed record cannot be changed, so those hashes stay as they are. Either kind is pseudonymous personal data, not anonymous data. A sealed record can also contain a country or region that the request itself declares. Verdifax does not observe or check it, so it is the caller's statement, not a measured location; records sealed before run 247 may also carry a country taken from a request header that any caller could set.

The /attestendpoint is turned off on the hosted API and accepts no calls. While it was on, it accepted only keys of Verdifax's own entity (its Mesedi product), and each call stored the submitted digest and the subject reference text the caller chose; those stored calls are kept.

AI governance review (Anthropic)

Our hosted service has the AI governance review turned on. When a request includes AI output text, we send that text, exactly as received, to Anthropic's Claude API for review. If the field is empty, nothing is sent to Anthropic. We keep only the hash of the text and the result of the review.

Anthropic's published Commercial Terms state that Anthropic may not train models on customer content from its services. Anthropic describes how long it keeps API inputs and outputs in its own privacy center, and Anthropic can change that policy. [Pending review by counsel: whether Anthropic's Commercial Terms and data processing addendum govern Verdifax's API account.]

Public demo records

We publish some of Verdifax's own demonstration runs so that anyone can check them without a login. Today, a sealed record can become public only when a Verdifax administrator publishes it with an admin API key, and an admin key can publish only runs that were created with that same admin key. Customer API keys cannot make a record public. Choosing a route identifier (route_id) that begins with buyer-demo- does not make a record public.

Under an earlier rule, any run whose route_id began with buyer-demo- was published automatically at https://api.verdifax.com/runs/{id}/bundle.json, where sequential run ids made them findable by counting. All 44 records published under that rule were withdrawn from public access on October 18, 2026, so that address now serves none. Runs 237 to 240, published later at private links, were withdrawn the same day. Copies downloaded before then may still exist; each contains all of the metadata recorded in its run, and 34 of them include the email address of Verdifax's founder.

Unsalted hashes from five genuine records sealed before run 245 also remain public as test data in the public verdifax-verify repository and its history: runs 208, 235, 237, 238 and 239 (run 239 came from the same address as run 240). Removing them would mean rewriting that repository's published history, which would break the signed provenance of its existing releases, and copies already made elsewhere would remain. The October 2026 hardware evidence record, sealed before run 245, also carries an unsalted hash, but it is the hash of that machine's own loopback address (127.0.0.1) and reveals no network address. On the hosted service the hashed value is the client's IP address alone, taken from the Fly-Client-IP header that Fly.io's proxy sets (the proxy replaces any value a caller sends), with no port, so trying every IPv4 address recovers an unsalted one sealed up to run 244; a request that reaches a server directly, as on the hardware demonstration machine, hashes the address together with its port.

Records published since then are served at https://api.verdifax.com/public/runs/{token}/bundle.json, where the token is 32 hexadecimal characters drawn from a cryptographic random source. These records are not served at the numbered address, so they cannot be found by counting run ids. Anyone who has the link can read the full sealed record, including all of the metadata in it. Public records may still be cached for up to one hour after an administrator unpublishes them.

Operational logs

Our API writes operational logs to Fly.io's logging system. Log lines for runs include the run id, timing, manifest hash, program id, route id and API key id, and for failed runs the error message. Our application does not write IP addresses, email addresses or names to these logs. We have not configured a separate retention period for these logs.

When the API crashes or logs an error, diagnostic data is sent to Sentry, as described on our sub-processor page.

Cookies and browser storage

Verdifax's own code sets no cookies. Cloudflare, which delivers our website, dashboard and documentation, adds two scripts to our pages: Cloudflare Web Analytics, which sends measurements about each page load to Cloudflare, and a Cloudflare bot-detection script, which Cloudflare uses to tell browsers apart from automated traffic. When we checked on October 16, 2026, the bot-detection script's request received a cookie named cf_clearance, set by Cloudflare for the verdifax.com domain with an expiry of one year. Some pages also load Cloudflare's email address obfuscation script. We do not use advertising trackers.

When you sign in to the dashboard, it stores your API key in your browser's local storage (verdifax.api_key), together with a flag that records whether the key has admin access (verdifax.is_admin), and a session flag in session storage (verdifax.session). Any script running on the dashboard pages, including the Cloudflare scripts above, can read local storage. Signing out removes these values. The documentation site stores your language choice in local storage (verdifax.lang).

What we do not ask for

The API has no field for model weights, identity tokens, or your customers' records, and we do not ask for them. The API stores whatever metadata you include, however, so anything you put in a metadata field becomes part of the sealed record.

How we use the data

We use personal data to: evaluate access requests and create and revoke API keys; run the service, including the AI governance review; publish demo records as described above; respond to you; diagnose errors; process payments; protect the service against abuse; and comply with legal obligations. We do not use personal data for advertising or to build profiles. We do not make automated decisions about you that have legal effects. We do not sell personal data. We have not yet set out the lawful basis for each of these uses. [Pending review by counsel: the lawful basis for each use under the GDPR and the UK GDPR.]

Sharing

We share personal data with the service providers listed on our sub-processor page, each for the purpose stated there: Fly.io (hosting), Cloudflare (website delivery, analytics and bot detection), Anthropic (AI governance review), Sentry (error diagnostics), Resend (email, sent through Amazon SES), Google Workspace (our company email), AWS KMS (key management), Stripe (payments), and the public Sigstore Rekor transparency log. Entries in the Rekor log contain only hashes, a signature and Verdifax's public key, and they are public and permanent. We will disclose personal data to public authorities if the law requires us to.

Retention

Verdifax has no automatic deletion or expiry for any stored data. Account records, access requests, sealed records and attestation records are kept indefinitely. The only bulk deletion is a cleanup that an administrator can run by hand, which removes runs that were not anchored in the public Rekor log. Revoking an API key marks it as revoked but does not delete it. Each access request is also emailed through Resend to our Google Workspace mailbox, so copies exist outside our database as well.

Sealed records are designed to be permanent. For runs anchored in the Rekor log, the service has no function that removes or edits the caller-declared metadata in the sealed record, so that metadata cannot currently be removed. Entries in the public Sigstore Rekor log cannot be removed by anyone.

The API includes an admin-only erase endpoint (POST /admin/erase): it rejects customer-grade API keys, and it acts only on runs created with the calling admin key. It destroys an encryption key and issues a sealed deletion receipt. Today no stored field is encrypted with these keys, so calling the endpoint does not remove or hide any sealed content, metadata, or other stored data.

Your rights

Depending on where you live, data protection law may give you the right to access, correct or delete your personal data, to receive a copy of it, and to object to or restrict how it is used. [Pending review by counsel: which of these rights apply to Verdifax's users.] To make a request, email privacy@verdifax.com. We respond within thirty (30) days.

The service has no self-service tools for these requests, so we handle each one by hand. We cannot currently remove metadata from sealed records, and no one can remove entries from the Rekor log. If you are in the European Economic Area or the United Kingdom, you can also complain to your data protection authority.

International transfers

Our API and database are hosted in the United States, on Fly.io in Ashburn, Virginia. AWS KMS and Amazon SES, which Resend uses to send our email, run in the us-east-1 region in the United States. Our website, dashboard and documentation are delivered through Cloudflare's global network, so requests to those sites may be handled at Cloudflare locations outside the United States.

If you are in the European Economic Area, the United Kingdom or Switzerland, your personal data is transferred to and stored in the United States. Verdifax has not entered into Standard Contractual Clauses for these transfers and has not self-certified under the EU-U.S. Data Privacy Framework. [Pending review by counsel: the transfer mechanism for personal data of users in the European Economic Area, the United Kingdom and Switzerland.]

Security

Connections to our website and API use TLS 1.2 or higher. Our database is stored on an encrypted volume. Our application does not add a separate layer of encryption to the data inside the database. API keys are stored as SHA-256 hashes, and we never store the key itself.

When we create an API key, our server also generates an Ed25519 signing key pair for it and stores both keys, including the private key, in our database. The actor signature in each sealed record is made by our server with that stored private key. It shows that Verdifax's server signed the record with the key assigned to your API key, not that you signed it yourself. The key we use to sign entries in the Rekor log is stored as a file on the same server volume. AWS KMS holds the master key for our record-erasure feature, which, as described under Retention, does not currently encrypt any stored data.

If a security incident affects your personal data, we will notify affected people and the relevant authorities where the law requires it.

Changes

When we change this policy, we post the new version on this page and update the "Last updated" date above. For material changes, we will also email account holders. We send these emails by hand, because the service has no automated notice system.

Contact

Questions or concerns about this policy can be sent to privacy@verdifax.com. Legal questions can be sent to legal@verdifax.com.