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 |
| API impact | Application calls stay OpenAI-compatible; key management is configuration |
| Revocation | Disabling the master key stops access to protected data |
| Rotation | Scheduled master key rotation with data key re-wrapping |
| Environments | Separate keys per environment and workspace |
| Audit | Key operations and data access exportable to SIEM |
| Status | Customer-managed keys are live on enterprise plans; confirm specifics with the enterprise team |
TL;DR
- BYOK is configuration plus operations, not a new API to code against.
- Use envelope encryption so rotation touches data keys, not your master key.
- Test revocation and rotation in staging; untested controls fail when needed.
- Separate keys per environment so staging can never read production data.
- Stream key operations to your SIEM and alert on anomalies.
How it works, step by step
- Create a master key in your KMS or HSM with a policy that limits which roles and services may use it.
- Connect it to your Plugsky enterprise workspace, confirming which data classes it protects.
- Keep separate keys per environment; staging keys must not be able to decrypt production data.
- Implement rotation as a scheduled job that re-wraps data keys, and log every operation.
- Test revocation in staging: disable the key, observe what stops, re-enable and document the blast radius.
- Route key usage and access events into your observability stack, with alerts on unusual decrypt patterns.
- Document escrow and break-glass procedures, and make key recovery part of your incident runbooks.
Try it yourself
Open the AI API key security checklist →
What you actually build
BYOK does not change your application code. Chat completions, streaming and embeddings remain OpenAI-compatible; the key is a configuration and operations concern around the platform. What you build is the key policy, the rotation job, the alerting and the runbooks.
The mechanism is envelope encryption. Your master key stays in KMS or HSM and wraps the data keys that protect stored objects. That indirection is why rotation is cheap and revocation is decisive: you change the wrapper, not every object, and you disable access without deleting data.
Environment separation and testing
Most BYOK incidents are self-inflicted: staging keys reused in production, rotation jobs that fail silently, or revocation paths nobody has exercised. Separate keys per environment and per workspace, and make the separation testable — a staging credential should demonstrably fail against production data.
- Rotation: schedule it, monitor duration and completeness, and verify samples decrypt afterwards.
- Revocation: rehearse it; know which workloads stop and how recovery works.
- Alerts: unusual decrypt volume or geography is an early signal of misuse.
The operational trade-offs
BYOK trades convenience for control. With provider-managed encryption, key availability is the provider's problem; with customer-managed keys, it is yours. That means KMS redundancy, documented escrow and a recovery plan that has been executed at least once outside production.
Be honest about scope in your own documentation: BYOK protects stored data, while inference happens in memory. Pair it with region pinning, access controls and audit export to cover the rest, and only adopt BYOK where a real requirement — regulation, customer contract or risk policy — justifies the operational load.
Honest comparison
| Developer concern | BYOK on Plugsky | Provider-managed encryption | Self-built serving |
|---|---|---|---|
| Code changes | None; configuration and operations | None | Full encryption design |
| Key custody | Your KMS or HSM | Provider | Your estate |
| Rotation | Your schedule and tooling | Provider-scheduled | Your implementation |
| Revocation | Immediate through key policy | Not available to you | Fully yours |
| Failure mode | Your key store becomes a dependency | Provider outage only | All on you |
| Adopt when | Compliance or contract requires it | Default for most teams | You operate the platform |
Frequently asked questions
Does BYOK change the API I call?
No. Chat completions, streaming and embeddings stay the same. BYOK adds a customer-managed key on enterprise plans and surrounding operational work.
Which key stores can I use?
AWS KMS, Azure Key Vault, HashiCorp Vault and on-prem HSM are documented options, alongside per-region platform encryption for those who do not need customer-managed keys.
How does rotation avoid rewriting data?
Envelope encryption. Data keys encrypt objects, and your master key wraps those data keys, so rotation re-wraps keys rather than re-encrypting all data.
What breaks if I revoke a key?
Anything protected by it becomes unreadable. That is the point of a kill switch, but it means revocation must be tested in staging and covered by incident runbooks.
Should staging and production share a key?
No. Separate keys per environment and workspace, and verify that staging credentials cannot decrypt production data. Shared keys are a common and serious mistake.
What should I monitor?
Key usage patterns, decrypt failures, rotation job outcomes and access changes. Alert on unusual volume or unexpected principals, and route events to your SIEM.
When is BYOK worth the operational cost?
When a regulation, customer contract or internal risk policy requires it. For most teams, region pinning, access controls and audit export cover the need without the extra dependency.