signafAIde privacy notice

• Controller: AIME TECH UK LIMITED, registered in England and Wales, company number 16819323, registered office 42 Beaufort Court, Admirals Way, London, England, E14 9XL.
• Privacy contact: [email protected].
• Data Protection Officer: Miryem Salah. Contact: [email protected]. ICO registration number: ZC169006.

We are the controller for personal data we use to run our own business: console accounts, organisation membership, billing, support, website and console analytics, the SDK client header, security logs and our communications with you.

We are a processor for personal data that our customers choose to put in the records they send to the Service (Customer Data). Our customer decides what their agents record and why. If your personal data is in a customer's records, that customer is the controller and you should contact them first. We process Customer Data only on their instructions, under our data processing agreement.

For a self-hosted signafAIde witness, the customer runs the software in its own environment and we do not receive its data.

The SDKs, CLI and MCP server work locally first. Until a person runs signafaide init (or the MCP signafaide_init tool) or sets an API key, they send nothing to us: no records, no registrations, no usage events, no client header, and no sandbox request. Setting SIGNAFAIDE_URL alone sends nothing.

4.1 Console accounts and organisations #

• What: email address; name (if you give it or your GitHub profile provides it); GitHub numeric user id, if you sign in with GitHub; your OpenID Connect issuer and subject identifier, if your organisation uses SSO; when the account was created and last signed in; the version of our terms and this notice you accepted, and when; organisation memberships and roles; invitations you send or receive (invitee email address); a record of actions taken in the console (for example exports, key revocations, member changes), with the acting user's email address.
• Sign-in data: one-time sign-in links (stored only as a hash, valid 15 minutes); session tokens (stored only as a hash, valid 30 days); short-lived sign-in state for GitHub and SSO (10 minutes).
• From GitHub: when you sign in with GitHub, we request the read:user and user:email scopes and receive your profile and email address.
• Why and lawful basis: to create and secure your account and give you access (contract, Article 6(1)(b)); to keep an audit trail of console actions for security and so your organisation can see who did what (legitimate interests, Article 6(1)(f)).

4.2 Billing #

• What: the organisation's plan, Stripe customer and subscription identifiers, billing status, monthly usage counts, and the email address used to start checkout. Card and payment details are collected and held by Stripe, not by us.
• Why and lawful basis: to take payment and keep accounts (contract, Article 6(1)(b)); to keep tax and accounting records (legal obligation, Article 6(1)(c)).

4.3 Sandbox projects #

A sandbox is created without an account, email or card. We store the sandbox project, a hash of its API key and a hash of its claim token. We use the requesting IP address in memory to limit sandbox creation (10 an hour per address by default) and do not store it in the database. An unclaimed sandbox is deleted 30 days after creation.

• Lawful basis: legitimate interests in providing a free trial and preventing abuse (Article 6(1)(f)).

4.4 Website and console analytics #

Our website, documentation and console send a page-view event to our own server. We do not use third-party analytics, advertising or tracking tools. Our analytics set no cookies and store nothing in your browser (no local storage, session storage or similar).

• What each page view records: time; the page path, with tokens, project ids, organisation ids and record hashes removed in the console; the referring site's host name (only when you arrive from another site); ref and utm_* campaign tags if present in the link; a browser family (for example "firefox") and a bot flag derived from the user agent; and a visitor hash.
• Visitor hash: a hash of your IP address and user agent combined with a random salt that changes every day and is never stored. We do not store your IP address or the full user agent. The hash lets us count unique visitors within one day but cannot be linked across days. It is the only way we count visitors; we do not group page views into sessions.
• Do Not Track and Global Privacy Control: if your browser sends either signal, our pages send no page-view event at all.
• Retention: raw page-view events 90 days; daily totals (views, visitors, pages, referrers, campaigns) kept indefinitely, and contain no visitor hashes.
• Lawful basis: legitimate interests in understanding how our site is used and improving it (Article 6(1)(f)). See our cookie notice for how this fits with PECR.

4.5 API usage and the SDK client header #

When an SDK, the CLI or the MCP server talks to the Service, each request carries a header such as:

X-Signafaide-Client: signafaide-python/0.1.0 (python 3.12.3; adapter=none; agent=claude-code; via=sdk)

It names the SDK and version, the language runtime and version, the framework adapter in use, the coding agent detected when the project was set up (one of a fixed list, or "unknown"), how the call was made (sdk, cli or mcp), and whether strict mode is on. signafaide verify and signafaide export also tell the Service when they are run. No content, file paths, host names, user names or other personal information is in the header.

For each API request we record the time, method, endpoint, status, error code, latency, project and environment, and the header fields above. We also record product milestones per project (for example first verify, first export, features used).

• Opt-out: SIGNAFAIDE_TELEMETRY=0 removes the adapter and coding agent from the header, stops the coding agent being saved in the local config, and turns off the verify and export events. The SDK name and version are still sent.
• Retention: raw API events 90 days; daily totals and per-project milestones kept indefinitely.
• Lawful basis: legitimate interests in operating, securing and improving the Service and understanding which integrations are used (Article 6(1)(f)). This data is about software and projects and is not intended to identify individuals, but it is linked to a project that may belong to an identifiable person.

4.6 Security and abuse prevention #

