Privacy

Data Processing Agreement (template)

Template, not legal advice. Have your lawyer review it. This is a starting point for a business that uses Counterseal and needs a data processing agreement. It has not been reviewed by a lawyer for you or for us, it is not signed by anyone by being on this page, and it does not change our terms or privacy policy. Words in [square brackets] are choices to fill in. Every promise below describes what the service does today; where a promise depends on people rather than code (for example, how fast we tell you about a breach), it is marked as a choice for you and us to agree.

Version 0.1, 9 October 2026

1. Parties and roles

This agreement is between [Customer legal name, address] (the Controller, or the organisation in control of the personal information under PIPEDA) and Gautam Khosla, Ottawa, Canada, operating Counterseal (the Processor). It applies to personal data the Processor processes for the Controller through the Counterseal service (counterseal.gautamkhosla.com; leash.gautamkhosla.com only redirects there). For the data the Processor needs to run the account itself (the account's sign-in, abuse prevention and totals about how the product is used), the Processor decides on its own and the privacy policy applies.

2. What is processed

Subject matter, nature and purpose: holding irreversible API calls and coding-agent commands until a person approves them with a passkey, keeping the Controller's API keys encrypted, recording decisions in a hash-chained audit log and, if the Controller leaves public receipts on, in a public log without personal data. Duration: while the Controller's account exists, then as in section 10. Categories of data subjects and data: see Annex 1.

3. Processing only on instructions (GDPR Art. 28(3)(a))

The Processor processes the data only to provide the service as the Controller configures and uses it (its settings, tokens, policies and decisions are its documented instructions), and as this agreement says. If a law requires other processing, the Processor tells the Controller first unless that law forbids it. The Processor tells the Controller if it believes an instruction breaks data protection law.

4. Confidentiality (Art. 28(3)(b))

Only the Processor's operator has access to the production systems, and is bound to confidentiality. [If anyone else is given access, they are bound to confidentiality first.] No one can read a vaulted API key in the database: each is encrypted with its own key, wrapped by a master key held outside the database.

5. Security (Art. 28(3)(c) and Art. 32)

The Processor keeps the technical and organisational measures in Annex 2 and may change them only to keep or raise the level of protection. Its security standards self-assessment maps them to OWASP standards; it is self-assessed, not certified.

6. Subprocessors (Art. 28(2) and 28(4))

The Controller authorises the subprocessor on the subprocessors page (Cloudflare, Inc.). The Processor gives [30] days' notice before adding or replacing one, by updating that page and [emailing the Controller's contact]; the Controller may object on reasonable data protection grounds, and if the parties cannot resolve it, may end the service and delete its account. The Processor holds each subprocessor to data protection obligations at least as protective as these, through that subprocessor's own data processing terms, and stays responsible for it.

7. Helping with data subjects' rights (Art. 28(3)(e))

The service lets the Controller answer most requests itself: its owner can see all the data in the app, download all of it as one file (Privacy, Download all my data), delete keys, tokens and team members, set how long closed held calls are kept, and delete the whole account. If a data subject writes to the Processor directly, the Processor passes the request to the Controller [within 5 business days] and does not answer it on the Controller's behalf unless asked to.

8. Personal data breaches (Art. 33 and PIPEDA s. 10.1)

The Processor tells the Controller about a personal data breach affecting the Controller's data without undue delay after becoming aware of it, and in any case within [48] hours, with what is known then (what happened, what data and roughly how many people, likely consequences, what is being done) and updates as it learns more. It keeps a record of every breach. The Controller decides whether to notify regulators and people. Notices go to [the Controller's security contact].

9. Other help (Art. 28(3)(f))

The Processor gives the Controller the information it reasonably needs for security, breach notification, data protection impact assessments and prior consultation, mostly through the documentation already public (the security page, the threat model and the protocol in the source repository) and [at the Controller's cost for anything beyond that].

10. Return and deletion at the end (Art. 28(3)(g))

Before the end, the Controller can download all its data (section 7) and the evidence pack (Audit log, Evidence pack). Deleting the account in the app erases at once the account, its people, passkeys, vault, tokens, keys, holds, sessions, alert devices, rate limit counters and the audit log, and unlinks its public log entries so nothing on the Processor's side says whose they were. Two things remain, by design, and the Controller accepts them: public log entries already published stay in the append-only public log (they hold no name, path, body, key, token or IP address); and database backups kept by the subprocessor roll off within 30 days.

11. Information and audits (Art. 28(3)(h))

The Processor makes available the information needed to show it meets this agreement: this agreement, the security self-assessment, and the service's source code, tests and threat model in its public repository. [Once a year, on 30 days' written notice, at the Controller's cost,] the Controller or an independent auditor bound to confidentiality may audit further, in a way that does not expose other customers' data or the service's secrets.

12. International transfers

The Processor is in Canada, which the European Commission recognises as providing adequate protection for organisations subject to PIPEDA. The subprocessor processes data in the United States and at its edge locations worldwide, under its own data processing addendum, which covers transfers out of the EU, the UK and Switzerland (see the subprocessors page). [If the Controller needs Standard Contractual Clauses with the Processor itself, attach them here: Module 2 or 3 as fits.]

13. Canada: PIPEDA

Under PIPEDA's accountability principle (Schedule 1, 4.1.3), the Controller stays responsible for personal information it transfers to the Processor, and this agreement is the contractual means for a comparable level of protection while the Processor handles it. The Processor uses the information only for the purposes in section 2, protects it with safeguards suited to its sensitivity (Annex 2; principle 4.7), keeps it no longer than section 10 and the retention settings allow (principle 4.5), helps the Controller answer access and correction requests (principle 4.9, through section 7), and tells the Controller about a breach of security safeguards as in section 8 so the Controller can assess real risk of significant harm and report and notify as PIPEDA requires. [If Quebec's Law 25 or another provincial law applies to the Controller, add its terms here.]

Annex 1: data subjects and data

• People on the Controller's account (its owner and team members): name as typed, role, passkey public keys and their fingerprints, sessions, coarse place (country and network name) of command line sign-ins, seals they give, alert devices' push addresses if they turn alerts on.
• Anyone whose data appears in the Controller's agents' requests or commands (for example a customer whose refund an agent asks for, or a name in a command): only in the preview of a held request (dropped a day after it closes), a held command (kept with its hold, 365 days by default, 30 or 90 if the owner chooses), the private audit log's path field (first 300 characters), and, for a Stripe call let through by a money cap, its amount and charge id in the private audit log. Never in a public receipt.
• No special categories of data are needed or asked for. The Controller should not send them in agent requests that will be held.

Annex 2: technical and organisational measures

• Sign-in and every approval with a passkey (WebAuthn, user verification required); no passwords exist.
• Each vaulted API key encrypted with AES-256-GCM under its own key, wrapped by a master key held as a platform secret outside the database, and bound to its row; no API returns a key.
• Agents get scoped, expiring, revocable tokens; tokens, keys and sessions are stored only as SHA-256 hashes.
• Roles checked on the server for every request; destructive changes need a fresh passkey ceremony; account-wide actions need the owner.
• HTTPS only (HSTS), a strict Content Security Policy with Trusted Types, no third-party code on any page.
• Rate limits on every endpoint; per-account ceilings on everything an account can create.
• A hash-chained audit log of every decision and security change, exportable and verifiable by the Controller.
• Request logs off (Workers Logs disabled); IP addresses kept only as salted hashes for rate limiting, for a day at most.
• An automated test suite for every security rule, run in continuous integration; a public threat model; a security contact in /.well-known/security.txt.

Contact for this agreement: privacy@gautamkhosla.com.