Smartflow 1.8 · Sovereign

The compliance fabric for regulated AI

EU AI Act Conformity Console · WORM-backed audit archive · RFC 3161 trusted timestamps · AI Bill of Materials · MCP Trust Registry · National AI Inventory · Pre-Bind Insurance Compliance Engine. Built specifically for organisations that must answer to a regulator — and for the regulators themselves.

EU AI Act Sovereign Tamper-evident Independent verifier Pre-bind insurance Cosign-signed

Why this release is critical for EU companies

The EU AI Act's high-risk obligations land 2 August 2026. Sovereign is the only AI gateway that ships, in a single product, every artifact a national supervisor will ask for: an Article-by-article Conformity Console, immutable WORM-archived logs with eIDAS-grade RFC 3161 timestamps, a signed AI Bill of Materials per Annex IV, real-time Article 79 incident pre-filing, and an open-source verifier the regulator can run themselves. Deployers, providers, and supervisors all use the same platform — there is no second tool to buy and no second integration to land.

Release Summary
#FeatureCategoryWho it's for
1EU AI Act Conformity Console — read-only regulator view mapping every existing log onto Articles 9–17, 26, 79New FeatureEU deployers · Notified bodies · Supervisors
2WORM Audit Archive Connectors — S3 Object Lock · Azure immutable blob · GCS Bucket Lock · NetApp SnapLockNew FeatureEvery regulated industry
3RFC 3161 Trusted Timestamps — every chain block externally signed by an eIDAS-qualified TSANew FeatureEU + legal-grade evidentiary contexts
4AI Bill of Materials — signed per-tenant inventory of every model, prompt, RAG corpus, MCP tool, policy, IdPNew FeatureAnnex IV §1–2 conformity · NTIA / CISA AI-BOM
5MCP Trust Registry — federated registry with Sigstore / SLSA provenance + per-tenant approvalNew FeatureEvery CISO managing MCP exposure
6Independent Audit Verifier — open-source standalone Rust binary that any regulator can runOpen SourceSupervisors · Auditors · Notified bodies
7Single Pane of Glass — one live SSE feed for Shield, NIPR, ID.me, Maestro, Retrospector and chain sealsNew FeatureSOC · Compliance leadership · Sales briefings
8Closed-loop Retrospector → GRC — ServiceNow · RSA Archer · MetricStream · OneTrust · webhookNew FeatureEnterprise GRC programs
9Aperion Sovereign Supervisor Platform — National AI Inventory, Article 79 pipeline, k-anonymous cross-carrier benchmarking, confidential-compute attestationSovereignNational + EU supervisors
10FedRAMP / IL5 / GAIA-X deployment variants — opinionated, regulator-grade Compose overlaysSovereignGovernment · Defence · EU sovereign cloud
11Pre-Bind Insurance Compliance Engine — NAIC Suitability Model 275 · IDD POG · SEC Reg BI · EU SFDRInsuranceCarriers · Producers · Insurance supervisors
12Private Registry & Cosign-Signed Imagesregistry.aperion.ai with token-auth, per-tenant pull creds, every tag cosign-signedNew FeatureEvery customer · Annex IV §1(b) provenance · NIS2 supply chain
Regulator-Grade Evidence
1
EU AI Act Conformity Console ★ Headline Feature
New Feature

A read-only regulator dashboard that maps every event Smartflow already emits onto the specific articles a supervisor reads first. Open it in front of an examiner and walk Article 9 (risk management) through Article 79 (serious incidents) without leaving the page.

For each article the console exposes (a) a one-line obligation summary, (b) the Smartflow components that produce evidence, (c) regulator-runnable endpoints they can hit themselves, and (d) honestly-disclosed gaps. Every article is colour-coded Present, Partial — gaps disclosed, or Not implemented, and the page returns an overall legal-admissibility score.

The same data is available as JSON at GET /api/conformity/summary, GET /api/conformity/articles/{id}, and GET /api/conformity/incidents, so the supervisor can pull it programmatically into their own SupTech tooling.

