Key facts
| Key custody | Customer-managed keys via AWS KMS, Azure Key Vault, HashiCorp Vault or on-prem HSM |
| Encryption | AES-256 at rest with envelope encryption and per-region KMS; TLS 1.3 in transit |
| Revocation | Revoking the key cuts access to protected data — a live control you operate |
| Deployment | Cloud, your VPC, on-prem and air-gapped tiers all support customer key custody |
| Access control | SSO (SAML 2.0 or OIDC), SCIM provisioning and RBAC at workspace, role and resource level |
| Audit | Key lifecycle and access events exportable to SIEM (Splunk, Sentinel, QRadar, Datadog) |
| Reference architecture | Key hierarchy documented per deployment tier; keys separated from platform admin |
| Exit path | Revoke or retire keys at offboarding; application code stays OpenAI-compatible |
TL;DR
- Your KMS or HSM holds the master key; revocation becomes a live control you operate.
- Envelope encryption with AES-256 at rest and TLS 1.3 in transit keeps rotation cheap.
- Document the key hierarchy before go-live; retrofitting custody is a project.
- Separate key permissions from platform administration so no single role holds both.
- Start free with plugsky-micro and plugsky-lite; a 14-day full-access trial covers larger models.
How it works, step by step
- Decide which stores fall under customer-managed keys and name the owner of the key lifecycle.
- Create the key in your KMS or HSM and reference it from the Plugsky workspace.
- Rehearse rotation and revocation in staging before any production data is protected.
- Draw the key hierarchy and assign an owner for the master key and each data key class.
- Decide the deployment tier per workload and confirm it supports your custody model.
- Export key lifecycle events to the SIEM and keep the runbook under change control.
Try it yourself
Open the private LLM deployment estimator →
BYOK for enterprise architects: what changes
Enterprise architects are asked to prove that encryption keys are separable from the platform, that revocation is possible without vendor intervention, and that the control survives deployment changes. A reference architecture answers that with a key hierarchy, an identity model and an audit trail — not a checkbox on a security questionnaire.
BYOK means you supply and control the keys that protect your data — through a cloud KMS such as AWS KMS or Azure Key Vault, HashiCorp Vault, or an on-prem HSM — while Plugsky performs cryptographic operations with envelope encryption: a master key you own wraps the data keys that protect each store, so rotating or revoking a small key changes access without touching the corpus. AES-256 protects data at rest with per-region KMS, TLS 1.3 protects it in transit, and key permissions are separated from platform administration.
Architecture and controls
Diagram the key hierarchy first: which KMS or HSM holds the master key, which data keys wrap which stores, who can revoke, and what happens to running workloads when a key is disabled. Separate key permissions from platform administration, then route key lifecycle and access events into the SIEM you already operate.
Integration pattern and rollout
Start from the deployment topology you run — Plugsky cloud, your VPC, on-prem or air-gapped — and add key custody as a layer. Because the API stays OpenAI-compatible, key separation changes configuration, identity and operations rather than application code.
Integrate custody as configuration, not application code. A workspace references the key provider, your services keep using the same OpenAI-compatible endpoints, and the security team owns the key lifecycle: creation, rotation, revocation and evidence. Because the key hierarchy is external to the application, a change of custody does not change prompts, evaluations or SDK usage.
Limits, evidence and cost
Where BYOK does not help: it does not make an uncertified platform certified, and it does not remove your duty to classify data. Compliance posture shows SOC 2 Type II and ISO 27001 readiness in progress rather than completed certification — record that honestly in your risk register.
Pricing stays flat-rate on self-serve plans — see the live pricing page for current tiers — so key custody does not introduce per-operation billing. Start on the free plan with plugsky-micro and plugsky-lite and no card, then use the 14-day full-access trial to evaluate larger models before procurement.
Honest comparison
| Concern | Plugsky BYOK | Vendor-managed keys | Building in-house |
|---|---|---|---|
| Key custody | Your KMS or HSM; keys separated from platform administration | Vendor KMS and shared control plane | You build and run the whole stack |
| Revocation | Revoke the key and protected access stops | Usually a vendor support process | You own the runbook |
| Evidence | Key lifecycle and access events exportable to SIEM | Vendor portal logs | Custom logging pipeline |
| Operational load | You own key availability, rotation and backups | Vendor owns the lifecycle | You own everything |
| Time to control | Configuration on supported tiers | Available immediately | Quarters of engineering |
| Reference architecture | Key separation documented per deployment tier | Varies by vendor | You design and prove it |
Frequently asked questions
What does BYOK actually change?
You supply and control the master key through a KMS or HSM while Plugsky performs cryptographic operations with envelope encryption. Revoking your key stops access to protected data, and key operations stay auditable.
Who is responsible when a key is unavailable?
You are. Key availability becomes your availability, so plan KMS or HSM redundancy, break-glass procedures and incident response before go-live.
Does BYOK replace certification or a DPA?
No. It is one technical control. Compliance posture — SOC 2 Type II and ISO 27001 readiness in progress — and contractual terms such as the DPA must be reviewed separately.
Does BYOK change our application code?
No. Key custody is configuration on supported tiers and the API stays OpenAI-compatible, so application code, prompts and evaluations carry over unchanged.
How should we document BYOK for audits?
Diagram the key hierarchy, record who can revoke or rotate, and export key lifecycle events to your SIEM. Keep the runbook under the same change control as other critical procedures.
Can we rotate keys without downtime?
Use envelope encryption so rotation targets small data keys rather than the master key, and rehearse the rotation in staging first — the operational path is where incidents concentrate.