Data Processing Addendum
The short version
- Anvil Cloud is US-hosted. There is no EU or UK data residency option today.
- For customer data flowing through a guarded action, you are the controller and Anvil is your processor. For our own account, site, and security data, Anvil is the controller — the privacy statement says which is which.
- Seven sub-processors, listed in section 4. Two of them are AI providers that are conditional and currently off — no customer content reaches a model provider on
anvilcontrol.aitoday. - We notify you of a personal data breach without undue delay after becoming aware of it, not after we have finished concluding things.
- Deletion is on request and it is a manual operation. There is no automatic expiry for decision records yet, and we say so rather than describe a schedule that does not exist.
- We hold no SOC 2, no ISO 27001, and no completed third-party penetration test.
What this page is, and what it is not
This page states the data-processing commitments Anvil makes today, in enough detail for a security or procurement review to be done against it. Every technical statement below describes behaviour that exists in the running service.
This page is not an executed contract. It is a public statement, not a signature. If you need a signed DPA, email henry@anvilcontrol.ai and we will reply within one business day.
To be exact about where we are: we do not keep a pre-drafted counter-signable DPA on the shelf today. For a customer who needs one we will produce it, built on the commitments on this page, and we would rather tell you that than imply a document is already waiting for your redlines. Where a signed DPA exists and differs from this page, the signed DPA governs.
Anvil is provided by Henry Miller, an individual trading as Anvil, in San Francisco, California; no operating entity has been incorporated yet, and when one is we will name it here. A signed agreement is still where a registered address and a negotiated governing law belong — but we are not going to leave you guessing who is on the other side of this page.
1. Roles
| Role | Who |
|---|---|
| Controller / business | You, the customer |
| Processor / service provider | Anvil |
| Sub-processors | The parties listed in section 4 |
You determine the purposes and means of processing. We process personal data contained in customer data only to provide, secure, support, and improve the service, on your instructions, and as required by law. We do not process it for our own purposes, we do not sell or share it, and we do not use it outside that business purpose.
2. Subject matter of the processing
| Item | Detail |
|---|---|
| Nature and purpose | Evaluating your policy against actions your systems take; suppressing duplicate execution; recording decisions for audit; routing approvals; analysing logs and configuration you submit |
| Duration | For the term of your use of the service, plus the retention described in section 7 |
| Categories of data subjects | Your end users and customers, to the extent they appear in an action you guard; your own personnel who sign in, approve, or override |
| Categories of personal data | Identifiers and contact data appearing in guarded actions or submitted logs (for example an email address, a counterparty name, an account reference); transaction amounts and references; your personnel's email addresses; IP addresses and user agents in request logs |
| Special-category data | Not supported. Anvil is not a supported environment for protected health information or raw payment-card authentication data, and you must not submit either |
| Automated decision-making | Anvil evaluates your rules and can block or delay an action. It is a control on your systems, not a decision engine about individuals, and it must not be used to make fully automated consequential decisions about people |
3. Confidentiality and personnel
Access to production systems and customer data is limited to the small number of people who need it to operate and support the service. Those people are bound by confidentiality obligations that survive their engagement. Access is via individually authenticated accounts, and administrative actions in the product are attributed to the operator who took them — an approval or an override records the operator's email on the audit record.
4. Sub-processors
These are the third parties that may process customer data on our behalf. The first five are in active use. The two AI rows are conditional and are off on anvilcontrol.ai today.
| Sub-processor | Purpose | Status | Location |
|---|---|---|---|
| Railway | Application hosting, Postgres database, Redis | Active | United States |
| Cloudflare | CDN and static hosting for the public site | Active | United States |
| GitHub (Microsoft) | Source hosting, the build pipeline, and storage of the daily database backup artifact | Active | United States |
| Resend | Transactional and alert email | Active | United States |
OAuth sign-in, scope openid email profile | Active | United States | |
| Anthropic | AI-assisted analysis, only on a deployment with AI analysis enabled and an Anthropic key configured | Conditional — currently off | United States |
| Google (Gemini) | AI-assisted analysis, only on a deployment with AI analysis enabled and a Gemini key configured | Conditional — currently off | United States |
Why GitHub is on this list. Our host does not provide native Postgres backups on our current plan, so the daily backup is taken by our own build pipeline and retained there as a private artifact. A full copy of the database therefore exists in a second place. That is a deliberate trade for having a restorable backup at all, and it belongs in the table rather than in a footnote.
Sub-processor obligations. We impose data-protection obligations on each sub-processor that are materially no less protective than those in this page and in any DPA we sign with you, and we remain responsible to you for a sub-processor's performance as if it were our own.
External model processing is conditional and disableable. AI-assisted analysis requires both an explicit enablement flag and a provider key. With either missing, no customer content reaches any model provider. Where it is enabled, only a redacted excerpt is sent, the response is cached to avoid repeat calls, and no customer content is used to train models. If your requirement is that no content ever reaches an external model, say so and we will confirm the configuration in writing.
Customer-directed integrations are outside this list. When you connect a system you own — for example Stripe, Datadog, CloudWatch, Splunk, Temporal, Airflow, Twilio, n8n, LangSmith, Langfuse, or Helicone — Anvil pulls from that provider using read-scoped credentials you supply. That provider is your processor under your agreement with them, not our sub-processor. Anvil holds the credential in memory for the pull window (up to 12 hours), never returns it to the browser, and does not write it to durable storage.
Notification and objection. We maintain the list above as the current one. Customers under a signed agreement are notified before a new sub-processor begins processing their data, and the signed DPA sets out the objection procedure and the remedy if a reasonable objection cannot be resolved.
5. Security measures
Stated as implemented, not aspirational.
| Control | Status today |
|---|---|
| Encryption in transit | TLS on every hosted surface; HSTS in production |
| Encryption at rest | Provided by our host for the database and Redis, and by GitHub for the daily backup artifact |
| Credential storage | API keys stored as hashes with a non-secret prefix; the key is not recoverable from our database. Connector credentials held in memory only, never written to durable storage. Webhook signing secrets — the shared secrets used to sign retry and approval callbacks to your endpoint — are stored as cleartext in the database, because the server is the signer and needs the value to compute the HMAC; they are covered by encryption at rest and production access controls, and rotating one is an update you make. We would rather name that than let "credentials are hashed" imply more than it covers |
| Tenant isolation | Every tenant-scoped read and write is filtered by workspace at the query layer, with automated checks that fail the build on a raw un-namespaced key, plus a two-tenant end-to-end isolation test |
| Authentication | Google OAuth for the control plane; hashed API keys for the runtime API. Reads and the interface fail closed in production when no control token is configured |
| Authorisation for high-risk actions | Maker-checker approvals with self-approval blocked; overrides require an armed, single-use token and are recorded against the operator |
| Audit records | Decision records for every guarded call, linkable into a tamper-evident hash chain that anvil verify checks. HMAC signing of that chain is off unless a signing key is configured, and the product labels the unsigned state honestly rather than implying attestation |
| Durability | Money-path execution truth is written to Postgres before the action, so a crash cannot lose the record that made double-execution possible. The service refuses to boot in production on undeclared ephemeral storage |
| Secure development and change review | Every change goes through pull request review, a typed build, and a test suite that gates deploys; security fixes ship with a regression test that fails on the vulnerable code |
| Vulnerability and dependency management | Automated dependency audit in the pipeline |
| Backups and restore | A daily logical pg_dump of the production database that is restored into an empty database and row-count-verified in the same automated run — a dump that does not restore fails that day's run, loudly, rather than being discovered on the worst day. The dump is kept for 14 days as a private build artifact at GitHub, downloadable only by repository collaborators and encrypted at rest by GitHub. Our host does not provide native Postgres backups on our current plan, which is why this runs instead of a host feature. Every run writes a receipt, pass or fail, and a release checks those receipts |
| Business continuity and recovery | The daily verified restore above is the recovery plan, and it is tested every day rather than annually. What we do not have: a documented recovery-time or recovery-point objective, a second region, or a failover that does not involve a person. Recovery is a manual restore performed by one operator. We would rather state that than describe a continuity programme we do not run |
| Personnel security | Production access is held by one person — the operator, who is also the author — through individually authenticated accounts at our host, our source host, and our identity provider. There is no shared login and no service account a human signs in as. There is no background-check, security-training, or offboarding programme, because there is no one to run it on. When that changes, this row changes with it |
| Availability monitoring | Public status page with component checks and incident history |
| Incident response | Documented reporting channel and response commitments — see section 8 |
| Independent assessments | None today. We hold no SOC 2, ISO 27001, or completed third-party penetration test, and we are not going to imply otherwise. If a report is a requirement for you, tell us and we will tell you honestly where we are |
Where you have a signed agreement, the security schedule in that agreement — not this page — defines our commitment.
6. Assistance with data-subject requests
If you receive a request from a data subject that requires data held in Anvil, email henry@anvilcontrol.ai and we will help you locate, export, correct, or delete it. Decision records are also exportable by you directly, through the anvil audit command and the decision log in the dashboard.
If a data subject contacts us directly about data we process for you, we will not respond substantively on your behalf — we will refer them to you and tell you it happened.
Impact assessments and prior consultation. If you need to complete a data protection impact assessment, or consult a supervisory authority, about processing that runs through Anvil, we will give you the information we hold about how the service works, what it stores, where it stores it, and who can reach it — the same detail as this page, in whatever form your assessment needs. Ask, and it is a conversation, not a ticket.
7. Retention, deletion, and return
| What | Retention today |
|---|---|
| Submitted log or config text (ghost intake) | Not retained. Parsed in memory; never written to a file or a database row |
| Ghost intake report and its rendered PDF | Up to 30 minutes in the Redis job store, and up to 12 hours in server memory, so the report can be rendered, downloaded, and emailed. Dropped after that, and not preserved across a restart |
| Intake session counters | Up to 12 hours, in memory |
| Connector credentials | The pull window, up to 12 hours, in memory |
| Sign-in and session records | 30 days after last use, in Redis, expiring on their own |
| Decision records, receipts, policies, usage events | Retained until deletion is requested. No automatic expiry is implemented today |
| Idempotency records | 24 hours by default; this is the duplicate-suppression window |
| Database backups | 14 days — a daily dump kept as a private build artifact at GitHub; 14 days is that artifact's retention |
Deletion is on request, by email, and it is a manual operation. There is no self-serve deletion endpoint today, and we would rather say that than describe an automatic schedule that does not exist. Send the request to henry@anvilcontrol.ai and we will confirm receipt within one business day and tell you what was removed.
A contractual retention period and a contractual deletion deadline are exactly the kind of thing the signed DPA should fix. We have deliberately left them open here rather than announce a period the service does not yet enforce.
Backups, security logs, records under legal hold, and records we are required by law to keep may persist for a limited additional period after deletion.
8. Personal data breach
If we become aware of a personal data breach affecting customer data in our control, we will notify you without undue delay — not only once we have confirmed the full picture, and not conditional on our own view of whether a law requires notice. Your notification clock depends on hearing from us early and imperfectly rather than late and completely, so that is what we have committed to.
With that notice we will give you the facts we have at the time, say plainly what we do not yet know, update you as we learn more, give you what you reasonably need for your own notification obligations, and cooperate on investigation and remediation. Notice is not an admission of fault.
Unsuccessful access attempts, scans, pings, and denial-of-service attempts that do not compromise customer data are not breaches and are not notified as such.
For customers under a signed agreement, the notification obligations in that agreement control where they are stricter. Our published security-response commitments — acknowledgement within one business day, a triage and severity call within three business days, and a seven-day target for anything that lets money move incorrectly, crosses a tenant boundary, or exposes credentials — apply to everyone, and we will tell you before we miss one of those windows rather than after.
9. International transfers
Anvil Cloud is hosted in the United States and all sub-processors in section 4 process in the United States. We do not offer EU or UK data residency today.
Where personal data is transferred from the EEA, the UK, or Switzerland, the mechanism is a signed DPA incorporating the EU standard contractual clauses, Module Two (controller to processor), and the UK International Data Transfer Addendum where the UK GDPR applies. A public page cannot execute those clauses — see the note at the top of this page for exactly where we stand on producing one, which is honest rather than convenient.
During beta the service is aimed primarily at US customers. If you are selling into the EEA or the UK and need executed transfer terms before you can adopt Anvil, tell us early — that is a real amount of work and we would rather schedule it than surprise you.
10. Audits and compliance information
On reasonable request and under NDA we will answer a security questionnaire, walk your team through our architecture and controls, and provide the documentation we have. We do not currently hold a third-party audit report to hand over, and we will say so directly rather than defer the question.
11. Government and law-enforcement requests
If we receive a legally binding request for customer data, we will, unless legally prohibited, tell you before disclosing anything so you can seek protective relief, disclose only the minimum the request compels, and challenge a request that appears overbroad or unlawful.
12. Prohibited processing
We do not sell customer personal data, do not share it for cross-context behavioural advertising, do not retain or use it outside the business purpose of providing the service, and do not combine it with data from other sources except as needed to provide the service to you.
13. Term, survival, and liability
This page applies for as long as Anvil processes personal data on your behalf. The confidentiality, security, and deletion obligations in it survive the end of your use of the service for as long as any of your data remains with us or in a backup.
Liability for a breach of these processing obligations is governed by the limitation of liability in the Terms — during the free beta, capped at what you have paid us, which is nothing — or by the liability terms of a signed agreement where one exists. We are telling you that directly rather than leaving a second blank: a data-processing page that is silent on liability is not more protective, it is just less clear.
14. Order of precedence
Where a signed Master Services Agreement or DPA exists between us, that document governs. Otherwise this page and the Terms are the operative statement of how we handle your data, and the Terms incorporate this page by reference.
This page is intended to be consistent with everything else we publish. If you find a place where it is not, tell us at henry@anvilcontrol.ai and we will fix the page — that is not a courtesy, it is the only way a document like this stays worth reading.