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) |
| Protected data | AES-256 at rest with envelope encryption under customer-managed keys |
| Incident control | Revoking the key cuts access to protected data — rehearse the runbook |
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.
- A revoked key bounds exposure immediately; document the runbook before you need it.
- Pair key custody with prompt minimisation and retention limits, not instead of them.
- 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.
- Pick a read-heavy clinical workflow for the first deployment and classify its data.
- Configure retention to the minimum the policy allows and redact identifiers before prompting.
- Restrict key permissions to a small operations group with a documented incident path.
Original data
Try it yourself
Open the sovereign AI readiness score →
BYOK for healthcare teams: what changes
Healthcare teams carry protected health information across clinical, billing and research systems, and each flow has its own minimum-necessary rules. Key custody gives security teams a direct way to bound exposure: disable the key and protected data becomes unreadable, while every key operation is recorded.
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
Keep identifiers out of prompts where policy allows and use customer-managed keys for the stores that hold the rest. Configure prompt retention to the minimum your policy permits, and route key lifecycle and access events into the audit tooling your compliance team already reviews.
Integration pattern and rollout
Begin with a read-heavy use case such as policy search or document summarisation, run it in staging with a test key, then rehearse revocation and rotation. At go-live, restrict key permissions to a small operations group and document the path for key unavailability.
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 protects data at rest and gives you a revocation control; it does not replace a HIPAA-style compliance programme, and Plugsky's certifications are in progress rather than complete. Treat it as one layer in a defence-in-depth design.
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 |
| PHI protection | Customer keys plus configurable retention and audit | Shared key management | Full platform responsibility |
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 make PHI handling compliant?
No. It strengthens protection and gives you a revocation control, but a compliance programme, risk analysis and policies remain your organisation's responsibility.
What happens to running workloads if a key is revoked?
Access to data protected by that key stops. Plan the incident runbook for key unavailability and test the path in staging before relying on it.
Should we encrypt everything with customer keys?
Start with the stores that hold protected data and expand as evidence accumulates. Keep key permissions limited to a small operations group.