Ad Astra Computing builds verifiable infrastructure for the agent economy. Each product leaves an artefact a third party can check. This page sets out, in engineering-led terms, how that evidence intersects with the EU AI Act, GDPR, NIS2, DORA and eIDAS, and what the products do not deliver on their own.
The intent is engineering-led. Cryptographic primitives are useful inputs into a compliance programme. They are not, by themselves, a compliance programme. The matrix below states what each Ad Astra component supplies, what the customer is responsible for and what is on the roadmap rather than shipped today.
Not legal advice. This page describes Ad Astra Computing's compliance posture in engineering terms. It is not legal advice. It does not create a lawyer-client relationship or substitute for a customer's own regulatory assessment. Where a specific obligation is in play, consult qualified counsel in the relevant jurisdiction.
Each product emits a checkable artefact:
@adastracomputing/ink on npm; the spec is in the public repo and may be freely forked.witness.tulpa.network for transparency-log inclusion proofs.The Act requires high-risk AI systems to support automatic event logging over the system lifetime (Article 12), provide instructions for use and transparency (Article 13) and document the system technically (Article 11). Providers retain logs for at least six months under provider control where applicable (Article 19).
INK can provide a cryptographically verifiable logging layer for an Article 12 record-keeping programme: integrity, signature authenticity, sequencing, tamper-evidence and third-party verifiability for agent message events. The same applies to Dispatch's vault replays for coding-agent runs.
INK does not, on its own, define which events must be logged for a given high-risk use case, how those events are presented in a human-readable form, retention or deletion policy, access control, post-market monitoring, language requirements or Annex III sector-specific fields. Those remain the deployer's and provider's responsibility.
Verification of an INK envelope runs in the browser against the canonical bytes and the signer's public key. The Ad Astra homepage demonstrates this. Confirming the cryptographic claim does not require sending the record's contents to Ad Astra. Other personal data (IP, support correspondence, billing, request telemetry) may still be processed in the ordinary course of operating the service; see the privacy policy and subprocessors page.
Ad Astra Computing acts as a controller for data it collects directly: marketing signups, sales enquiries, support correspondence, its own CRM and tulpa user accounts (users sign up with Ad Astra directly, so Ad Astra decides the purpose and means). Ad Astra Computing acts as a processor for customer data handled through the products on the customer's behalf: INK envelopes routed via Ad Astra endpoints and Dispatch customer runs (orchestration state, agent decisions, vault contents). The applicable role determines which GDPR obligations attach to which flow. Customers with mixed workloads should confirm the role for their specific deployment before contracting.
For data processing addendum discussions, write to [email protected].
INK's signed audit trail and tulpa's witness log produce the kind of integrity-bound, third-party-verifiable record that supports evidence collection for incident and ICT-third-party-risk obligations. Sectoral mapping (financial entities under DORA; essential and important entities under NIS2) is on the roadmap; today these tools are components, not turnkey compliance.
eIDAS caution. Ed25519 signatures used by INK are not qualified electronic signatures under Regulation (EU) No 910/2014. They provide cryptographic integrity, not the legal effect of a QES. Customers requiring QES must overlay a qualified trust-service signature; INK does not replace that and never claims to.
| Capability | Status |
|---|---|
| Ed25519 cryptographic message integrity | Supports |
| Per-agent identity (DID-based, not identity proofing or KYC) | Supports |
| Tamper-evident message sequence | Supports |
| Public-witness Merkle log inclusion proofs | Supports (via tulpa-operated witness) |
| Browser-side verification (no record contents to Ad Astra) | Supports |
| Open spec, open reference implementation | Supports (Apache 2.0) |
| Human-readable audit export (CSV / JSON / PDF) | Roadmap |
| Configurable retention policy, legal hold, deletion | Customer must configure |
| Event taxonomy for a specific high-risk use case | Customer must configure |
| EU-region processing option (subject to Cloudflare configuration) | Requires scoped implementation review |
| ISO 27001 certification | Roadmap |
| SOC 2 Type II attestation | Roadmap |
| ISO/IEC 42001 (AI management system) | Roadmap |
| Security whitepaper (key custody, threat model) | Roadmap |
| Model and system cards for Articles 11 / 13 | Roadmap |
| NIS2 / DORA sectoral mapping | Roadmap |
| Qualified electronic signature (eIDAS QES) | Does not provide |
| European Health Data Space (EHDS) alignment | Out of scope today |
Cloudflare Workers, which host the Ad Astra public endpoints and the tulpa.network witness, can be configured to use Cloudflare's EU-region processing option. The default deployment uses Cloudflare's global edge. EU-region configuration is available subject to a scoped implementation review and Cloudflare's own product limits; it is not a default contractual residency commitment.
Today the Ad Astra public endpoints retain D1 audit rows for accepted intents (content hashes only, not raw contents; hashes and accompanying metadata may still be personal data depending on context), Cloudflare-side request telemetry on the normal Cloudflare retention schedule and Resend's standard delivery metadata. Per-customer retention SLAs, legal holds and deletion workflows are not a default capability today and would need to be agreed in writing before deployment. Configurable retention is on the roadmap above.
European procurement enquiries (DPA discussions, subprocessor questions, security questionnaires, regulated-use scoping):
Contract artefacts (data processing addenda, standard contractual clauses where applicable, subprocessor lists, security questionnaire responses) are available on request through the addresses above. Enterprise buyers with a preferred DPA template are welcome to send it as the base for review.
Ad Astra Computing, Inc. is a Delaware corporation. We do not currently operate an EU legal establishment, appoint a GDPR Article 27 representative or appoint an AI Act Article 22 authorised representative. Customers whose procurement, placing-on-market or putting-into-service scenario requires any of these should reach out before contracting.