Legal
Data Processing Agreement
Last updated: 8 September 2026
This agreement sets out how Ad Astra Computing processes personal data on your behalf when you use AER. It is the agreement required by Article 28 of the General Data Protection Regulation and by its United Kingdom equivalent, and it carries the transfer safeguards for personal data that leaves the European Economic Area or the United Kingdom.
You do not need to negotiate or sign anything to be covered. This agreement takes effect automatically when you accept the Terms of Service, on the same terms for every customer. If your own process needs a countersigned copy, write to legal@adastracomputing.com and we will return one.
How this agreement takes effect
This agreement forms part of the Terms of Service and applies for as long as we process personal data on your behalf. Where it conflicts with the Terms of Service on a question of data protection, this agreement governs. Where it conflicts with the Standard Contractual Clauses described below, those clauses govern.
We may change this agreement to reflect a change in law, a new subprocessor or a change to the service. When a change is material we email every registered account holder before the date it takes effect, in the same way we do for the Terms of Service.
Parties and roles
For the telemetry your agents send to AER, you are the controller and Ad Astra Computing Inc., a Delaware corporation, is the processor. You decide what your agents run, which identifiers you attach to a session and how long records are kept. We hold and process that data to provide the service and for nothing else.
For the account data we collect when you request access, sign in or manage your organisation, Ad Astra Computing is itself the controller. That processing is described in the privacy policy and falls outside this agreement.
Instructions
We process personal data only on your documented instructions, including on transfers to a third country. Your instructions are the Terms of Service, this agreement, the configuration you set in the console or through the API and any further written instruction you give us. We do not use your data to train models, and we do not use it for our own purposes.
If we consider an instruction to infringe data protection law, we will tell you immediately and may suspend that instruction until it is resolved. Where a law we are subject to requires us to process your data beyond your instructions, we will inform you of that legal requirement first unless the law itself forbids the notice on important grounds of public interest.
Confidentiality
Everyone we authorise to process your personal data is bound by a duty of confidentiality that survives the end of their engagement, and access is limited to the people who need it to operate or support the service.
Security of processing
We implement the technical and organisational measures set out in Annex II, which are appropriate to the risk given that AER records metadata rather than content. We review those measures as the service changes. Because Annex II is published, we will not weaken a measure without updating this page.
Subprocessors
You give us a general authorisation to engage the subprocessors listed in Annex III. Before we add or replace one we update that list and, for customers who have asked for notice by email, send it at least 30 days in advance. If you reasonably object on data protection grounds within that period we will work with you on an alternative, and if there is none you may terminate the affected part of the service without penalty for the unused term.
Each subprocessor is bound by written terms no less protective than this agreement. We remain fully liable to you for a subprocessor's performance of its data protection obligations.
Assisting you with data subject rights
The service is built so that you can answer most requests yourself. The API returns every session, event and record held for your tenant, exports them in open formats, and deletes them on demand or through the retention window you set. Where a request still needs us, we assist you by appropriate technical and organisational measures, taking into account the nature of the processing.
If a data subject contacts us directly about data we hold for you, we will not respond on the substance. We will forward the request to you without undue delay and tell the data subject that we have done so.
Breaches, impact assessments and prior consultation
If we become aware of a personal data breach affecting your data we will notify you without undue delay and in any case within 48 hours. The notice will describe the nature of the breach, the categories and approximate number of records concerned, the likely consequences and the measures we have taken or propose to take. Where we cannot provide all of it at once we will provide it in phases as the investigation develops, rather than delay the first notice.
We assist you with data protection impact assessments and with prior consultation of a supervisory authority, taking into account the information available to us. Annex I and Annex II are written to cover most of what such an assessment asks for.
Deletion and return
At any time during the term you can export your data through the API and delete it through the console, the API or the retention setting. When the service ends we delete the personal data we process for you within 30 days, including from our subprocessors, unless a law we are subject to requires us to keep it. We retain a minimal metadata row for each deleted record, holding its identifier, hash and timestamps, so that a later verification request fails clearly rather than ambiguously.
One limit is inherent in how AER works and we state it in the contract rather than in a footnote. Record hashes and signatures are anchored to a public append-only transparency log that nobody controls, so a hash already anchored to Rekor cannot be deleted, by us or by anyone. No event content, and no personal data, is ever sent to that log. If your assessment is that anchoring does not suit your data, anchoring can be turned off for your tenant in settings before records are created.
Audits and information
We make available the information you need to demonstrate compliance with Article 28 and we allow for and contribute to audits. In practice this means we answer a written security questionnaire within 30 days, and we provide the documentation behind Annex II on request.
You may also audit us directly, once in any twelve month period, on 30 days written notice, during business hours and under confidentiality, and more often if a supervisory authority requires it or if we have notified you of a breach. You bear your own costs. We will say plainly that AER does not hold a SOC 2 or ISO 27001 certificate today, so an audit means reading our controls and asking us questions rather than reading an auditor's report.
International transfers
Ad Astra Computing is established in the United States and the service runs on a global network, so personal data you send to AER is transferred outside the European Economic Area and the United Kingdom.
For transfers from the European Economic Area we enter into the Standard Contractual Clauses approved by the European Commission in Implementing Decision (EU) 2021/914. They are incorporated into this agreement by reference and take effect on the same event that brings this agreement into force, which the parties treat as their signature of those clauses. The selections that the clauses leave open are completed as follows.
| Clause | Selection |
|---|---|
| Module in operation | Module Two, controller to processor. You are the data exporter and Ad Astra Computing is the data importer |
| Clause 7, docking | Included, so a further party may accede to the clauses |
| Clause 9, subprocessors | Option 2, general written authorisation, with 30 days notice of a new subprocessor |
| Clause 11, redress | The optional independent dispute resolution body is not selected |
| Clause 17, governing law | The law of Ireland |
| Clause 18(b), forum | The courts of Ireland |
| Annexes | Annex I, Annex II and Annex III of this agreement serve as the annexes to the clauses |
For transfers from the United Kingdom the clauses above apply as amended by the International Data Transfer Addendum issued by the Information Commissioner under section 119A of the Data Protection Act 2018, version B1.0. Its tables are completed as follows.
| Table | Entry |
|---|---|
| Table 1, parties | The exporter and importer named in Annex I.A. The start date is the date you accepted the Terms of Service |
| Table 2, selected clauses | The clauses above, as completed by the SCC selections table |
| Table 3, appendix information | Annex I, Annex II and Annex III of this agreement |
| Table 4, ending the addendum | Either party may end the addendum under section 19 if the Information Commissioner issues a revised approved addendum |
For transfers from Switzerland the clauses apply with the Federal Data Protection and Information Commissioner as the competent authority, with references to the GDPR read as references to the Swiss Federal Act on Data Protection, and with the clauses protecting the data of legal entities as well as individuals.
If a court or authority invalidates a mechanism above, we will adopt a valid replacement without asking you to renegotiate. If a public authority demands access to a customer's personal data we will challenge the demand where there is a reasonable basis, disclose only the minimum the order compels and notify you unless the law forbids it, in which case we will seek a waiver of that prohibition.
United States state privacy laws
Where you are subject to a United States state privacy law, we act as your service provider or processor under that law. We do not sell your personal data, we do not share it for cross-context behavioural advertising, and we do not retain, use or disclose it for any purpose other than providing the service under this agreement. We certify that we understand these restrictions and will comply with them.
Liability
The limitations of liability in the Terms of Service apply to claims between us under this agreement. They do not apply to a data subject's rights under the Standard Contractual Clauses, which cannot be limited by contract, and they do not limit any liability that applicable law does not permit us to limit.
Annex I. Description of the processing
A. Parties
The data exporter is the customer, being the organisation or person that accepted the Terms of Service, acting as controller. Its identity and contact details are those held in its AER account, and its activity is the use of AI agents in the course of its own business. The data importer is Ad Astra Computing Inc., a Delaware corporation, with a notice address at 1111B S Governors Ave # 41847, Dover, DE 19904, United States, acting as processor. Its contact point is privacy@adastracomputing.com and its activity is operating AER.
B. Description of the transfer
Categories of data subject. The customer's authorised users of the console and the API, and any individual identified by a principal identifier the customer chooses to attach to an agent session, such as the employee or end user on whose behalf an agent acted.
Categories of personal data. For authorised users, name, work email address, organisation, hashed authentication credentials, second factor enrolment, session and audit records and the internet protocol address and browser user agent recorded for abuse prevention. For agent telemetry, the identifiers, kinds and display names of principals the customer attaches, agent and environment identifiers, session tags, model names, token counts, tool names, hostnames, file paths, process executable names and timestamps. Personal data reaches AER through agent telemetry only where the customer puts it in one of those fields.
Data the service does not receive. The collector never captures prompts, model completions, tool arguments or request and response bodies or headers, and the ingest path rejects payload fields outside a fixed allowlist. Special categories of personal data are not processed, and the customer must not submit them.
Frequency. Continuous, for as long as the customer's agents run.
Nature and purpose. Recording agent execution metadata, assembling it into a canonical record, signing that record, anchoring its hash to a public transparency log, detecting deviation from a trained baseline, and making the record available to the customer and to the third parties the customer chooses.
Retention. Until the customer deletes the data or the retention window it sets expires, and in any case no longer than 30 days after the service ends. Anchored hashes are permanent, as set out above.
Subprocessors. As listed in Annex III, for the duration of the service and for the purposes stated there.
C. Competent supervisory authority
Where the customer is established in a member state of the European Economic Area, the supervisory authority of that member state. Where the customer is not established in the European Economic Area but falls within Article 3(2) of the GDPR, the supervisory authority of the member state in which its Article 27 representative is established. For transfers from the United Kingdom, the Information Commissioner's Office.
Annex II. Technical and organisational measures
These are the measures in force today. They are described in more detail on the security page.
| Area | Measure |
|---|---|
| Encryption in transit and at rest | All API and console traffic runs over TLS. Data at rest is encrypted by the underlying Cloudflare storage services (D1, Durable Objects and R2). |
| Pseudonymisation and data minimisation | The collector records metadata only. Prompts, model completions, tool arguments and request and response bodies are never captured, and the ingest path strips unrecognised payload fields against an allowlist, so content cannot reach storage even when a client sends more than it should. |
| Credential handling | API keys are shown once at creation and stored only as an Argon2id hash, so a leaked key is revoked and replaced rather than recovered. Console accounts support TOTP two-factor authentication, and sensitive operations require a fresh reauthentication before they proceed. |
| Access control and tenancy | Every read and write that touches customer data carries a tenant scope enforced in application code, and an automated test suite exercises isolation across tenants. API keys carry a role of read, write or admin, so a key can be issued with the narrowest access that does the job. The operator console sits behind Cloudflare Access, an admin key and a second factor. |
| Integrity | Each completed record is canonicalised, hashed with SHA-256 and signed with an Ed25519 key. The hash and signature are anchored to a public append-only transparency log. The tenant audit trail is a hash chain, and a customer can verify it at any time through the API. |
| Availability and resilience | The service runs on the Cloudflare global network with a replicated primary database. Per-tenant rate limits protect the service from a single noisy client. Health and readiness endpoints are exposed for monitoring and incidents are published at aer.run/status. |
| Logging and detection | Tenant-visible audit logging covers credential, webhook and configuration changes. Failed authentication is counted and exposed to operators. Webhook targets must use HTTPS and deliveries are signed with a rotatable HMAC secret. |
| Secure development | Changes are reviewed and covered by an automated test suite that runs before deploy. Dependency updates are tracked and applied. A vulnerability disclosure process is published at aer.run/security with a three business day acknowledgement target. |
| Deletion | A tenant-configurable retention window from 1 to 3650 days expires record content automatically. An operator erasure path soft-deletes a tenant immediately and purges its data after a short grace period. |
Annex III. Subprocessors
The authorised subprocessors are those listed on the subprocessors page, which is incorporated into this agreement and is the single place that list is maintained. It records each provider, the entity and location, the purpose and the data in scope, and it distinguishes providers that process personal data from transparency services that receive only a hash and a signature.
Contact
For a countersigned copy, a security questionnaire or anything else in this agreement, write to legal@adastracomputing.com. For a data protection request, write to privacy@adastracomputing.com. To report a vulnerability, write to security@adastracomputing.com.