Security, by construction.

Overview & posture

Aerandil is the typed operating model that hospitality businesses run on. It holds the data those businesses depend on — guest profiles, reservations, folios and charges, operational records — for multiple tenants on shared infrastructure. This document describes how that data is protected.

Our posture is simple to state and honest about its stage. Aerandil is pre-certification: SOC 2 is in progress, not yet attested. What is not early-stage is the engineering. Every control described below is implemented in the platform today, built into the architecture rather than layered over it. This whitepaper is written to be read by a security reviewer — it distinguishes what is enforced in code from what depends on the production deployment, and it does not claim certifications we do not hold.

• Scope. The Aerandil platform: the ontology kernel — its API and durable store — and the cloud control plane that operates it. Customer-built integrations and the operator's own environment are covered by the shared-responsibility model in §15.
• Audience. Security, compliance, and procurement reviewers evaluating Aerandil as a processor of personal and operational data.
• Entity. Aerandil is a UK limited company, operating under UK GDPR and the Data Protection Act 2018, serving customers across the UK, EU, and US.

Security by construction

Aerandil's security model is a property of its data architecture, not a perimeter around it. The platform is an ontology: every real thing is a typed, versioned object; relationships are typed links; and — critically — state only ever changes through actions.

An action is a named, validated, authorized operation. There is no arbitrary write path into the store: applications, staff tools, and AI agents all change data through the same governed contract. Every accepted action emits an append-only event. Authorization, validation, and a complete audit record are therefore not features bolted onto the system — they are the only way data moves.

• Typed objects. Every record has a declared schema, a monotonic version, an owning tenant, and is soft-deleted rather than destroyed — history is preserved by default.
• Actions as the sole write path. Mutations are named verbs with schemas and authorization scopes. No client holds direct write access to the database; there is no privileged back door that bypasses validation or audit.
• Append-only events. Each committed action writes an immutable event carrying the actor, tenant, timestamp, and correlation id. Events are never updated or deleted after insert.
• Idempotency & concurrency. Create and apply operations accept idempotency keys; updates use optimistic concurrency preconditions — so retries cannot double-apply and concurrent writers cannot silently overwrite one another.

Identity & access

Aerandil authenticates two kinds of caller — machines and people — and issues every request a scoped, short-lived token.

• Machine identity. Service and agent integrations authenticate with OAuth 2.1 client-credentials. Access tokens are signed with EdDSA (Ed25519) — an asymmetric scheme, so verifiers validate tokens against a published public key and never hold signing capability. The signing algorithm is pinned, rejecting both unsigned tokens and HMAC-downgrade attempts.
• Published key set. Public keys are served at a standard JWKS endpoint with key identifiers, enabling zero-downtime key rotation and a verification grace window for tokens already in flight.
• Human identity. Operators authenticate through WorkOS AuthKit, which provides single sign-on and multi-factor authentication under the operator's own policy. Aerandil verifies the resulting session locally and exchanges it for a tenant-scoped platform token, recorded as a distinct user principal.
• Credential protection. Client secrets are stored only as Argon2id hashes with parameters pinned to OWASP guidance, and support overlapping rotation so credentials can be rolled without downtime.
• Principal separation. Machine, delegated-agent, and human callers are distinguishable as separate principal types on every event they produce — the audit trail records not just what changed but which kind of actor changed it.

Authorization & least privilege

Access is governed by a fine-grained scope vector carried on every token. Aerandil issues the narrowest grant that does the job.

• Least privilege. Scopes are granted per integration. Read scopes are separate from write authority, and write authority is itself per-action.
• Writes are scoped actions. There is no blanket write scope. A caller is authorized either for a specific action or, where appropriate, a catch-all apply scope reserved for trusted first-party callers — the two are independent and neither implies the other.
• Privileged operations. Destructive and operator-level capabilities — single-subject erasure and whole-tenant administration — sit behind dedicated privileged scopes that should never be issued to tenant-level credentials.
• Denied-access audit. Authorization failures are recorded, not merely refused, so attempted access outside a credential's grant is visible in the audit trail.
• Mandatory access control. Sensitive fields carry classification markings; a caller sees a classified field only if its credentials carry the matching clearance, and the production read API redacts fields the caller is not cleared for.

Tenant isolation

