BYOK Encryption: Why Your AI Audit Logs Should Use Your Keys
Your AI gateway audit log contains the most sensitive data in your AI infrastructure. Every prompt, every response, every detection event, every enforcement action — the full record of what your organization sent to AI models and what came back. For regulated industries, this log is both the compliance evidence and the exposure surface.
Most AI gateways encrypt audit logs with platform-managed keys. The vendor generates the key, the vendor stores the key, and the vendor can decrypt the data. For organizations subject to HIPAA, PCI-DSS, SOX, or data sovereignty requirements, that is not sufficient. The question from your compliance team is straightforward: who controls the encryption key?
Bring Your Own Key (BYOK) encryption answers that question. The customer provides the key. The platform encrypts with it. The platform cannot decrypt without the customer’s authorization. Audit data is protected even from the platform operator.
The Problem with Platform-Managed Keys
When a SaaS platform manages the encryption key for your audit data, three things are true:
The platform can read your data. Not “could theoretically” — operationally can, because the platform holds the decryption key. For audit logs that contain prompts with patient records, financial data, or proprietary business context, this creates a data processing relationship that your compliance program must account for.
Key compromise is platform-wide. A breach of the platform’s key management affects every customer simultaneously. Your organization’s audit data exposure is tied to the platform’s security posture, not your own.
You cannot prove exclusive control. When a regulator asks “who can access this data?”, the honest answer includes the platform operator. For HIPAA covered entities, PCI-DSS merchants, and SOX-regulated companies, that answer triggers additional oversight requirements — subprocessor agreements, data processing addendums, and audit scope expansion.
BYOK removes all three problems. Your key lives in your key management system. The platform receives a wrapped data encryption key for each operation and returns it when done. Your KMS controls access. You control the key lifecycle — rotation, revocation, and destruction.
How Envelope Encryption Works
BYOK does not mean sending your master key to the platform. It uses envelope encryption — a standard pattern where two layers of keys protect the data.
Your customer-managed key lives in your KMS (Azure Key Vault, AWS KMS, or HashiCorp Vault). It never leaves your KMS. The platform never sees it in plaintext.
Data encryption keys are generated per encryption operation and wrapped (encrypted) using your customer-managed key. The wrapped key is stored alongside the encrypted data. Plaintext encryption keys are never persisted to storage.
The flow for writing an audit log entry: the platform requests a key from your KMS, encrypts the audit record’s sensitive fields using industry-standard AES-256 encryption, discards the plaintext key from memory, and stores the wrapped key reference alongside the encrypted record.
The flow for reading an audit log entry: the platform retrieves the encrypted record and its wrapped key reference, sends the wrapped key to your KMS for unwrapping, decrypts the audit fields, then discards the plaintext key from memory.
At no point does the platform possess your customer-managed key. At no point is a plaintext data encryption key persisted to storage. The only long-lived secret is the wrapped key — which is useless without your KMS to unwrap it.
Fail-Closed Writes, Fail-Open Reads
The hardest design decision in BYOK is what happens when the KMS is unavailable. Your key management system is an external dependency — it can be slow, temporarily unreachable, or misconfigured. The platform must decide: do I fail the operation or proceed without encryption?
Writes are fail-closed. If the KMS is unavailable when the platform needs to encrypt an audit record, the write fails. The audit entry is not written in plaintext. The request that generated the audit event still completes, but the audit record is not persisted until encryption succeeds.
This is non-negotiable for regulated industries. A BYOK organization has made an explicit commitment: our audit data must be encrypted with our keys. Writing a plaintext record because the KMS was momentarily unavailable violates that commitment. A compliance auditor will not accept “we fell back to unencrypted for three minutes during a network hiccup” as an acceptable control failure.
Reads are fail-open. If the KMS is unavailable when an admin, export job, or SIEM connector needs to read an audit record, the system returns a placeholder: [encrypted - KMS unavailable]. The record exists. The metadata is visible. The encrypted content is not decrypted, but the system does not error out.
This asymmetry is deliberate. A failed write creates a permanent compliance gap — an unencrypted record that should not exist. A failed read is a temporary inconvenience — the data is still encrypted, still protected, and will be readable when the KMS recovers. The security posture during a read failure is actually stronger than normal operation, because nothing is decrypted.
Key Caching
Calling the KMS for every audit write creates a latency and availability dependency that does not scale. At enterprise traffic volumes, the KMS would receive thousands of key requests per minute — and every request on the write path would block until the KMS responds.
Key caching resolves this. When the platform generates a data encryption key for an organization, the key is cached in memory for a configurable period (default: one hour). Subsequent audit writes for the same organization reuse the cached key instead of requesting a new one from the KMS.
The cache is bounded, with eviction of the least recently used entries when the cache is full. Cache entries expire on a configurable schedule. When a key expires or is evicted, the next write requests a fresh key from the KMS. All records remain encrypted at rest — the cache only affects write-path latency.
For organizations that require maximum key isolation, the cache TTL can be set to zero. Every write generates a fresh key. The latency cost is a KMS round-trip per audit event.
SIEM Forwarding
Audit logs are not useful only in the platform’s admin console. Security teams need audit data in their SIEM — Splunk, Microsoft Sentinel, Elastic, or a webhook endpoint. For BYOK organizations, SIEM forwarding means the platform must decrypt records before sending them to the SIEM sink.
The decryption happens on-the-fly during the SIEM export process. The platform retrieves encrypted audit records, unwraps the DEKs via the customer’s KMS, decrypts the fields, and forwards the plaintext records to the configured SIEM endpoint. The decrypted copies are not persisted — they exist in memory only for the duration of the forwarding operation.
If the KMS is unavailable during SIEM forwarding, the fail-open semantics apply: records are forwarded with placeholder text for the encrypted fields. The SIEM receives the event metadata (timestamp, user, model, detection type, enforcement action) but not the prompt or response content. When the KMS recovers, subsequent forwarding batches include the decrypted content.
This ensures that SIEM ingestion is never blocked by KMS availability. Security teams see the event timeline in real time. The sensitive content follows when the KMS is reachable.
The Integrity Chain
Arbitex audit logs use a cryptographic integrity chain — each entry’s hash incorporates the previous entry’s hash, creating a tamper-evident sequence. For BYOK organizations, the integrity hash is computed over the encrypted record, not the plaintext content. This means the integrity chain is verifiable without decryption — you can prove that no records were modified, inserted, or deleted without ever decrypting the data.
Existing audit records (for organizations that enable BYOK after their initial deployment) remain readable. Each record carries a marker indicating which fields are encrypted. Records written before BYOK enablement have no encrypted fields and are read as plaintext. There is no mandatory backfill — historical records stay in their original form.
Why BYOK Matters for Compliance
The compliance case for BYOK is not about encryption strength — AES-256 encryption is the same standard regardless of who manages the key. The case is about control and attestation.
HIPAA (45 CFR 164.312): Covered entities must implement technical safeguards for electronic PHI. When audit logs contain prompts with patient data, those logs are ePHI. BYOK gives the covered entity encryption key control — the covered entity can attest that even the platform operator cannot access PHI without their authorization.
PCI-DSS (Requirement 3): Cardholder data must be encrypted at rest with keys managed according to documented key management procedures. BYOK aligns audit log encryption with the merchant’s existing key management program, rather than introducing a separate key management relationship with the platform vendor.
SOX (Section 404): Internal controls over financial reporting must be documented and testable. If audit logs capture AI interactions involving financial data, BYOK provides a clean control narrative: the company controls the encryption key, the company controls access to the data, the company can demonstrate that control to auditors.
In each case, the question from the auditor is the same: who can decrypt this data? With platform-managed keys, the answer includes the platform. With BYOK, the answer is only your organization.
For more on the Arbitex encryption posture, read Zero Cleartext: How Arbitex Enforces Encryption at Every Layer. For audit log architecture, see the platform security overview. For DLP detection that generates these audit events, see the complete DLP pipeline series.
Book a demo to see BYOK encryption in action for your AI audit logs.