Zero-Scope Financial Security.
Processing payments shouldn't put your entire engineering infrastructure at risk. Aeion OS employs a zero-trust PCI-DSS architecture. Through advanced tokenization, mandatory TLS 1.3 network enforcement, and real-time audio scrubbing of PAN and CVV data, Aeion OS keeps your core servers completely out of the Cardholder Data Environment (CDE).
The PCI-DSS Defense-in-Depth
Client-Side Tokenization
Aeion completely rejects routing raw credit card numbers through its API. We utilize secure, client-side iframes (via Stripe or Accept.js) to tokenize PANs directly in the user's browser. The Aeion backend only ever stores and transmits the opaque cryptographic token, mathematically removing the OS from PCI-DSS Level 1 scope.
Real-Time PAN/CVV Redaction
In live retail support or telehealth sessions, customers often read their credit card aloud. When the `compliance: "pci"` profile is active, the Realtime module's transcription pipeline actively scrubs the transcript, replacing identified Primary Account Numbers (PAN) and CVV codes with a redacted marker before it ever touches the database.
Cryptographic Audit Logs
PCI-DSS § 10.5 requires absolute audit log integrity. Aeion enforces this by rotating an HMAC-SHA256 signing key every 90 days. Every administrative action, session join, and recording toggle is cryptographically stamped, preventing malicious tampering.
Strict Data Retention
Cardholder-adjacent data cannot live forever. The OS enforces a strict 365-day retention rule for any session operating under the PCI profile, automatically purging recorded media after exactly one year via a secure background job.
Attested Sub-Processors Only
If an AI agent joins a PCI session, it's physically restricted from using standard LLMs. An API-level sandbox routes it only to a curated allowlist of AI providers, guaranteeing that real-time data is only ever sent to providers holding a valid PCI-DSS Attestation of Compliance (AoC).
At-Rest Encryption
Every piece of recorded media or system state tied to a PCI session is encrypted. Aeion OS natively wraps data in AES-256-GCM, with the root secrets securely managed by a KMS.
The Compliance Profile Engine
Dynamic Security Toggling
Not every meeting needs military-grade encryption. Aeion lets operators toggle the `compliance: "pci"` or `compliance: "hipaa"` profile dynamically based on context. An internal HR standup runs smoothly on standard defaults, while a retail billing dispute instantly upgrades the session to enforce TLS 1.3, audio scrubbing, and KMS encryption.
PCI-DSS v4.0 — All 12 Requirements Mapped
Req. 1 — Install + maintain network security controls
Tenant-isolated VPC + per-tenant firewall rules + denied-by-default outbound on the CDE.
Req. 2 — Apply secure configurations to all system components
Hardened OS images (CIS Benchmark Level 2), reviewed on a regular cadence by our platform security process.
Req. 3 — Protect stored account data
We don't store PANs — client-side tokenization keeps Aeion out of the CDE entirely.
Req. 4 — Protect cardholder data with strong cryptography during transmission
TLS 1.3 mandatory; PANs never traverse Aeion's network (tokenized at the browser).
Req. 5 — Protect all systems + networks from malicious software
Files module DLP scanning (antivirus engine + AI signatures) on every upload.
Req. 6 — Develop + maintain secure systems + software
Pre-destructive migration guard, 3-stage RBAC review on every change, SAST + SCA scanning.
Req. 7 — Restrict access to system components + cardholder data by business need-to-know
3-stage RBAC — a permission resolver enforces least-privilege on every request.
Req. 8 — Identify users + authenticate access
MFA mandatory for any user with payment-adjacent permissions; WebAuthn + TOTP available.
Req. 9 — Restrict physical access to cardholder data
Cloud-only — no physical CDE under your control. Your hyperscaler handles 9.x.
Req. 10 — Log + monitor all access to system components
HMAC-SHA256 signed audit logs with key rotation every 90 days.
Req. 11 — Test security of systems + networks regularly
Quarterly internal penetration testing by our security team; annual external ASV scan by a qualified scanning vendor.
Req. 12 — Support information security with organizational policies + programs
Documented policies (incident response, vendor management, security awareness) shared on request.
Scope Reduction — Aeion Stays Out of the CDE
The fastest path to PCI compliance is not handling cardholder data at all. Aeion's architecture is built around this principle:
SAQ-A eligible. If you tokenize cards via Stripe Elements, Square Web Payments SDK, Adyen Web Components, or any other PCI-DSS Level 1 hosted-iframe provider, your Aeion deployment qualifies for the SAQ-A (Self-Assessment Questionnaire A) — the lowest-burden PCI attestation, 22 controls instead of 300+.
The PAN never touches Aeion. Card data goes browser → iframe → payment provider → tokenized response back to browser → token submitted to Aeion. Our backend only sees the token (e.g., tok_1Q... from Stripe or cnon:... from Square). We have no way to recover the raw PAN even under subpoena — by architecture.
Stored payment methods. When a customer "saves their card for next time," Aeion stores ONLY the provider-issued payment method ID (pm_..., card_...) — never the raw card. Subsequent charges are issued via the provider's stored-credential API. The card itself lives in the provider's PCI-DSS Level 1 vault.
Refunds + voids + ACH. Same model. Aeion holds the transaction ID, the provider holds the payment instrument. We forward your operator's intent (refund $50, void $200), the provider executes against the stored credential.
What's IN Aeion's scope: the transaction record, the customer ID, the amount, the timestamp, the status. None of that is cardholder data per PCI Glossary — it's transaction metadata. Storing it doesn't bring Aeion into CDE scope.
What's OUT of Aeion's scope: PAN, expiration date, CVV/CVC, track 1/2 data, PIN/PIN block. These never enter our network.
Supported Payment Providers — Tokenization Out of the Box
Stripe
Stripe Elements + Payment Element + Checkout, Apple Pay, Google Pay, ACH (US/SEPA), connect (marketplace + saas), subscriptions, billing portal.
Square
Web Payments SDK, Apple Pay + Google Pay, Cash App Pay, ACH, In-Person via Square Terminal (Bridge-integrated for POS).
Adyen
Drop-in component + Web Components, 100+ payment methods globally (iDEAL, SOFORT, Klarna, AliPay, WeChat Pay).
PayPal / Braintree
Drop-in UI + JS SDK, PayPal Express, Venmo, ApplePay, GooglePay, ACH via Braintree.
Authorize.Net
Accept.js iframe tokenization, eCheck, recurring billing.
Worldpay
Hosted payment page + tokenization, supported for European acquirer-direct.
Klarna
BNPL (Pay in 4, Pay in 30, Financing) via hosted widget.
Custom provider
Pluggable adapter pattern. Any PCI Level 1 provider with a JS tokenization SDK works.
Real-Time PAN Scrubbing
In retail customer support, telehealth, and contact center scenarios, customers often read their card number aloud over voice. PCI-DSS § 3 says you can't store CHD; but if you record sessions, the audio file becomes CHD by transcript.
Aeion's solution: real-time redaction at the transcription layer. When compliance: "pci" is set on a Realtime session:
- Live audio streams through the Whisper.cpp transcription pipeline.
- PAN detector (regex + Luhn algorithm validation) scans the transcript window for 13-19 digit sequences matching credit card BINs.
- CVV detector scans for 3-4 digit sequences preceded by trigger words ("the security code", "the three digits on the back").
- Detection → redaction. Matches replaced with
[PAN_REDACTED]/[CVV_REDACTED]in the transcript stream. The matching audio segment is also muted-out in the recording (silence-substitution, with frame-accurate timing from the transcription word-timestamps). - No undo. Redaction happens before the database write — there's no path to recover the original.
Result: even if a support agent records the call, the recording contains no usable cardholder data. The session is out of PCI scope by construction.
Audit Log Integrity — Cryptographically Stamped
PCI-DSS § 10.5 demands audit log integrity — auditors must be able to prove that logs weren't modified after the fact. Aeion uses HMAC-SHA256 chained signatures:
- Per-row HMAC. Every audit row signed with a tenant-scoped HMAC key.
- Chain commitment. Each row's signature includes the previous row's signature in the input — tampering with row N invalidates the signature of every row N+1, N+2, ... up to "now."
- Key rotation. The HMAC signing key rotates every 90 days. Old keys are archived but readable for verification — auditors can verify historical signatures against the key in use at the time of writing.
- Verification tooling. Operators can recompute the chain and flag any tampered rows on demand — via Admin → Compliance → Verify Audit Chain, or as part of a scheduled integrity check.
Every PCI-relevant event flows through this pipe: session start, session join, recording toggle, payment authorization, refund, admin login, role change, key rotation, configuration change.
Frequently Asked Questions
If you tokenize cards via Stripe / Square / Adyen / any PCI Level 1 hosted iframe, you qualify for **SAQ-A** — 22 controls, the lowest burden. If you also handle the iframe (e.g., custom checkout that injects PCI-relevant JavaScript), you bump up to **SAQ-A-EP** — about 100 controls. If you handle raw PAN at any point, you're in **SAQ-D** — 300+ controls. Aeion's architecture pushes you toward SAQ-A by default; SAQ-A-EP is uncommon; SAQ-D requires explicit Enterprise configuration we don't recommend.
No — by architecture. The card data goes browser → payment-provider iframe → tokenization. Our backend only sees the opaque token. There's no API endpoint, no service, no migration path that exposes a raw PAN to Aeion-owned infrastructure. Even with root database access, you'd find tokens like `tok_1Q...` instead of card numbers.
Same — we store the provider's payment method ID (`pm_...` / `card_...`), not the card itself. Subsequent charges call the provider's stored-credential API with that ID. The card lives in the provider's vault forever; we never have it.
Pro and Enterprise tiers include a PCI-DSS Responsibility Matrix that maps each of the 12 requirements to "Aeion's responsibility" / "Your responsibility" / "Shared." We provide our portion's AoC + ROC on request. Enterprise customers get a dedicated security contact who joins QSA calls.
Yes — Whisper.cpp supports 100+ languages and PAN detection is digit-based (language-agnostic). CVV detection relies on trigger phrases; for non-English deployments, the trigger phrase list is configurable per tenant (e.g., "code de sécurité" for French, "código de seguridad" for Spanish).
~50-150 ms added to the transcription pipeline (Whisper inference dominates). End-user perceives no difference vs unprotected. The redaction step runs in-line with transcription, not as a separate pass.
Audio-only at present. Video frames are not scanned for displayed card numbers (someone holding their card up to the camera). If your workflow includes that risk, configure the session to block video recording under the PCI profile — supported on Pro+. We're tracking video-PAN OCR as a future enhancement.
Yes, on Enterprise. The payment adapter pattern accepts any provider with a client-side tokenization SDK. We'll review the provider's PCI Level 1 attestation and build the adapter (~1-2 weeks). The integration follows the same External-Adapter honest-no-op pattern as Bridge.