Aerandil is multi-tenant to the database row. Isolation is enforced in Postgres itself, beneath the application, so an application-layer mistake cannot cross tenant boundaries.

• Forced row-level security. Every tenant-scoped table carries a forced row-level-security policy keyed on the request's tenant context. With no tenant set, the policy returns zero rows — it fails closed, never open.
• Dual-role connections. The application connects under a role that cannot bypass row-level security; migrations and cross-tenant maintenance use a separate administrative role. The two are provisioned distinctly in production.
• Per-transaction scoping. The active tenant is set per statement inside the transaction, so connection pooling cannot leak context between requests, and tenant-covering primary keys keep every row physically attributable to its tenant.
• Defense in depth. Tenant-scoped reads additionally carry an explicit tenant predicate, so isolation holds — and is testable — independent of the row-level-security layer.

Data residency & sovereignty

For customers in the UK, EU, and US, where data lives is a contractual and regulatory requirement, not a preference. Aerandil treats residency as a machine-enforced property of each tenant.

A tenant carries a residency contract — for example, EEA-only, EEA-or-adequate-jurisdiction, or a specific country. Aerandil evaluates that contract against the regions it operates, grounded in the EU Commission's adequacy decisions. The United States is treated as transfer-mechanism territory rather than infrastructure-adequate, reflecting that US adequacy is recipient-specific.

• Enforced at three points. The residency contract is checked when a tenant is placed, again if it is ever relocated, and once more when a regional node boots — a node in the wrong jurisdiction for its tenants refuses to start.
• Relocation without divergence. Moving a tenant between regions runs through a quiesce, export, import, and independent-verification sequence; the origin then refuses further writes so no divergent cross-region copy can form during a move.
• Honest scope. The residency decision logic is implemented and tested in the platform. The physical guarantee that traffic lands in-region is delivered by the production cloud deployment — the network and infrastructure layer — which this document treats as a deployment property rather than a code claim.

Encryption & key management

• In transit. Transport encryption is mandatory in production: the platform refuses to start against a database connection that is not TLS-protected. A single modern TLS stack is used throughout; downgrade is rejected.
• At rest. Data at rest is encrypted by the managed database tier on certified cloud infrastructure, with customer-manageable KMS keys available.
• Key management. Token-signing keys are per-region, rotatable, and published as public keys only. Webhook signing keys rotate through a two-step promote flow. Cryptographic keys for participant dispatch are held in an operator vault and referenced by pointer — no private key material is stored in the data model.

Audit & integrity

Because every change flows through an action, Aerandil produces a complete, immutable record of what happened without any additional instrumentation.

• Immutable event log. The events table is append-only — never updated or deleted after insert — and records the actor, tenant, timestamp, and correlation id for every accepted mutation.
• Signed outbound delivery. Webhook deliveries are HMAC-SHA256 signed in a timestamped, replay-resistant scheme and verified in constant time. Participant-to-participant dispatch uses CloudEvents envelopes with Ed25519 signatures over canonical bytes, a strict replay window, and mutually-authenticated TLS on outbound calls.
• Tamper-evidence. The append-only contract is enforced at the schema level and protected by change-management controls; the log's integrity is a property of the store, not of operational discipline alone.
• Classified-field redaction. Marking-classified field values are redacted from the immutable event log at write time — they never enter the change feed, for any consumer.

Data-subject rights

Aerandil is built to let operators answer data-subject requests directly — including the one most platforms struggle with, the right to be forgotten.

• Right to erasure (Art 17). Erasure is a first-class operation, available per subject and as a whole-tenant decommission. It hard-deletes the subject's records, bypassing ordinary retention floors; the event log is retained as PII-free audit metadata.
• Portability & access (Art 15 / 20). A tenant's data can be exported as a consistent, structured snapshot for portability and access requests.
• Erasure-compatible by design. The immutable event log does not conflict with erasure: classified field values are actively redacted from change-log payloads at write time (marking-driven), so personal values never enter the log to begin with. The posture is 'classified values never enter the log' — enforced in code, not 'erase from an immutable log'.

Data lifecycle & retention

• Retention windows. Records carry per-category retention windows — shorter for personal data, longer where financial-record law requires it.
• Soft-delete. Objects are soft-deleted, not destroyed, preserving history and audit; a scheduled pruner hard-deletes past the retention horizon, cascades to dependent links, and preserves the audit events.
• Operator control. Retention windows can be tuned to the operator's jurisdiction; erasure requests override them on demand.

