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) |
| Customer custody | Per-tenant keys via AWS KMS, Azure Key Vault, HashiCorp Vault or HSM |
| Procurement evidence | DPA with GDPR Article 28 terms, SCCs and a published subprocessor list |
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.
- Per-tenant envelope keys keep revocation scoped to one customer.
- BYOK shortens enterprise reviews when paired with DPA and audit evidence.
- 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.
- Design tenant metadata so each workspace references its own key provider.
- Test with a design partner, including revocation and key-unavailable scenarios.
- Publish the custody model with the DPA and subprocessor list buyers request.
Original data
Try it yourself
Open the sovereign AI readiness score →
BYOK for SaaS teams: what changes
SaaS teams meet BYOK in two directions: enterprise buyers ask whether you offer it, and your own platform must protect tenant data with keys the customer controls. Supporting customer-managed keys is often the fastest way through a security review, because custody moves to infrastructure the buyer already trusts.
In practice, bring your own key (BYOK) creates a cryptographic boundary you operate: your KMS or HSM holds the master key, Plugsky uses it through envelope encryption to wrap per-object data keys, and revoking it stops access to everything protected by that key. AES-256 at rest with per-region KMS, TLS 1.3 in transit, and key permissions kept separate from platform administration are the baseline controls.
Architecture and controls
Design per-tenant envelope encryption: a tenant-specific key wraps the data keys for that tenant's stores, so revocation affects one customer rather than the platform. Keep key permissions separate from platform administration and record lifecycle events for the audit exports buyers request.
Integration pattern and rollout
Implement custody as configuration, not code: tenant metadata names the KMS or HSM and the application keeps using the same OpenAI-compatible API. Test with a design-partner tenant, including the revocation path, before publishing BYOK as a feature.
The engineering work sits around the pipeline: reference the customer key from the workspace, keep the OpenAI-compatible call path unchanged, and automate rotation so it becomes routine rather than an incident. Export key lifecycle events to the same SIEM that receives authentication and admin events, and keep break-glass procedures in version control.
Limits, evidence and cost
BYOK does not make you compliant on its own — SOC 2 Type II and ISO 27001 readiness is in progress, so align claims with what you can evidence. It also shifts availability risk: if the customer's key is unavailable, their workloads are too.
There is no separate line item for customer-managed keys on supported tiers; check the live pricing page for plan detail. The free plan covers plugsky-micro and plugsky-lite with no card, and the 14-day full-access trial lets you test the full capability set before you commit.
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 |
| Customer-managed keys | BYOK available to offer your own tenants | Add-on or absent | You implement per-tenant encryption |
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.
Should we offer BYOK to our customers?
It often shortens enterprise security reviews because custody stays with the buyer. Start with design partners, document the revocation path, then productise it.
How do we scope keys per tenant?
Use per-tenant envelope keys so revocation affects one customer, and keep key permissions separate from your platform administration roles.
What do buyers ask for first?
Key custody, revocation and evidence. Pair the answer with your DPA, subprocessor list and region-scoped audit exports.