Security and trust

Aethis is infrastructure for systems that need verifiable decisions, including in regulated environments. The engine has been validated against the published benchmarks (Simpson 2026 §3) and is intended for production use; the developer surfaces around it are in early access while pricing, rate limits, and the published API contract settle. Security and data protection are designed in from the start. Controls are proportionate to current scale and are formalised as the platform matures.

Several properties of the engine are themselves security-relevant.

• —Decisions are evaluated by a constraint solver against a compiled ruleset. No language model runs in the decision path. The set of inputs that affect an outcome is bounded by the ruleset.
• —Rule authoring (LLM-assisted) and rule evaluation (deterministic) are separated. The authoring pipeline runs at build time and produces a compiled artefact; the runtime executes that artefact only.
• —Every decision returns the ruleset and engine version. Reproducing a past decision against a known input is deterministic.
• —Customer rule content is isolated per project and per organisation. API keys are scoped to a project.

• —In transit: TLS 1.2 or higher for all traffic to api.aethis.ai, the dashboard, and sub-processor endpoints.
• —At rest: provider-managed encryption (AES-256 or equivalent) on databases, object storage, and secret stores.
• —Secrets: managed in Google Secret Manager with least-privilege service-account access.

• —Customer authentication is handled by Clerk (passwordless email, OAuth, or password with strength requirements).
• —API access uses scoped, revocable API keys. Keys are issued and rotated through the dashboard.
• —Internal access to production systems is restricted to named staff, gated by SSO and short-lived credentials, and audited.
• —Production access requires approval and is logged.

Customer data is logically isolated by organisation and project at the application layer. Rulesets, fields, tests, and decisions are scoped to the owning project and not accessible across organisations.

Core application data is hosted in the United Kingdom or European Union. Some sub-processors operate in the United States. Where data crosses borders we rely on UK International Data Transfer Agreements, the EU Standard Contractual Clauses, or adequacy regulations. The current list of sub-processors and their regions is at /subprocessors.

Two different things are logged, and it is worth separating them because only one of them can contain what you submitted.

Request logs are always written. They record the timestamp, route, status, latency, API key identifier and ruleset version. They do not contain the values sent with a call. Because calls made from the panel on our home page are proxied by our own server, the address recorded for them is our egress address, not yours.

Decision logs are what would record the values themselves. This is a capability that is off by default in the engine and not enabled on the public production engine, so a call to api.aethis.ai today writes no decision record at all. We are describing it here because it can be enabled — per deployment, as a deliberate change — and because you should know what it would capture before that happens rather than after.

Where decision logging is enabled:

• —An authenticated call records the values supplied to the engine alongside the outcome. If those values exceed 256 KiB the payload is dropped rather than truncated, and the record is flagged, keeping the input hash as the replay handle.
• —An anonymous call to the public endpoint records no submitted values at all — only a decision id, the input hash, the ruleset identity and version, the outcome, timing, and enough shape to be useful: which fields you left blank, which field identifiers failed validation, and per-section results.
• —Records carry a 90-day time-to-live, stamped at write time. Retention is a single engine-wide setting rather than a per-customer one, so a different period means a dedicated deployment, not a contract term on the shared engine.
• —Authentication events and admin actions in the dashboard are recorded separately, and always.

One honest caveat about that input hash. It is deliberately unsalted, because the reproducibility contract requires a caller to be able to recompute it from their own inputs and check that a replay matches. An unsalted hash of a small input space can be reversed by enumeration: anyone with read access to the decision store and a list of plausible values could test which one produces a given hash. So the anonymous guarantee is precisely that raw submitted values are never stored — not that a low-entropy input could never be recovered from its hash. Treat neither path as a place for real personal or confidential data, and use synthetic values in the demo on our home page.

Application databases are backed up daily by the managed provider, with point-in-time recovery available. Compiled rulesets are content-addressed and reproducible from source, so engine state can be reconstructed independently of any single backup.

Report suspected vulnerabilities to security@aethis.ai. Please do not exfiltrate data, run automated scanners against production, or test rate limits. We aim to acknowledge reports within two business days. Researchers acting in good faith and within these guidelines will not be pursued.

Aethis processes personal data in accordance with UK GDPR and the Data Protection Act 2018. SOC 2 Type I and ISO 27001 alignment work is underway; we do not currently claim either certification. A summary of current controls is available to prospective customers under NDA.

• —Treat API keys as secrets; never commit them to source control.
• —Apply your own access controls and audit on top of decision outputs.
• —Keep a human in the loop for high-stakes decisions, as set out in the Acceptable Use Policy.
• —Notify us promptly of any suspected unauthorised access to your account.

Security questions: security@aethis.ai.