Software supply chain

Aerandil treats the path from source code to running image as a security boundary in its own right.

• Scanned & inventoried. Every release image is scanned for known vulnerabilities and fails the build on high-severity findings, and ships with a generated software bill of materials.
• Signed & attested. Images are signed with keyless Sigstore signing — no long-lived keys — and carry SLSA build-provenance attestation, so their origin is cryptographically verifiable.
• Pinned & immutable. Every continuous-integration action is pinned by commit hash, cloud credentials are short-lived and federated rather than static, and deployments reference images by immutable digest recorded through an auditable change.
• Admission enforcement. In the production cluster, an admission policy verifies image signatures and provenance and fails closed — this enforcement is a property of the deployed environment.

Observability & incident response

• Distributed tracing. Requests are traced end to end with OpenTelemetry, propagating context across services and regions. The tenant identifier is recorded as a trace attribute; no other personal data enters telemetry.
• Metrics & logs. Around fifty operational metric families and structured, correlated logs give response teams visibility into availability, latency, errors, and background processing.
• Incident response. Correlation identifiers stitch a request across every surface it touches; failed outbound deliveries land in an inspectable dead-letter path. Error monitoring can be enabled per deployment.

Business continuity

• High availability. The database runs multi-availability-zone from day one, with a synchronous standby.
• Backup & recovery. Point-in-time recovery is enabled with a retention window sized to the customer's contract, and restore exercises are run on a recurring basis.
• Graceful operation. Shutdown drains background workers cleanly, so in-flight work is not lost on deploy or failover.

Compliance & frameworks

Aerandil's controls are mapped to the frameworks procurement reviews ask about. Each is labelled by where it genuinely stands.

• SOC 2. In progress. Controls are mapped to the Trust Services Criteria and a Type 1 effort is underway via continuous monitoring. Not yet attested.
• ISO 27001:2022. Technical controls are aligned to Annex A and maintained alongside the code.
• GDPR (UK & EU). UK-home posture under the ICO, with standard contractual clauses and an EU representative as we enter the EU market. A Data Processing Agreement is available.
• US privacy. Aligned to CCPA / CPRA and the broader state landscape, with SOC 2 as the primary procurement signal.
• Inherited infrastructure. The underlying cloud is independently SOC 2 / ISO 27001 certified; physical and datacentre controls are inherited from the provider.

Shared responsibility

Some controls are ours; some are the operator's. We are explicit about the line.

• Aerandil provides. The platform controls in this document: identity, authorization, isolation, residency logic, encryption in transit and at rest, audit, data-subject-rights endpoints, supply-chain integrity, and observability.
• The operator provides. Configuration of their identity tenant including the multi-factor policy; the network perimeter — WAF, DDoS protection, IP controls; least-privilege scoping of the credentials they issue; and forwarding of logs to their retention archive.
• Payment data. Aerandil's data model holds no card numbers by design. Operators integrate a tokenized payment processor, keeping card data out of Aerandil's scope entirely.

Sub-processors

Aerandil uses a small, disclosed set of sub-processors. The current list is maintained and provided to customers, and the Data Processing Agreement governs their use.

• Cloud infrastructure. Amazon Web Services — hosting and the managed database tier.
• Operator identity. WorkOS — single sign-on and multi-factor authentication for operator access.
• Error monitoring. An error-monitoring provider may be enabled per deployment; it is configured to avoid carrying personal data.

Responsible disclosure

We welcome coordinated disclosure of security issues. Report a suspected vulnerability to security@aerandil.com. We will acknowledge your report, keep you informed as we investigate, and credit you once the issue is resolved. We ask that you give us reasonable time to remediate before public disclosure, and that you avoid accessing or modifying data that is not yours during testing.

Roadmap

We list what we are actively building, so the line between shipped and planned is never blurred.

• SOC 2 Type 1. Completing the continuous-monitoring rollout toward attestation.
• Admission-enforcement hardening. Cluster-wide rollout of image-signature admission verification across all environments.

Document control

• Version. 1.0
• Last updated. June 2026
• Status. Public. This is a living document; controls and posture are updated as the platform evolves.
• Contact. security@aerandil.com