EU AI ActAperion evidence source
Art. 9Risk management
Art. 9guardrail_policy · Maestro · verified_identity · shield rule packs
Art. 10compliance_detector · AIDA agent credentials · information_barrier matrix
Art. 11 + Annex IVexamination_suite · ai_inventory · AI-BOM
Art. 12vas per-request log · audit_chain · audit-verifier · WORM archive · RFC 3161 timestamps
Art. 13Maestro response patches · group banners · Shield / NIPR response headers
Art. 14shield approval queue · nipr · compliance_retrospector findings
Art. 15ai_analyzer · ab_testing · alerting · shield
Art. 17compliance_retrospector 5-pass program · examination_suite · alerting
Art. 26verified_identity · vas user_id / groups · audit_chain
Art. 79audit_chain Critical events · sovereign incident pipeline · pre-filed report templates
EU criticality

This is the document a notified body asks for first. Aperion auto-produces it, signs it, and archives it. No more "we'll get our consultants to write the Annex IV technical documentation" — it's continuously generated.

2
WORM Audit Archive Connectors
New Feature

The tamper-evident chain now lands automatically in genuine immutable storage — not in a TTL'd cache. Four connectors ship in 1.8, all behind the same trait so a deployment can fan out to multiple backends for redundancy:

  • AWS S3 Object Lock — COMPLIANCE mode, 7-year retention default. Cannot be deleted by the writer's own account.
  • Azure Blob Storage — immutable storage policies, time-based or legal-hold.
  • Google Cloud Storage — Bucket Lock retention policies.
  • NetApp SnapLock Compliance — for on-prem and air-gapped deployments. Written and closed files cannot be modified within the retention window.

Every successful archive returns a signed receipt that proves which seq range was archived where and when. Receipts themselves are chained back into the audit log so an attacker cannot remove the evidence that an archive operation happened.

EU criticality

