Key facts
| Key stores | AWS KMS, Azure Key Vault, HashiCorp Vault or on-prem HSM |
| Encryption model | AES-256 at rest with envelope encryption; TLS 1.3 in transit |
| Revocation | Disabling the master key stops access to protected data |
| Rotation | Scheduled master key rotation with data key re-wrapping |
| Deployment tiers | Cloud, VPC, on-prem and air-gapped all support key separation |
| Identity | SSO/SCIM and RBAC separate key custodians from platform administrators |
| Audit | Key operations and data access recorded and exportable to SIEM |
| Status | Customer-managed keys are live on enterprise plans; confirm specifics with the enterprise team |
TL;DR
- Envelope encryption keeps the master key inside your KMS or HSM.
- Revocation is a genuine kill switch — and your availability depends on it.
- Design key escrow, recovery and rotation before go-live.
- Separate key custody from platform administration.
- Keep keys in the same jurisdiction as the data they protect.
How it works, step by step
- Decide which data classes require customer-managed keys: prompts, completions, embeddings, logs or all four.
- Choose the key store — AWS KMS, Azure Key Vault, HashiCorp Vault or on-prem HSM — and confirm residency with your data planes.
- Define key hierarchy: a master key in your store wrapping per-object data keys, with an explicit rotation schedule.
- Separate duties so key custodians are not platform administrators, and require dual control for destructive actions.
- Test revocation and rotation in staging and measure the blast radius before enabling in production.
- Configure key usage and data access audit events to flow into your SIEM with alerts on anomalies.
- Document break-glass, escrow and recovery procedures, and rehearse them with operations and security.
Try it yourself
Open the AI API key security checklist →
How BYOK works in a bank
The standard pattern is envelope encryption. Your master key lives in your KMS or HSM and never leaves it. Each object — a prompt, a completion, an embedding, a log record — is encrypted with a data key, and that data key is wrapped with the master key. Decryption therefore requires an operation your key policy authorises, which is what makes revocation meaningful: disable the key and protected data becomes unreadable.
Plugsky supports customer-managed keys through AWS KMS, Azure Key Vault, HashiCorp Vault and on-prem HSM, alongside per-region platform encryption. The control is genuine, and so is the responsibility: key availability becomes part of your service availability.
Operating a kill switch responsibly
A kill switch that has never been tested is not a control. Rehearse revocation and rotation in a staging estate, measure what stops and how quickly, and record the results. Then design recovery with the same rigour as any critical system: escrow, backup and break-glass procedures with dual control.
- Availability: KMS or HSM outages affect protected workloads; plan redundancy.
- Rotation: schedule re-wrapping, monitor performance and log every rotation event.
- Access: separate key custody from platform administration so no single role holds both.
What BYOK does and does not cover
BYOK protects stored data and gives you a revocable control over it. It does not mean the platform never processes your data — inference happens in memory, so contractual terms, access controls, region pinning and audit remain essential. Be precise in internal documentation, because auditors will probe exactly this boundary.
For the strictest workloads, combine BYOK with a VPC, on-prem or air-gapped deployment and keep keys in the same jurisdiction as data. That combination — keys you control, processing inside your boundary, and audit events in your SIEM — is the position most banking regulators and internal risk functions expect to see.
Honest comparison
| Banking control | Plugsky BYOK | Provider-managed encryption | Self-built platform |
|---|---|---|---|
| Key custody | Your KMS or on-prem HSM | Provider KMS | Your estate |
| Revocation | Available through your key policy | Not available to you | Fully yours |
| Rotation | You schedule and re-wrap | Provider-scheduled | Your process |
| Access separation | Split key and platform duties | Provider staff and systems | Depends on your design |
| Residency | Keys and data in one jurisdiction | Provider region choices | Wherever you host |
| Operational duty | High — availability and recovery | Lowest | Highest |
Frequently asked questions
Does BYOK mean the platform never sees our data?
No. It means you control the keys protecting stored data and can revoke access. Processing still occurs in memory, so contractual, access and audit controls remain necessary.
Which key stores are supported?
AWS KMS, Azure Key Vault, HashiCorp Vault and on-prem HSM are documented for customer-managed keys, alongside per-region KMS for platform encryption.
What happens if we lose a master key?
Protected data may be unrecoverable. Define escrow, backup and break-glass procedures with dual control, and test recovery in staging before enabling BYOK in production.
How does rotation work?
Rotate the master key on schedule and re-wrap data keys. Test for performance and completeness, log each rotation, and confirm that audit events surface in your SIEM.
Can keys live in a different region from the data?
They can, but it usually weakens your residency position. Keep keys and data in the same jurisdiction unless legal advice says otherwise.
Does BYOK work on-prem and air-gapped?
Yes. On-prem HSM integration is supported, and air-gapped deployments keep all key operations inside your perimeter with no external path.
Is BYOK required for compliance?
Not universally, but it is common for regulated data and sovereignty requirements. Confirm what your regulator and auditors expect for each data class before committing.