Privacy

What is collected

Agent traces. When you install the SDK, it sends a trace of each agent run: the names of the tools your agent called, the arguments it passed them, the instruction the run started from, and the claim the agent made about what it did. Tool arguments routinely contain recipient email addresses and subject lines, because that is what an email tool takes as input.

Gmail metadata. Only for messages that fall inside the time window of a trace being verified, and only these fields: recipient, subject, timestamp, and the filenames of attachments.

Your account. Email address and a password hash, held by Supabase Auth. Passwords are never visible to this application.

If you answer the poll on the home page: the framework you picked, your free-text answer if you gave one, and your email address if you chose to leave one. The email field is optional and the poll works without it.

There is no analytics, no tracking script, and no third-party JavaScript on this site.

What Gmail access is used for

Read-only, and for one purpose: checking whether an email your agent claimed to send actually exists in the mailbox. The scope granted is gmail.readonly. Nothing is ever sent, modified, labelled, or deleted.

Message bodies are never read and never stored. One detail worth stating precisely rather than glossing: messages are requested in Gmail’s full format, because that is the only format that returns the attachment structure, and attachment filenames are needed to verify a claim that something was attached. That response therefore contains the message body. Nothing in the code reads it, nothing writes it anywhere, and it is discarded with the rest of the response. What is kept is only the four fields listed above.

Only the mailbox you connect is ever queried, and only within the time window of a run you sent.

Where it is stored

In a Postgres database hosted by Supabase. Access is restricted at the database level: row level security is enabled on every table and the public API roles have no grants, so the data is reachable only by this application’s server.

Verification records are append-only. Claims and verdicts can never be edited or deleted in place — the database rejects the attempt. That is the point of the product: evidence that can be quietly rewritten is not evidence. The practical consequence for you is that correcting a stored verdict is not possible; the only operation is deleting the project and everything under it.

Your API key is stored only as a hash, so it cannot be recovered from the database — losing it means generating a new one. A Slack webhook you configure is stored encrypted.

Who it is shared with

Nobody. Your data is not sold, not shared with advertisers, not used to train models, and not sent to any third-party AI service.

The one exception is the one you set up yourself: if you add a Slack webhook on the settings page, then each alert — which contains the claim text, and so the recipient address inside it — is posted to the Slack channel you chose. That happens only for projects that have configured a webhook, only to that project’s own channel, and stops when you remove it.

The infrastructure providers who necessarily handle the data are Supabase (database and authentication), Vercel (hosting), and Google (the Gmail API you connect).

How to delete your data

Email mishraaditya2517@gmail.com from the address you signed up with and ask. Your project, its traces, its claims and its verdicts are removed, along with the account itself. There is no retention period afterwards and no archived copy.

You can also revoke Gmail access yourself at any time, without asking anyone, from your Google account permissions. Verification stops working immediately; nothing already stored is affected.

Contact

mishraaditya2517@gmail.com — for deletion requests, questions about any of the above, or to tell me something here is wrong.