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) |
| Multi-tenant controls | Workspace, role and resource RBAC with scoped API keys per tenant |
| Delegated custody | Per-customer KMS or HSM options with per-tenant audit export |
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.
- Offer key custody as a service tier; customers with strict policies retain control.
- Keep per-tenant evidence exportable without moving another customer's data.
- 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.
- Define custody tiers in your service catalogue with clear responsibility boundaries.
- Provision each tenant with a workspace, scoped keys and its chosen key provider.
- Document the incident path when a customer key is disabled mid-service.
Try it yourself
Open the AI API key security checklist →
BYOK for MSPs: what changes
MSPs run AI for many customers at once, and each customer eventually asks the same question: who holds the keys? Offering customer-managed keys turns a security objection into a product feature, provided tenant boundaries, delegated administration and evidence hold up under review.
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
Model tenancy with workspaces, scoped API keys and RBAC at role and resource level, then let each customer bring their own KMS or HSM where policy requires it. Keep key lifecycle events exportable so you can answer customer audits without exposing another tenant's data.
Integration pattern and rollout
Standardise a service-catalogue entry: deployment tier, key custody option, retention profile and audit exports. Because Plugsky is OpenAI-compatible, automation and integration code carries across tenants; only configuration and key custody vary.
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
BYOK raises your operational bar — key availability becomes part of your SLA to the customer. Document what happens when a customer disables a key mid-incident, and separate your platform recovery path from their key recovery path.
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 |
| Tenant custody | Per-customer key custody offered as a service option | Often single model for all tenants | You build tenancy and custody |
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.
Can each customer bring their own key?
Yes. BYOK is available through AWS KMS, Azure Key Vault, HashiCorp Vault or HSM, so customers with strict policies retain custody while you operate the platform.
How do we keep tenant evidence separate?
Use workspaces and scoped keys per tenant, and export audit events per tenant. Reviews should be answerable without moving another customer's data.
Does BYOK change our SLA?
Your platform SLA stays yours; key availability becomes a customer responsibility. Document that boundary explicitly in the service description.