Article 12 logs require legal-grade retention. WORM is the difference between detective evidence (we'd notice tampering) and preventive evidence (the chain physically cannot be tampered with). EU national supervisors will increasingly insist on this distinction.

3
RFC 3161 Trusted Timestamp on every chain block
New Feature

The HMAC chain proves authenticity and order. RFC 3161 adds the third leg: time. Each chain block's SHA-256 digest is sent to a Trusted Timestamp Authority, which returns a signed token containing the hash plus UTC time. The token rides alongside the chain block forever.

Sovereign ships recipes for DigiCert Trust Lifecycle Manager, GlobalSign, Sectigo, and the open-source FreeTSA, plus a runbook for running an internal HSM-backed TSA in air-gapped sites. EU deployments use the operator's choice of eIDAS-qualified TSA (Bundesdruckerei, Sectigo Qualified, etc).

EU criticality

Under eIDAS, a record signed with a qualified TSA token is admissible in court without further proof of time. This is the exact bar EU commercial litigation and supervisory enforcement demand. Aperion is the only AI gateway that ships this productized.

4
AI Bill of Materials — signed per-tenant inventory
New Feature

Every tenant gets a continuously-refreshed, signed JSON inventory of every component the gateway sees in active use: foundation models, fine-tunes, prompt templates, RAG corpora, MCP tools, policies, and identity providers. Each component is content-hashed so the AI-BOM is reproducible — two snapshots taken at different times have identical entries when nothing changed.

Maps directly to EU AI Act Annex IV §1(b–c) (components and tools used) and §2(a–b) (data and data governance), and to NTIA + CISA AI-BOM guidance.

GET
/api/aibom?tenant=X
Signed AI-BOM for a tenant — JSON, stable hash per component
GET
/api/aibom/components
Flat unsigned list — ideal for diffing two days side-by-side
EU criticality

No competitor productizes this. Every EU AI Act provider obligation that asks "what is in the system" is answered by one signed JSON document.

5
MCP Trust Registry — federated provenance + per-tenant approval
New Feature

MCP supply-chain risk is now the dominant story in MCP security. Sovereign answers it with a federated registry: every server has a global trust status (Trusted, Quarantined, Untrusted), one or more provenance claims (Sigstore signature with Rekor log index, SLSA build attestation, GitHub native attestation, or in-house CI signature), and a per-tenant approval state. A tenant must explicitly approve a globally-trusted server before its agents can call it. Quarantined servers warn but allow; untrusted servers block.

GET
/api/mcp/trust
List global registry entries
POST
/api/mcp/trust/{id}/approve
Tenant approval (per-tenant overlay)
POST
/api/mcp/trust/{id}/revoke
Tenant revocation
POST
/api/mcp/trust/{id}/evaluate
Preview the decision a call would receive
Closes

"Could the agent be tricked into calling a malicious MCP server?" — answered at the gateway, before the call leaves the proxy.

6
Independent Audit Verifier — open source
Open Source

A standalone Rust binary, MIT-licensed, that any regulator or auditor can build from source on a clean machine and use to independently validate an Aperion chain export. Zero Smartflow dependencies. Reads JSONL or JSON-array exports, recomputes every HMAC and every prev_hash linkage, and prints a clean / tampered verdict with the offending sequence numbers when the chain has been mutated.

Three subcommands: verify (whole chain), canonical (print the exact bytes that were HMAC'd for one entry, so the regulator can reproduce a signature with openssl dgst -mac HMAC), and fingerprint (algorithm + version self-attestation).

Closes

"Symmetric HMAC means weak third-party evidence" — verifier is regulator-runnable, build-from-source reproducible, and version-fingerprinted.

7
Single Pane of Glass — combined live SSE feed
New Feature

One demo URL that shows Shield decisions, NIPR decisions, ID.me identity events, Maestro policy hits, Retrospector findings, and audit chain seq numbers tickering live in two synchronised lanes — pre-flight enforcement on the left, post-decision evidence on the right. Auto-reconnects, runs in demo mode for showroom use, and exposes a snapshot endpoint so a late viewer sees cumulative totals immediately.

GET
/api/spog/stream
SSE: every actionable event in real time
GET
/api/spog/snapshot
JSON: cumulative counters since process start
8
Closed-loop Retrospector → GRC
Integration

Retrospector findings now flow directly into the system the customer's compliance team actually runs in. Five connectors ship: ServiceNow GRC (full REST), RSA Archer (full REST), MetricStream, OneTrust, and a generic webhook for anything else. Closure callbacks come back via POST /api/grc/callback/{vendor} and feed Maestro policy hints so similar findings can be auto-routed in future.

Aperion Sovereign — National Supervisor Platform
9
Aperion Sovereign — for the regulators themselves ★ Sovereign Headline
Sovereign

A separate deployment topology and product SKU built for national and EU-level supervisors rather than for individual carriers. Sovereign sits above tenant Aperion deployments, sees only the metadata it needs to supervise the regulated population, and never holds raw tenant data.

What it gives a supervisor:

  • National AI Inventory — every regulated AI system in the country, registered through gateway adoption. Maps to AI Act Art. 49 (registration) + Art. 71 (deployer registration).
  • Real-time Article 79 incident pipeline — every Critical-severity event across the regulated population pre-fills an incident report. Statutory deadlines (immediate / 48 h / 15 days) tracked automatically. Overdue filings surface to the dashboard.
  • Cross-carrier benchmarking with k-anonymity ≥ 5 — a supervisor can compare carriers ("median carrier blocks 0.4% of bind_policy attempts; you block 0.9%") without seeing carrier-level data. Buckets with fewer than 5 carriers are suppressed.
  • Confidential-compute attestation surface — Intel TDX / AMD SEV-SNP / AWS Nitro / Azure CVM. The supervisor pins the workload measurement and rejects any quote whose hash does not match.
GET
/api/sovereign/inventory
National AI inventory; filterable by Member State
GET
/api/sovereign/incidents
Open + overdue Article 79 incidents
POST
/api/sovereign/benchmarks
k-anonymous percentile report builder
GET
/api/sovereign/health
Supervisor health + attestation envelope
EU criticality

This is the answer to "how could one Member State actually operate AI Act supervision at scale?". Aperion Sovereign is the SupTech reference architecture for EIOPA, BaFin, AFM, ACPR, IVASS, and the EU AI Act regulatory sandboxes that every Member State must establish by August 2026.

10
Sovereign deployment variants — FedRAMP High · DoD IL5 · EU GAIA-X
Sovereign

Productized, opinionated deployment overlays for regulator-grade hosting:

  • FedRAMP High — FIPS 140-3 crypto, AWS GovCloud S3 Object Lock, FedRAMP-authorised TSA, full posture map of every control family to a Smartflow capability.
  • DoD IL5 — inherits FedRAMP High and adds DoD CAC authentication, per-tenant HSM partitions (Thales Luna SA), classified-network isolation, and pinned mTLS to the DoD CA chain.
  • EU GAIA-X — EU-only data residency, eIDAS-qualified TSA (Bundesdruckerei, Sectigo Qualified), GAIA-X self-description manifest, Article 12 logging + Article 79 incident pipeline live by default.

Every variant is a single docker compose up -d on top of the standard safechat-enterprise:latest image. What changes is configuration, not the binary surface — so the same code is auditable across all regimes.

Pre-Bind Insurance Compliance Engine
11
NAIC Suitability Model 275 · IDD POG · SEC Reg BI · EU SFDR
Insurance

NIPR (1.7) answered "is this producer licensed?". Sovereign's Pre-Bind Engine answers everything else a conduct regulator asks before binding — across four regimes that an insurance carrier must respect simultaneously when distributing globally:

  • NAIC Suitability in Annuity Transactions Model #275 — best-interest standard, suitability information completeness (age, income, objective, risk tolerance, liquidity needs), insurance-agent disclosure delivery, senior-low-liquidity deferred-annuity escalation.
  • IDD Demands & Needs + POG (EU 27 Member States) — Article 20(1) demands and needs specification, Product Oversight & Governance target-market alignment.
  • SEC Reg BI — Form CRS delivery for retail investors crossing into securities (variable annuity / variable life), Care Obligation inputs, supervisor-approval escalation when missing.
  • EU SFDR — Article 8 / Article 9 product alignment with the consumer's expressed sustainability preferences. Asks for an Art. 9 product but recommended Art. 8? Block.

Same tiered-severity model as Shield and NIPR (Critical = Block · High = Approval · Medium = Warn · Low = Audit). The strictest decision across the enabled regimes wins. Every regime has its own enforcement toggle so a carrier can dogfood in audit-only mode before flipping each one to enforce.

POST
/api/prebind/evaluate
Dry-run a binding before sending it through the proxy seam
EU criticality

IDD and SFDR are mandatory in every EU Member State. SFDR Article 9 misalignment is a fast track to enforcement at AFM, BaFin, ACPR, and IVASS — and no AI gateway except Aperion checks it pre-bind. Combined with NIPR, this makes Aperion the de-facto compliance gate for EU insurance distribution AI.

Software Supply Chain
12
Private Registry & Cosign-Signed Images
New Feature

Starting with 1.8, all Aperion runtime images live in registry.aperion.ai — a private Docker registry tied directly to the Aperion licensing dashboard. Every customer receives one or more scoped, revocable pull credentials; there is no public anonymous pull path. Per-tenant credentials are minted and revoked from the licensing dashboard so an operator can rotate a key without going through Support.

Every image, every tag, is signed at push time with a long-lived cosign keypair. The Aperion public key is published openly at https://docs.aperion.ai/cosign.pub so anyone — your build pipeline, your CISO, your auditor, a regulator — can independently prove that the binary they are about to run was signed by Aperion and has not been tampered with in transit.

  • Authentication — token-auth (Docker Registry v2 spec) issued by the Aperion licensing service. Tokens are short-lived (15 min); credentials behind them are bcrypt-hashed at rest.
  • Authorization — per-credential scope (pull or pull,push); only the Aperion build server holds push credentials.
  • Signingcosign sign on every push; signatures stored alongside the image in the registry under aperion/<image>/sha256-<digest>.sig.
  • Verification — single cosign verify --key command before deployment; suitable for use as an admission-controller policy in Kubernetes (Sigstore Policy Controller, Kyverno, or Gatekeeper).
  • Revocation — instant from the licensing dashboard. Pulls already in flight against the revoked credential start failing on the next 15-minute token refresh.
EU criticality

Maps directly to EU AI Act Annex IV §1(b) (provenance of components used) and NIS2 Article 21(2)(d) (supply-chain security of network and information systems). With cosign verification in your CI/CD admission policy, "did this binary come from Aperion?" becomes a deterministic yes/no — not a Slack thread.

 Full image-verification guide →   (cosign quickstart, K8s admission policies, CI snippets, regulator handoff)

Upgrading to 1.8
Upgrade Notes

Image access — Aperion 1.8 runtime images are gated behind the Aperion private registry at registry.aperion.ai. Existing customers should contact Aperion Support to be issued a per-tenant pull credential. Each credential is scoped, revocable, and tied to your license record.

Pull workflow:

docker login registry.aperion.ai -u <your-issued-username>
docker pull registry.aperion.ai/aperion/safechat-enterprise:v1.8.0
docker pull registry.aperion.ai/aperion/safechat:v1.8.0
docker pull registry.aperion.ai/aperion/safechat-dashboard:v1.8.0

Verifying authenticity with cosign — every Aperion image is signed at push time with a long-lived cosign keypair. The public key is published at https://docs.aperion.ai/cosign.pub. Verifying before deployment is one command:

curl -sSL https://docs.aperion.ai/cosign.pub -o /tmp/aperion-cosign.pub
cosign verify --key /tmp/aperion-cosign.pub \\
  registry.aperion.ai/aperion/safechat-enterprise:v1.8.0

A successful verification proves (a) the manifest digest you are about to run was signed by Aperion, and (b) it has not been altered since signing. This pairs directly with the open-source audit verifier — together they give your auditor end-to-end provenance from build server to running container to chain block.

 Full guide, including Kubernetes admission-controller policies for Sigstore Policy Controller, Kyverno, and OPA Gatekeeper, plus CI snippets for GitHub Actions, GitLab CI, Jenkins, and Argo CD: Verifying Aperion Images →

EU AI Act activation — once the new image is in place, set the following in your proxy environment:

TSA_URL=https://timestamp.digicert.com           # or your eIDAS TSA
WORM_S3_BUCKET=acme-aperion-worm-prod             # 7-year retention recommended
MCP_TRUST_REGISTRY_PATH=/etc/smartflow/mcp-trust.yaml
SF_CONFORMITY_ADMIN_KEY=...                       # bearer for /api/conformity/*
SF_AIBOM_ADMIN_KEY=...                            # bearer for /api/aibom
SF_MCP_TRUST_ADMIN_KEY=...                        # bearer for /api/mcp/trust*
SF_GRC_ADMIN_KEY=...                              # bearer for /api/grc/*
SF_SOVEREIGN_ADMIN_KEY=...                        # bearer for /api/sovereign/* (supervisor only)

Sovereign deployment — pick a variant in deploy/sovereign/{fedramp,il5,gaia-x}/ and follow the variant-specific runbook supplied by Aperion Support.

Audit Verifier (open source) — clone tools/audit-verifier/, run cargo build --release, and ship the binary to your auditor or regulator. This component is intentionally MIT-licensed and dependency-free so any third party can build it from source on a clean machine.

No database migrations. The audit chain remains backwards compatible; older entries verify the same way; new entries add tsa_token_b64 and (when archived) WORM receipt fields.