# signafAIde data processing agreement Version: 1.2 Effective date: 14 November 2026 This data processing agreement ("DPA") forms part of the signafAIde terms of service, or the Enterprise agreement, between AIME TECH UK LIMITED, registered in England and Wales, company number 16819323, registered office 42 Beaufort Court, Admirals Way, London, England, E14 9XL ("Processor", "we") and the customer organisation ("Controller", "you"). It applies to personal data in Customer Data that we process for you when providing the hosted signafAIde Service. It meets Article 28 of the UK GDPR and, where it applies, Article 28 of the EU GDPR. It does not apply to a self-hosted signafAIde witness, where you run the software and we do not receive its data, except to the extent we access it under an Enterprise support arrangement, which then sets out that access. ## 1. Definitions Terms such as "controller", "processor", "personal data", "personal data breach", "processing" and "data subject" have the meanings in the UK GDPR (and the EU GDPR where it applies). "Data Protection Law" means the UK GDPR, the Data Protection Act 2018, the EU GDPR where it applies, and any laws that replace them. "Customer Data" and "Service" have the meanings in the terms of service. "Sub-processor" means a third party we engage to process Customer Data. ## 2. Roles and instructions 2.1 You are the controller and we are the processor of personal data in Customer Data. 2.2 We process Customer Data only on your documented instructions, which are: these terms and this DPA; your configuration and use of the Service (including which records you send, whether you turn on stored content, which members and auditor links you create, and which exports you run); and any further written instructions we agree. We will tell you if we believe an instruction breaks Data Protection Law, unless the law prevents us. 2.3 We may process Customer Data where UK or EU law requires us to, and will tell you before doing so unless the law prohibits it. 2.4 You are responsible for: the lawfulness of the processing; giving any notices and obtaining any consents data subjects need; deciding what your agents record; not putting personal data in agent names, tool or action names or other envelope fields; and deciding whether to use stored content. ## 3. Details of the processing The subject matter, duration, nature and purpose of processing, the types of personal data and the categories of data subjects are set out in Annex 1. ## 4. Confidentiality We ensure that everyone we authorise to process Customer Data is bound by a duty of confidentiality, contractual or statutory, and has access only as needed to provide, secure and support the Service. ## 5. Security 5.1 We implement the technical and organisational measures in Annex 2, which are designed to give a level of security appropriate to the risk, as required by Article 32. 5.2 We may update these measures, provided the overall level of security is not reduced. ## 6. Sub-processors 6.1 You give general authorisation for us to use the sub-processors in our sub-processor list at /legal/subprocessors. 6.2 We will give you at least 30 days' notice of a new or replacement sub-processor, by updating the list and emailing organisation owners. You may object on reasonable data protection grounds within that period. If we cannot address the objection, you may terminate the affected part of the Service and receive a refund of prepaid fees for the unused period. 6.3 We impose data protection obligations on each sub-processor equivalent to this DPA, and remain liable to you for its performance. 6.4 The public randomness and timestamp services described in Annex 1 section 6 receive no Customer Data other than, in the case of the timestamp services, one hash per anchor that combines many customers' batches. We do not treat them as sub-processors. ## 7. Data subject requests Taking into account the nature of the processing, we will help you respond to requests from data subjects to exercise their rights. If we receive a request about Customer Data directly, we will pass it to you without undue delay and will not respond except to direct the person to you, unless you instruct us otherwise. Most data in records is hash-only and can be exported by you through the console and API; see also section 10 on deletion. ## 8. Assistance We will provide reasonable help with your data protection impact assessments, prior consultations and security obligations, taking into account the nature of the processing and the information available to us. ## 9. Personal data breaches 9.1 We will notify you without undue delay, and in any event within 48 hours, after becoming aware of a personal data breach affecting Customer Data. 9.2 The notice will describe, as far as we know at the time: the nature of the breach; the categories and approximate number of data subjects and records concerned; the likely consequences; and the measures taken or proposed. We will provide further information as it becomes available. 9.3 We will notify the email addresses of your organisation's owners and admins, and post a notice in the console. 9.4 Notice of a breach is not an admission of fault. ## 10. Deletion and return 10.1 **During the Service.** Stored content is deleted automatically one year after receipt, or seven years after receipt while the Controller's organisation has the retention add-on. An unclaimed sandbox is deleted 30 days after creation. Revoking a customer-supplied content key (Enterprise) destroys our sealed copy of it, which makes content encrypted under it permanently unreadable. 10.2 **Return.** You can export verification packs, including stored content, at any time during the Service and, after termination, for the export period in terms section 16.4 (90 days where we terminate on notice for any reason, 30 days after any other termination). 10.3 **After termination.** After the export period we will delete Customer Data within 30 days, and from backups within a further 30 days as backups expire, except: (a) data we must keep by law; (b) one hash per anchor published to public timestamp services, which third parties record permanently and which cannot be withdrawn; and (c) anchors, service key history and, for each anchored batch, its batch hash and Merkle path, needed to keep other customers' records verifiable. These are hashes that do not contain record content, envelopes, agent or tool names, or any project, organisation or person identifier. 10.4 On request we will confirm deletion in writing. 10.5 **Self-service deletion.** At any time during the Service, an owner can delete a project or the organisation from the console, and a user can delete their own account. Deletion takes effect at once and keeps only what section 10.3(b) and (c) describe; it is your documented instruction to delete that Customer Data. ## 11. Audits and information 11.1 We will make available to you the information reasonably necessary to show compliance with Article 28, including answers to reasonable security questionnaires. 11.2 If that information is not enough, you (or an independent auditor bound by confidentiality, who is not our competitor) may audit our compliance with this DPA, once in any 12-month period, on at least 30 days' written notice, during business hours, at your cost, without access to other customers' data, and in a way that does not unreasonably disrupt our business. More frequent audits are allowed where a supervisory authority requires one or after a personal data breach. ## 12. International transfers 12.1 We will not transfer Customer Data outside the UK and EEA except in line with Data Protection Law. Our hosting region is the United Kingdom (Google Cloud, London, europe-west2). Enterprise customers can choose UK or EU data residency under their order form. 12.2 **UK transfers.** Where we or a sub-processor transfer Customer Data from the UK to a country without UK adequacy regulations, we will use the International Data Transfer Agreement or the International Data Transfer Addendum to the EU Standard Contractual Clauses, with a transfer risk assessment. 12.3 **EU transfers.** Where the EU GDPR applies to your processing and Customer Data is transferred to a country without an EU adequacy decision, the EU Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914), Module Two (controller to processor), are incorporated by reference, with: clause 7 (docking) included; clause 9 option 2 (general authorisation, notice as in section 6.2); clause 11 optional wording omitted; clause 17 governed by the law of Ireland; clause 18 courts of Ireland; Annexes I and II completed by Annex 1 and Annex 2 of this DPA. Onward transfers by us to sub-processors use Module Three where needed. ## 13. Liability and precedence 13.1 Each party's liability under this DPA is subject to the limits and exclusions in the terms of service (or Enterprise agreement). 13.2 If this DPA conflicts with the terms of service, this DPA prevails for the processing of personal data. If the Standard Contractual Clauses or the IDTA apply and conflict with this DPA, they prevail. 13.3 This DPA is governed by the law of England and Wales, except where the Standard Contractual Clauses require otherwise. --- ## Annex 1: Details of the processing ### 1. Parties - Controller: the customer organisation, as named in its console account or order form. Contact: the organisation's owners. - Processor: AIME TECH UK LIMITED, 42 Beaufort Court, Admirals Way, London, England, E14 9XL. Contact: sales@signafaide.co.uk. - Data Protection Officer: Miryem Salah. Contact: sales@signafaide.co.uk. ICO registration number: ZC169006. ### 2. Subject matter and nature Receiving, checking, countersigning, storing and making available for export and verification records of decisions made by the Controller's AI agents; optionally storing encrypted record content; showing records to the Controller's members and auditors in the console; sending alerts the Controller configures. The Processor does not run the Controller's AI agents or models and does not assess the decisions recorded. ### 3. Purpose To provide the Service under the terms of service. ### 4. Duration For the term of the agreement and the export and deletion periods in section 10. ### 5. Types of personal data **Hash-only mode (the default).** For each record the Processor receives: - a SHA-256 hash of the record content (not the content itself); - the record envelope: kind (decision, outcome or note), project, environment (test or live), agent name, sequence number, hash of the previous record, time, tool or action name, and the hash of the related decision for an outcome; - the agent's key id and Ed25519 signature; - each agent's Ed25519 public key. Tool and agent names are sent and stored in plain text; the protocol requires that they never hold personal data, and the Controller must not put personal data in them. Each content hash is salted with 16 random bytes that the Controller keeps with the content and sends only with stored content, so the Processor cannot link a hash-only record's content hash to any content, even by trying likely values. If the Controller follows these rules, hash-only records hold no personal data that the Processor can read; whoever holds a record's content and its salt can show that they match its hash. **Stored content (optional, Team plan and above for live records; available in sandboxes).** Any JSON content the Controller chooses to send, typically the inputs and outputs of an agent's tool calls, the model used and the reason given. This may contain any personal data the Controller's agents handle, for example names, contact details, account or transaction details about the Controller's customers, staff or other individuals. **Other Customer Data.** Email addresses for alerts set by the Controller; webhook addresses; replay and experiment results uploaded by the Controller (hash-only by default; recorded and candidate values only for records with stored content). **Special category and criminal offence data.** Not expected. The Controller must not send it in stored content unless agreed in writing. ### 6. Categories of data subjects Individuals whose data appears in the Controller's stored content, which depends on the Controller's use case: for example the Controller's customers, end users, employees, contractors or other individuals affected by its AI agents' decisions. ### 7. Public services that receive no Customer Data - drand (League of Entropy beacon, through `api.drand.sh`, `api2.drand.sh` and `drand.cloudflare.com`): the Processor only reads public randomness. Nothing is sent. - OpenTimestamps calendars (`a.pool.opentimestamps.org`, `b.pool.opentimestamps.org`, `a.pool.eternitywall.com`; proofs upgraded through `alice.btc.calendar.opentimestamps.org`, `bob.btc.calendar.opentimestamps.org`, `finney.calendar.eternitywall.com`, `btc.calendar.catallaxy.com`): receive one SHA-256 hash per anchor, about once an hour, covering the batch hashes of many customers. - Block explorers (`mempool.space`, `blockstream.info`): the Processor requests public block headers of the timestamp ledger by height. Nothing about the Controller is sent. ### 8. Retention - Stored content: one year from receipt, or seven years while the Controller has the retention add-on. - Envelopes, hashes, receipts, batches and anchors: while the Controller's organisation is active, then as in section 10. - Unclaimed sandbox: 30 days from creation. --- ## Annex 2: Technical and organisational measures ### A. Integrity of records - Each record is signed by the Controller's agent key (Ed25519). Agent private keys are generated and kept on the Controller's systems and never sent to the Processor. - Registering an agent key requires proof of possession (a signature by that key). Adding a new key to an agent that already has an active key requires a signature by the active key, unless a developer or admin revokes the active key in the console first. An API key alone cannot add a key to an agent. - Records are chained per agent by hash. The Processor countersigns each batch, and a signed head per agent, with its own Ed25519 service key, so that neither party can forge or edit a record alone. - Batch hashes are combined into a Merkle tree (RFC 6962) about every hour and the anchor hash is timestamped through OpenTimestamps, a public timestamp service; each batch also carries a drand round. Verification packs can be checked with the open-source verifier without the Processor. - When content is stored, the Service checks it matches the record's content hash. - The service key history is published and committed to in each anchor; retired keys stay published so old receipts remain verifiable. ### B. Encryption - Stored content is encrypted at rest with AES-256-GCM. Each organisation (or unclaimed sandbox project) has its own data key. Each record's ciphertext is bound to its record hash as associated data. - Data keys are wrapped by a content master key supplied to the Service through its configuration. The Service refuses to start in production without it. - On Enterprise, the Controller can supply its own content key. The Processor holds it only wrapped by the content master key. Rotating or revoking it destroys the Processor's wrapped copy, after which content encrypted under it can no longer be read. The Processor can decrypt content while the key is active; this is not a hold-your-own-key arrangement. - A daily job deletes stored content older than one year (seven years for an organisation with the retention add-on). - Encryption in transit: HTTPS (TLS) between clients and the Service, and between our edge network and our servers. - Encryption at rest of the database volume and backups: Google Cloud encrypts stored data at rest by default. Stored content is also encrypted by the Service itself, under per-organisation data keys (AES-256-GCM), optionally wrapped by a customer-managed key. ### C. Credentials and secrets - API keys, console sign-in links, session tokens and sandbox claim tokens are stored only as hashes. - Sign-in links expire after 15 minutes and are single use; console sessions expire after 30 days; session cookies are HttpOnly and SameSite=Lax, and Secure on HTTPS. - The service key and content master key are held as secrets in the production environment, not in the code repository, with access limited to the staff who operate the Service. ### D. Access control - Console access by emailed one-time link, GitHub OAuth, or OpenID Connect SSO (Enterprise). An SSO email domain must be proven by a DNS TXT record before SSO signs anyone in, and SSO identities are bound by issuer and subject, not email address. - Role-based access within each organisation: owner, admin, developer and auditor. Auditors are read-only. Setting or revoking a customer content key requires an owner. - Auditor links are read-only, scoped to one project and environment (optionally some agents and a date range), expire, and can be revoked. - Each API key is scoped to one project and one environment (test or live); a signed record cannot be replayed into another project or environment. - Staff access to the operator admin is through Cloudflare Access limited to the company email domain, and the Service verifies the Cloudflare Access token on every admin request. Without that configuration the production Service serves no admin. The admin shows usage analytics and plans; it has no view of stored content. - Staff access to production servers and databases: limited to named AIMETECH engineering staff, each with an individual account. ### E. Logging and monitoring - A console audit log records actions by the Controller's members (for example exports, key and link revocations, member and role changes), visible to the organisation. - An admin audit log records actions by the Processor's staff in the operator admin. - Rejected records and chain conflicts are counted per project and agent; alerts (webhook and email) can be set for chain conflicts and outbox gaps. ### F. Network and application security - Rate limits on sandbox API keys, sign-in requests, exports, sandbox creation and analytics events. Where a limit is per IP address, the address is held in memory only. - Alert webhooks and SSO issuers must be public HTTPS addresses; the Service refuses loopback, private, link-local and cloud metadata addresses and does not follow redirects. Webhook bodies are signed (HMAC-SHA256). - Development mode, which shows sign-in links in responses, only runs on a loopback address. ### G. Resilience - Backups: the database is backed up daily within the UK hosting region, and backups are kept for 30 days. - Availability: the Service runs on Google Cloud's managed infrastructure in the London region and can be restored from backup to a new instance. ### H. Organisational - Staff are bound by confidentiality, access is reviewed when staff join or leave, and security incidents are handled under AIMETECH's incident response procedure. --- ## Annex 3: Sub-processors See /legal/subprocessors (`subprocessors.md`).