• What: IP addresses, used in memory for rate limiting and not stored by our application; error and rejection counts per project and agent; logs held by our hosting and edge providers, which keep them for up to 30 days.
• Lawful basis: legitimate interests in keeping the Service secure (Article 6(1)(f)).

4.7 Emails and support #

• What: your email address and the content of messages. We send transactional emails: sign-in links, invitations and, if you set them up, alerts. They are sent through our email provider, Brevo, from [email protected], and replies go to [email protected]. We do not send marketing emails.
• Lawful basis: contract (Article 6(1)(b)) for service emails; legitimate interests (Article 6(1)(f)) for support.

4.8 Staff administration #

Our staff access the operator admin (analytics and plans) through Cloudflare Access, limited to our company email domain. Staff actions in the admin are logged with the staff member's email address.

When a customer opts in, the Service receives for each record by default: a hash of its content, and the record envelope (record kind, project, environment, agent name, sequence number, link to the previous record, time, tool or action name, and a reference to an earlier record where relevant). It also receives each agent's public key. Inputs and outputs are not sent unless the customer turns on stored content.

If a customer turns on stored content, we also receive the content they choose to send, which may include personal data. Stored content is encrypted at rest with per-organisation keys and deleted one year after receipt, or seven years after receipt while the customer's organisation has the retention add-on. Envelopes and hashes are kept with no time limit while the customer's account is active.

We publish only one hash per anchor (about one an hour, covering many customers' batches) to public timestamp services. No record content or envelope is published.

Customers are responsible for not putting personal data in agent names or tool names, and for having a lawful basis for anything they record.

We share personal data with the service providers listed in our sub-processor list at /legal/subprocessors, including our hosting provider (Google Cloud), our email provider (Brevo), Stripe (payments), Cloudflare (edge network and staff admin access) and GitHub (if you sign in with GitHub). The public randomness and timestamp services we use receive no personal data.

We may also disclose data if the law requires it, to protect our rights or the safety of others, or to a buyer or successor of the business under equivalent protections.

We do not sell personal data and do not share it for advertising.

We host the Service on Google Cloud Platform in the London region (europe-west2), so Customer Data and our data are stored in the United Kingdom by default. Some providers (for example Stripe, Cloudflare and GitHub) may process data outside the UK and EEA, including in the United States. Where this happens we rely on: UK adequacy regulations or the EU Commission's adequacy decisions (including the UK Extension to the EU-US Data Privacy Framework where the provider is certified); or the International Data Transfer Agreement or the EU Standard Contractual Clauses with the UK Addendum, with a transfer risk assessment. You can ask us for details.

8.1 Deleting your account, organisation or project #

You can delete your account, and an organisation owner can delete a project or the whole organisation, yourself in the console. You type the name (or your email address) back and must have signed in within the last 15 minutes. The deletion is recorded in the console audit log and takes effect at once.

• Deleting your account removes your user record, sessions, memberships, SSO identities, sign-in links and invitations to your address. Your email address is removed from all console audit log entries (entries keep the action, not who did it). Organisations where you are the only member are deleted with your account.
• Deleting a project removes its records (envelopes, including agent and tool names, content hashes, signatures and stored content), receipts, batches, agents and their keys, API keys, auditor links, alert settings, experiments, audit packs, usage counts and the analytics events and milestones that name it.
• Deleting an organisation deletes all its projects as above, plus its members, invitations, billing details held by us, customer-managed keys, SSO settings and its console audit log, and cancels its Stripe subscription.

What we keep after a deletion, exactly:

• for each of the deleted project's batches that had already been anchored: the batch hash (SHA-256), its position in the anchor's Merkle tree and its Merkle path. Other customers' proofs and our published anchors point into the same Merkle trees. These values name no project, organisation, agent, record or person;
• the anchors (Merkle roots, signatures and public timestamp proofs) and our service key history, which cover many customers at once;
• one console audit entry recording the deletion and its time; for a project or organisation it names the owner who deleted it, for an account it names no one;
• the hash submitted to public timestamp services for each anchor, which those services and the public ledger behind them hold permanently and which nobody can withdraw;
• billing records that Stripe and we must keep by law, and backup copies until the backups expire (backups are kept for 30 days).

Under UK and EU data protection law you have the right to: access your personal data; have it corrected; have it erased; restrict or object to our processing, including processing based on legitimate interests; data portability; and withdraw consent where we rely on it. To use these rights, contact [email protected]. We will reply within one month, which may be extended where the law allows.

If your request concerns a customer's records, we will pass it to that customer and help them respond, as their processor.

You can complain to the Information Commissioner's Office (ico.org.uk, 0303 123 1113), or, in the EU, to your local supervisory authority. We would appreciate the chance to deal with your concern first.

We do not make decisions about you based solely on automated processing that have legal or similarly significant effects. The Service records decisions made by our customers' AI agents; it does not make or assess those decisions.

We protect personal data with measures including encryption in transit, hashing of API keys, sign-in links, session tokens and claim tokens, encryption at rest of stored content with per-organisation keys, role-based access in the console, and restricted, logged staff access. The data processing agreement describes the measures in more detail.

We will post changes to this notice here and update the effective date. If a change is significant, we will tell organisation owners by email or in the console.