PCI-DSS Architecture & Specs
A deep dive into the `compliance: "pci"` profile, HMAC-SHA256 audit log integrity, and real-time PAN/CVV NLP scrubbing.
Security & Enforcement Metrics
Audit Signing
HMAC-SHA256 (Rotated 90 days)
Encryption At-Rest
AES-256-GCM via KMS
Network Standard
TLS 1.3 minimum (session policy; enforced at the network edge)
Retention Max
365 Days (Auto-Purge)
1. Real-Time Data Minimization (§ 3.3.1)
Aeion goes beyond standard database tokenization by aggressively protecting the unstructured data generated during voice and video calls.
- Real-Time PII Scrubbing: When a Realtime session runs under the compliance: "pci" profile, the transcription pipeline's redaction layer shifts into strict mode. The PAN detector doesn't just look for long digit runs — it validates 13–19 digit sequences against the Luhn checksum and known card BIN patterns, so it flags real card numbers rather than order IDs or phone numbers that happen to be long. The CVV detector keys off trigger phrases ("the security code," "the three digits on the back") to catch 3–4 digit codes that carry no self-identifying structure. Matches are replaced with a redacted marker ([PAN_REDACTED] / [CVV_REDACTED]) before the transcript is ever committed to the database, and the corresponding audio segment is muted-out in the recording using frame-accurate word timestamps — so neither the text store nor the media file retains usable cardholder data. Redaction is one-way: it runs inline, ahead of the database write, and there is no path to recover the original.
- Data Retention Limits: PCI-DSS § 9.4 mandates strict retention limits. The profile automatically enforces a 365-day retention window. A background job monitors PCI-tagged recording sessions and hard-deletes both the database records and the backing media files the moment they exceed one year of age — the deletion isn't a soft-delete flag, it removes the underlying media so aged cardholder-adjacent recordings can't be resurrected.
The PCI Compliance Runtime, Conceptually
Setting a session's compliance profile to pci activates a bundle of enforced constraints, all at once, with no piecemeal opt-in:
- TLS 1.3 minimum and mandatory recording encryption (§ 3.5.1 and § 4.2.1)
- Audit log signing on every action in the session (§ 10.5)
- An AI/LLM/TTS/STT provider allowlist — only sub-processors with an active Attestation of Compliance (AoC) may process session data (§ 12.8)
If a developer's code (or a misconfigured integration) tries to route a PCI session's audio or transcript to a provider that isn't on the allowlist, the kernel refuses the call outright — the request never leaves the allowlist gate, and the session continues under its remaining constraints rather than silently sending cardholder-adjacent data somewhere unapproved.
2. Audit Log Integrity (§ 10.5)
In a post-breach scenario, auditors must trust the logs. Standard SQL tables can be manipulated by malicious insiders. - HMAC-SHA256 Chained Signing: Every time a PCI session is created, joined, or recorded, the action is logged, and the audit-signing layer generates a cryptographic stamp using an active HMAC-SHA256 key. The signing input for each row includes the previous row's signature, so the ledger is a chain rather than a set of independent stamps — altering any single row invalidates not just that row but the signature of every row written after it. A malicious insider can't quietly edit one entry and re-sign it in isolation; the break propagates all the way to "now." - 90-Day Key Rotation: To comply with strict cryptography requirements (§ 3.6), the system rotates the active HMAC signing key every 90 days. Old keys are retained (wrapped via a KMS) exclusively for signature verification, so auditors can recompute and validate historical signatures against whichever key was active when each row was written. Verification is operator-runnable on demand rather than a black box — the chain can be recomputed and any tampered row flagged.
Frequently Asked Questions
Before. The PAN/CVV scrubber runs inline with transcription, ahead of the database write. By the time a transcript row is committed, the cardholder data is already gone, and the matching audio segment has been muted in the recording. There's no "redact later" pass and no way to recover the original string.
Each row's HMAC-SHA256 signature includes the previous row's signature as part of its input, forming a chain. Editing row N breaks N's signature *and* every signature after it, so a single quiet edit is mathematically visible. Rotated-out keys are wrapped in a KMS and kept for verification, so historical rows still validate against the key that was active when they were written.
It activates the whole bundle at once: a TLS 1.3-minimum policy tag on the session, mandatory AES-256-GCM encryption of recordings, audit signing on every session action, and an AI/LLM/TTS/STT sub-processor allowlist. If code tries to route session audio or transcript to a provider without an active Attestation of Compliance, the kernel refuses the call at the allowlist gate rather than sending it.
Connection-level TLS enforcement lives at your network edge — the `pci` profile records a TLS 1.3-minimum policy for audit visibility, but your load balancer or reverse proxy must physically drop TLS 1.2 traffic before it reaches the app. Network segmentation and engaging a QSA for quarterly ASV scans also remain yours.
There's a strict remediation runbook: an admin can surgically delete the offending transcript row and its source recording media, and the audit-signing layer records those deletions immutably. The miss is flagged back to the platform team to harden the detection pattern, so the core system stays secure while the gap is closed.