> ## Documentation Index
> Fetch the complete documentation index at: https://docs.algovoi.co.uk/llms.txt
> Use this file to discover all available pages before exploring further.

# Security posture

> How AlgoVoi protects merchants, payers, regulators and the audit trail: concrete, independently verifiable claims with no marketing fluff.

This page is written for security teams, procurement reviewers, auditors, and anyone evaluating whether AlgoVoi is safe to put behind their checkout, AI agent, or marketplace. Every claim below is concrete and backed by source-pointer evidence.

For developers, the protocol pages and the [Compliance overview](/compliance) are likely a better starting point.

The **canonical compliance hub** lives at [`algovoi.co.uk/compliance.html`](https://algovoi.co.uk/compliance.html) — status-badge dashboard, regulatory scope table, AML/CTF programme detail, server-by-server security ratings, and the full policy library.

The full Information Security Policy & ICT Risk Management Framework (v2.0, 1,239 lines covering SOC 2 CC1–CC9, DORA Articles 5–11, the Top-15 risk register, 8 incident runbooks, 9 BCP playbooks, and the exception register), together with the Tier B documents (BWRA full text, CDD/EDD full text, RoPA full text, transaction-monitoring rule values, pen-test report when produced, SOC 2 evidence package as it builds), are available for review under signed NDA — [request via `security@algovoi.co.uk`](mailto:security@algovoi.co.uk?subject=DD+Pack+Request).

## At a glance

<CardGroup cols={2}>
  <Card title="Compliance as an enabler" icon="shield-check">
    KYC, KYB, MLRO sign-off, AML monitoring, sanctions screening, and Fernet
    at-rest encryption shipped — not a roadmap. Your CFO signs off, your
    auditor doesn't have to ask twice.
  </Card>

  <Card title="Hash-chained audit log" icon="link">
    Every audit event, sanctions hit, and compliance event is SHA-256
    hash-chained at insert time. Tampering breaks a verifiable property
    detected at export. RFC 8785 canonical JSON.
  </Card>

  <Card title="Object Lock retention" icon="lock">
    Every audit batch is shipped to S3-compatible Object Lock storage in
    COMPLIANCE mode with 7-year retention. Even the bucket owner cannot
    delete or overwrite for the retention period.
  </Card>

  <Card title="Two-key encryption separation" icon="key">
    Special-category personal data (KYB documents) and operational secrets
    (HMAC, OAuth, MFA seeds) are encrypted with separate Fernet keys.
    Production startup refuses to start if the keys are equal.
  </Card>

  <Card title="UK-registered, FCA-aware" icon="building-columns">
    UK Limited operating entity. Information Security Policy aligned to
    UK Money Laundering Regulations 2017, UK GDPR, SAMLA 2018, and the
    DORA / MiCA framework for EU customer expansion.
  </Card>

  <Card title="Cloudflare-only origin" icon="cloud">
    Production hosts enforce a strict allowlist of Cloudflare IP ranges on the
    public interface. Direct-IP bypass attempts drop silently at the
    firewall — no TCP handshake completes from a non-Cloudflare source.
  </Card>
</CardGroup>

## Encryption

### In transit

* **TLS 1.3 everywhere.** All public traffic terminates at Cloudflare with TLS 1.3 enforced. AlgoVoi nginx accepts only TLS 1.3 + 1.2 with modern ciphers.
* **Cloudflare-only origin.** Production hosts enforce a strict Cloudflare IP allowlist via host firewall rules on the public interface: a dedicated chain accepts only Cloudflare's published IPv4 ranges and the private VPC, and drops everything else on the HTTPS/HTTP ports. Direct-IP bypass attempts are dropped silently — no TCP handshake completes.
* **Database TLS.** Postgres on the production database hosts enforces `ssl_min_protocol_version = TLSv1.3` with `ssl_prefer_server_ciphers = on`. Same-host bridge connections continue without TLS for negligible CPU overhead on loopback-equivalent traffic; any non-bridge / non-loopback source MUST use TLS via `hostssl scram-sha-256` with a `hostnossl reject` belt rule against config drift. Self-signed CA (4096-bit RSA) issues per-server certs; CA private key kept offline.
* **Private inter-host routing.** All control-plane / facilitator / KYB-verif / bot traffic between production hosts traverses a private VPC with sub-1ms RTT. No inter-host control traffic crosses the public internet.

### At rest

* **Two-key separation.** Tenant secrets (HMAC keys, OAuth tokens, MFA TOTP seeds, webhook secrets) use one Fernet key. Special-category personal data — KYB documents, beneficial-owner identity scans, KYC selfies — uses a **completely separate** Fernet key. Production validation refuses application startup if the keys are equal or unset.
* **MultiFernet rotation.** Both keys support zero-downtime rotation via a fallback-key slot. Documented procedures in the Information Security Policy.
* **Magic-prefix forward compatibility.** KYB document files on disk carry an `AVK1` 4-byte prefix so the loader can transparently distinguish encrypted files from any legacy plaintext, and so future encryption schemes (AVK2, AVK3) can ship with backward-compatible decryption.
* **Path-traversal hardening.** All file-system access through KYB storage routes through a `_safe_path()` guard that rejects null bytes and any path attempting to escape the documents root.

## Audit trail and tamper-evidence

This is where AlgoVoi differs from every other crypto-payments stack we've seen. **Three layers of defence**, not one.

### Layer 1 — write-once at the database

Three Postgres tables — `audit_log`, `screening_hits`, and `compliance_events` — are protected by Postgres `RULE` directives that block `UPDATE` and `DELETE` at the SQL level. The application can only `INSERT`.

### Layer 2 — cryptographic hash chain

Every row inserted into the three protected tables also stores a `chain_position`, a `content_hash` (SHA-256 of the row's RFC 8785 canonical-JSON content), and a `prev_hash` linking to the previous row's `content_hash`. Genesis row uses `0` × 64. Inserts are serialised by Postgres advisory lock so concurrent writers cannot fork the chain.

Tampering (UPDATE of an inserted row, DELETE of a row, INSERT of a forged row out of band) breaks a verifiable property. We expose three verify endpoints under admin scope:

* `GET /internal/audit-log/verify-chain`
* `GET /internal/compliance/screening-hits/verify-chain`
* `GET /internal/compliance/compliance-events/verify-chain`

Each returns `chain_intact: true|false` plus, if broken, the exact `chain_position` of the break and a human-readable failure reason. SOC 2 auditors and FCA examiners can run these endpoints under audit credentials any time.

### Layer 3 — off-VM Object Lock with COMPLIANCE retention

Every batch of new chained rows is exported as immutable NDJSON to S3-compatible Object Lock storage with `ObjectLockMode=COMPLIANCE` and a 7-year retention period. **Even the bucket owner with full IAM permissions cannot delete or overwrite the object before retention expires.**

The retention period (7 years) is configured per-object at upload and exceeds the UK MLR 2017 Reg 40(3) statutory minimum (5 years) and the FCA SYSC requirement.

A 5-minute reaper sweeps for un-shipped chained rows, batches them, computes the batch SHA-256, and uploads each batch with the position range and SHA encoded into the object key. An external auditor can fetch the NDJSON files, recompute hashes, and reconcile against in-DB rows. If the in-DB rows have been tampered with or even fully deleted, the Object Lock copy is the source of truth.

<Note>
  **What this means for an auditor:** the SOC 2 / FCA evidence ask "demonstrate that audit log entries cannot be tampered with after creation" has a three-layer answer that holds up under technical scrutiny — Postgres RULE, hash chain, off-VM immutable copy. We can demonstrate each layer with a working endpoint or bucket inventory in the auditor's presence.
</Note>

## Sanctions screening (SAMLA 2018, UK MLR 2017, OFAC)

* **Local cache, daily refresh.** Sanctions list data from OFSI (UK), OFAC (US), and the EU consolidated list is refreshed daily into a local Postgres cache. No third-party API call sits on the payment hot path.
* **Indexed lookup, sub-3ms.** `screen_wallet()` performs an indexed `wallet_address_normalised` lookup. Returns hit/clear plus a server-side action (`blocked` / `flagged` / `escalated`).
* **Tipping-off prevention.** Per SAMLA 2018 s.20, the gateway and facilitator only ever receive a boolean hit/clear result. The list source, entity name, and match metadata are confined to the compliance admin namespace and the MLRO review queue.
* **Multiple screening points.** Wallets are screened in real time at challenge issuance and verification, plus at tenant onboarding (KYB approval), plus at risk-tier change, plus by a daily background sweep that catches wallets which became sanctioned after their last screening.
* **Write-once hit records.** `ScreeningHit` rows are protected by the same three-layer audit defence as audit\_log: Postgres RULE, hash chain, Object Lock shipping.

## Access control

### Tenant API authentication

* API keys hashed with **Argon2id** (resistant to GPU brute-force).
* Plaintext returned once at issuance, never persisted.
* Key states: `active`, `grace`, `revoked`, `suspended`. Grace-period rotation supports zero-downtime replacement.
* Per-tenant rate limits enforced at nginx and the application layer.
* Generic `401 Unauthorized` on all auth failure — no internal detail leaks.

### Admin authentication

* Bearer tokens hashed with SHA-256, stored in a database table with O(1) lookup via a key-id alias plus a timing-safe full-hash comparison (`hmac.compare_digest`).
* Token expiry enforced per-key.
* **TOTP MFA mandatory** for the admin dashboard, with a tight clock-drift window.
* Scope-restricted access via a `require_scope()` dependency. Current scopes include `audit:read`, `compliance:read`, `compliance:admin`, `tenants:read`, `tenants:write`, `apikeys:admin`, `payouts:read`, `payouts:write`, `disputes:write`, `kyb:write`, `subscriptions:admin`.
* In-process auth-outcome counters surface authentication health to the operator without an external metrics dependency.

### Webhook signing

* Stripe-style HMAC-SHA256 signing on every outbound webhook delivery.
* Per-destination secret, Fernet-encrypted at rest.
* `X-AlgoVoi-Signature: t={timestamp},v1={sig}` header pattern customers' code can verify in any language.
* Retry queue with 30s → 32h escalating backoff and dead-letter capture (`FOR UPDATE SKIP LOCKED` for multi-replica safety).

## Compliance posture

| Standard                                 | Applicability                               | Status                                                                                                              |
| ---------------------------------------- | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| **UK Money Laundering Regulations 2017** | UK-registered crypto-asset service provider | Compliant: KYC, KYB, sanctions screening, transaction monitoring, MLRO, audit retention                             |
| **UK GDPR / DPA 2018**                   | All UK personal data                        | Lawful bases documented, subject rights operational, DPIA + ROPA scheduled Q3 2026                                  |
| **SAMLA 2018**                           | UK financial sanctions                      | Compliant: tipping-off prevention enforced, OFSI feed daily refresh, write-once hit log                             |
| **DORA (EU 2022/2554)**                  | Applicable on MiCA CASP authorisation       | Information Security Policy v1.0 published 2026-05-03, mapped to DORA Articles 5–11                                 |
| **MiCA (EU 2023/1114)**                  | When EU-resident customers are onboarded    | Authorisation tracked separately; no active solicitation of EU customers prior to authorisation                     |
| **SOC 2 Trust Services Criteria**        | Customer-required for enterprise B2B        | Information Security Policy mapped to CC1–CC9; SOC 2 Type II audit scheduled subject to ≥5 paying-tenants milestone |
| **PCI DSS**                              | Triggered if card data is processed         | Not applicable — AlgoVoi is crypto-only                                                                             |
| **ISO/IEC 27001**                        | Optional certification                      | Roadmap item Q4 2026 if customer demand drives it                                                                   |

## Vulnerability management

* **Patching cadence:** OS critical patches within 7 days, Important within 30. Application dependency patches: confirmed CVEs in our usage path within 7 days, otherwise within 30.
* **Dependency scanning:** GitHub Dependabot enabled across `chopmob-cloud/platform` and `chopmob-cloud/AlgoVoi`. Weekly automated scan, monthly manual review.
* **Pinned versions:** Python and Node dependencies pinned at minor version in `pyproject.toml` / `package.json`.
* **Penetration testing:** annual external pentest scheduled for Q4 2026 alongside the first-paying-tenants milestone. Internal lightweight quarterly OWASP Top 10 + STRIDE walkthrough until then.
* **Software Bill of Materials:** CycloneDX SBOM generated per release tag. First public SBOM ships with this trust page.

## Incident response

* **Classification:** P0 (catastrophic — fund loss, key compromise, sanctions failure) — immediate 24/7 response, founder ack within 15 min. P1 (severe service degradation) — 4h business-day SLA. P2 / P3 — documented business-day SLAs.
* **Regulator notification:** UK ICO within 72 hours for personal-data breaches per UK GDPR Art. 33. NCA SARonline within 30 days statutory for AML implications. Affected data subjects per Art. 34 timing.
* **Customer notification:** Affected tenant(s) within 1 hour of P0/P1 confirmation via email + dashboard banner. Material outage = status-page banner + all-tenant email within 1 hour.
* **Post-incident review:** Within 5 working days for every P0/P1, written timeline + root cause + action items + risk-register update + policy update if controls need strengthening.
* **Per-scenario runbooks:** 8 documented incident runbooks in the Information Security Policy (admin-key compromise, encryption-key compromise, sanctions failure, KYB document leak, VM full host failure, Cloudflare account compromise, audit-log integrity break, smart-contract bug).

## Business continuity and disaster recovery

| Service                      | RPO (data loss)             | RTO (downtime) |
| ---------------------------- | --------------------------- | -------------- |
| Payment processing (gateway) | 0                           | 1 hour         |
| Control plane                | 0                           | 1 hour         |
| Facilitator                  | 0                           | 1 hour         |
| Postgres                     | 24 hours                    | 4 hours        |
| KYB documents                | 24 hours                    | 4 hours        |
| Sanctions cache              | 24 hours                    | 1 hour         |
| Audit log + chain            | 0 (hash chain detects loss) | 4 hours        |

Daily encrypted Postgres dumps + KYB-doc rsync to a secondary VM. Weekly automated restore-test on the secondary. First annual tabletop exercise scheduled 2026-08-03; 9 documented BCP playbooks for specific failure modes.

## Vendor and supplier risk

ICT suppliers in scope are categorised T1 (critical — outage = platform outage, requires SOC 2 report on file), T2 (important), or T3 (routine). Inventory of 13 current suppliers tracked with onboarding date, last review date, next review date, and a documented termination plan for every T1.

T1 suppliers: Vultr (compute + Object Storage), Cloudflare (edge + WAF + DNS + TLS), GitHub (source control). Each has a signed Data Processing Agreement.

## Coordinated vulnerability disclosure

We welcome responsible security research. Contact details and policy live in the standard `security.txt` location:

* **Machine-readable:** [`api.algovoi.co.uk/.well-known/security.txt`](https://api.algovoi.co.uk/.well-known/security.txt)
* **Email:** [`security@algovoi.co.uk`](mailto:security@algovoi.co.uk)
* **PGP key:** Available on request from `security@algovoi.co.uk`. Will be published alongside this page once a stable rotation cadence is established.

When reporting, please include enough detail to reproduce the issue. We commit to acknowledging receipt within 2 business days, providing a triage classification within 5 business days, and a remediation timeline appropriate to severity. We will not pursue legal action against good-faith researchers who follow our coordinated-disclosure policy.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Are you SOC 2 audited?">
    Not yet. **SOC 2 Type I targeted Q2 2027; Type II targeted Q4 2027.** The
    Information Security Policy v2.0 is mapped to SOC 2 Common Criteria CC1–CC9
    today, so the audit is a fieldwork exercise rather than a controls-design
    exercise. The full policy is available for review under signed NDA via
    `security@algovoi.co.uk`.
  </Accordion>

  <Accordion title="Where is data stored?">
    All production data is stored on Vultr Cloud Compute infrastructure in EU /
    US regions. Vultr operates SOC 2 Type II audited datacentres. KYB documents
    and operational secrets are application-layer encrypted before disk write
    using two separate Fernet keys (see Encryption section). Daily encrypted
    backups to a secondary Vultr instance.
  </Accordion>

  <Accordion title="What happens to my data if I close my account?">
    Tenants can request deletion via the dashboard. Deletion routes through
    `gdpr_purge_service` which removes the tenant record and all linked
    operational data. **Exception:** records under AML hold (KYB documents,
    transaction logs, audit log, screening hits) are retained for the
    statutory minimum of 5 years per UK MLR 2017 Reg 40(3), as required by
    law. After the retention period expires, AML-hold records are purged
    automatically.
  </Accordion>

  <Accordion title="Can I get a copy of my data?">
    Yes. Tenants can export their full data record via a GDPR data-export
    request. Currently a manual operator process; self-service export
    endpoint is on the Q3 2026 roadmap.
  </Accordion>

  <Accordion title="Do you have a bug bounty programme?">
    Not yet. We accept coordinated disclosure via [security@algovoi.co.uk](mailto:security@algovoi.co.uk) and
    follow the policy in our security.txt. A formal paid bug bounty is on
    the roadmap once the platform crosses material revenue scale.
  </Accordion>

  <Accordion title="What about smart-contract security?">
    Two on-chain components are in production: the Solana Pay reference-binding
    flow (uses the standard Solana Pay primitive — no custom contract) and the
    xChain LogicSig on Algorand (custom AVM v11 contract at
    `chopmob-cloud/xchain-accounts`, internally peer-reviewed, external audit
    scheduled before xChain expands beyond Algorand mainnet).
  </Accordion>

  <Accordion title="Do you operate any custodial wallets?">
    No. Settlement is direct customer-wallet → merchant-wallet on the public
    blockchain. AlgoVoi never holds, controls, or transmits customer or
    merchant funds. The xChain feature uses a deterministic LogicSig address
    derived from the customer's existing EVM wallet — the customer signs an
    EIP-712 message in their own wallet to authorise each transfer.
  </Accordion>

  <Accordion title="What if you go out of business?">
    The non-custodial model means there are no customer funds at risk if
    AlgoVoi shuts down. KYB documents and audit records remain in
    customer-readable form for the statutory retention period via the off-VM
    Object Lock storage which is independently accessible. Documented
    business-continuity exit plan in the Information Security Policy on
    request.
  </Accordion>
</AccordionGroup>

## Request additional documentation

For procurement, vendor security review, or audit fieldwork:

* [`security@algovoi.co.uk`](mailto:security@algovoi.co.uk?subject=Vendor+Security+Review) — vendor security questionnaires answered within 5 business days
* **Information Security Policy v2.0** (1,239 lines, SOC 2 CC1–CC9, DORA Arts 5–11, full risk register, 8 incident runbooks, 9 BCP playbooks, exception register) — available under signed NDA via [`security@algovoi.co.uk`](mailto:security@algovoi.co.uk?subject=ISP+Request)
* **Tier B documents** (BWRA full text, CDD/EDD full text, RoPA full text, transaction-monitoring rule values, customer risk-scoring matrix full) — available under signed NDA
* Latest annual penetration test report — available on signed NDA once first test completes (Q4 2026)
* Latest SOC 2 report — when published

## External security audit — 2026-05-27

Self-conducted external audit covering all `algovoi.co.uk` subdomains and production VMs. Methodology: TLS probe (OpenSSL), HTTP header inspection, DNS record analysis, port scan from external IP, nginx config review.

### TLS / HTTPS

| Domain                            | Grade | TLS 1.3 | HSTS | Notes                                  |
| --------------------------------- | ----- | ------- | ---- | -------------------------------------- |
| `api.algovoi.co.uk`               | A+    | ✅       | ✅    | Cloudflare edge, HSTS max-age=31536000 |
| `docs.algovoi.co.uk`              | A+    | ✅       | ✅    | Mintlify / Cloudflare                  |
| `algovoi.co.uk`                   | A     | ✅       | ✅    | Marketing site via Cloudflare          |
| `recurr.algovoi.co.uk`            | A+    | ✅       | ✅    | Cloudflare                             |
| `verify.algovoi.co.uk`            | A+    | ✅       | ✅    | Cloudflare termination                 |
| `agent-trust-bench.algovoi.co.uk` | A+    | ✅       | ✅    | Cloudflare termination                 |

### HTTP security headers

| Header                      | `api.algovoi.co.uk` | `verify.algovoi.co.uk` | `algovoi.co.uk` |
| --------------------------- | ------------------- | ---------------------- | --------------- |
| `Strict-Transport-Security` | ✅                   | ✅                      | ✅               |
| `X-Content-Type-Options`    | ✅                   | ✅                      | ✅               |
| `X-Frame-Options`           | ✅                   | ✅                      | ⚠️ missing      |
| `Content-Security-Policy`   | ✅                   | ✅                      | ⚠️ missing      |
| `Referrer-Policy`           | ✅                   | ✅                      | ⚠️ missing      |
| `Permissions-Policy`        | ✅                   | ✅                      | ⚠️ missing      |

**F-3 (LOW):** `algovoi.co.uk` marketing site missing four security headers. No API or user data is exposed on this domain; risk is limited to clickjacking of the marketing page. Fix: Cloudflare Transform Rule or HTML `<meta>` tags.

### Email security (DMARC / SPF / DKIM)

| Record | Current            | Target             | Gap                                        |
| ------ | ------------------ | ------------------ | ------------------------------------------ |
| SPF    | `~all` (soft fail) | `-all` (hard fail) | Allows unauthenticated mail to be accepted |
| DMARC  | `p=none`           | `p=quarantine`     | No enforcement — reports only              |
| DKIM   | ✅ present          | —                  | No gap                                     |

**F-5 (LOW):** SPF in `~all` mode. Upgrade to `-all` once all sending sources are confirmed stable.

**F-6 (LOW):** DMARC at `p=none`. Upgrade path: `p=none` → `p=quarantine` → `p=reject` after reviewing aggregate reports for two weeks.

### Network exposure

Production hosts sit behind Cloudflare. On the public interface only the HTTPS/HTTP ports are open, and they are firewalled to Cloudflare's published IP ranges plus the private VPC — every other source is dropped with no TCP handshake. All application and database service ports are bound to the private VPC only and are not reachable from the public internet; a second, independent firewall layer blocks external access to internal service ports even where a container binds broadly. Two independent firewall layers (host origin allowlist + container-level egress/ingress controls) are persisted across reboots.

Specific host addresses, interface names, port numbers, and VPC ranges are held in the internal infrastructure documentation (available under NDA), not published here.

### Open API surface

`/openapi.json` and `/docs` (Swagger UI) are intentionally public on `api.algovoi.co.uk`. AlgoVoi is a developer-facing payment gateway and the OpenAPI schema is a selling tool, not a secret. All endpoints require tenant API key or admin bearer token; schema disclosure does not grant access.

### Summary

| Finding                                      | Severity | Status                                                                          |
| -------------------------------------------- | -------- | ------------------------------------------------------------------------------- |
| F-3 `algovoi.co.uk` missing security headers | LOW      | **Open** — marketing site only, no user data                                    |
| F-5 SPF `~all` soft fail                     | LOW      | **Open** — upgrade to `-all` before public launch                               |
| F-6 DMARC `p=none`                           | LOW      | **Open** — upgrade to `p=quarantine` after report review                        |
| Internal port exposure                       | —        | **Pass** — internal service ports VPC-only, blocked externally by host firewall |
| TLS, HSTS, API auth                          | —        | **Pass** — no findings                                                          |

*Audit conducted 2026-05-27 by AlgoVoi operator. External probe from non-VPC IP. Next scheduled external pentest: Q4 2026.*

***

## Running the estate on your own infrastructure

Everything on this page describes AlgoVoi's hosted perimeter. If your security review requires the
estate to run inside your own boundary instead, the same evidence machinery ships self-hosted: see
the [regulated-records self-hosting guide](/regulated-records-self-hosting-guide) for the
architecture, and [post-quantum evidence longevity](/post-quantum-evidence-longevity) for how
Falcon-1024 / ML-DSA-65 signing keeps self-hosted audit records verifiable for decades.

***

## Document changelog

| Date               | Change                                                                                                                                                                                                                                                                                                                              |
| ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 2026-05-27         | Cloudflare-only origin enforcement extended across production hosts: host firewall restricts the HTTPS/HTTP ports to Cloudflare IP ranges + private VPC only. External security audit section added.                                                                                                                                |
| 2026-05-03 (rev 3) | Postgres TLS in-transit deployed on the production database hosts. Secondary facilitator + KYB-verif migrated to a UK-region VPC-attached host; inter-host control traffic routes over the private VPC, sub-1ms RTT. KYB sanctions screening pipeline activated end-to-end on the control plane (was a silent no-op pre-migration). |
| 2026-05-03 (rev 2) | Reconciled with the canonical compliance hub at `algovoi.co.uk/compliance.html`. Information Security Policy upgraded to v2.0 (1,239 lines) and reframed as fully-public rather than NDA-tier. Tier B document policy (NDA-only) clarified. SOC 2 dates aligned to public roadmap (Type I Q2 2027, Type II Q4 2027).                |
| 2026-05-03         | Initial publication. Hash-chained audit log and Object Lock shipping marked live. Host firewall enforcement marked live.                                                                                                                                                                                                            |
