Key facts
| Key options | AWS KMS, Azure Key Vault, HashiCorp Vault or on-prem HSM |
| Encryption model | AES-256 at rest with envelope encryption and per-region KMS |
| In transit | TLS 1.3 |
| Deployment models | Cloud, VPC, on-prem and air-gapped tiers all support key separation |
| Access control | SSO/SCIM, RBAC at workspace, role and resource level |
| Audit | Key operations and data access recorded and exportable to SIEM |
| Compliance posture | SOC 2 Type II and ISO 27001 readiness in progress (not yet certified); GDPR and PDPL alignment |
| SLA | 99.9% uptime on paid plans; Enterprise 4-hour support SLA — see /legal/sla |
TL;DR
- BYOK gives you a kill switch: revoke the key and access to protected data stops.
- Your key availability becomes your availability — plan KMS redundancy and incident response.
- Use envelope encryption so you rotate small data keys, not the master key on every operation.
- Test revocation and rotation in staging; an untested kill switch is not a control.
- Separate key permissions from platform administration so no single role holds both.
How it works, step by step
- Identify which data classes require customer-managed keys (usually regulated personal data and secrets).
- Choose the key store: cloud KMS, HashiCorp Vault, or HSM, aligned to your residency requirements.
- Define key hierarchy and policies: master key, data keys, rotation cadence, backup and recovery.
- Separate duties so platform admins cannot export keys or grant themselves key access.
- Implement monitoring and alerting on key operations; export logs to your SIEM.
- Test revocation, rotation and recovery in a staging environment.
- Document the operational runbook and rehearse it as part of incident response.
Original data
Try it yourself
Open the sovereign AI readiness score →
How BYOK works in practice
The standard pattern is envelope encryption. Your master key lives in your KMS or HSM and never leaves it. The platform encrypts each object — prompts, completions, embeddings, logs — with a data key, then wraps that data key with your master key. Decryption requires a call your key policy authorises, which is why revocation is meaningful: disable the key and protected data becomes unreadable. Plugsky supports customer-managed keys through AWS KMS, Azure Key Vault, HashiCorp Vault and on-prem HSM, alongside per-region KMS for its own encryption.
The responsibilities you accept
- Availability: if your key store is unavailable, protected workloads stop — design redundancy.
- Recovery: losing a master key can mean permanent data loss; escrow and backup procedures are mandatory.
- Rotation: schedule re-wrapping of data keys and verify performance impact.
- Access governance: split key administration from platform administration.
- Audit: monitor key usage and export records to your SIEM.
Questions to ask a vendor
- Which data classes can be protected with customer keys, and which cannot?
- Is the key used per tenant, per workspace, or per object?
- What exactly happens when we revoke a key — what breaks, and how quickly?
- Are key operations logged with actor, operation and timestamp?
- Can vendor staff access plaintext with our key policy in place?
- Does key residency stay in the same region as the data?
Common pitfalls
The biggest is checkbox BYOK: enabled, never tested, with no plan for rotation or recovery. The second is operational fragility — a single KMS region with no failover. The third is permission sprawl, where platform administrators can also manage keys, defeating the separation that made BYOK valuable. The fourth is mismatched jurisdiction: keys stored in one region protecting data in another undermines the residency story you are trying to tell.
Honest comparison
| Capability | Plugsky | Hyperscaler AI platform | Building in-house |
|---|---|---|---|
| Customer-managed keys | AWS KMS, Azure Key Vault, Vault, on-prem HSM | Cloud KMS integration | You operate the HSM |
| Encryption at rest | AES-256 envelope with per-region KMS | Cloud provider encryption | Your implementation |
| Key audit | Key and access events exportable to SIEM | Native cloud audit | You build it |
| Revocation control | Available through your key policy | Available through cloud KMS policy | Fully in your hands |
| Residency alignment | Region-locked planes for data and keys | Region options per service | Your design |
| Certifications | SOC 2 / ISO 27001 readiness in progress | Completed audits in many regions | Your own programme |
Frequently asked questions
Does BYOK mean the vendor never sees my data?
No. It means you control the keys that protect stored data and can revoke access. Processing still happens in memory, so contractual and access controls remain essential.
Which key stores does Plugsky support?
AWS KMS, Azure Key Vault, HashiCorp Vault and on-prem HSM are documented for customer-managed keys, alongside per-region KMS for platform encryption.
What happens if we lose a key?
Protected data may be unrecoverable. Define escrow, backup and break-glass procedures before enabling BYOK, and test recovery in staging.
How does key rotation work?
Rotate the master key on schedule and re-wrap data keys. Test the procedure for performance and completeness, and log each rotation event.
Is BYOK required for compliance?
Not universally, but it is common for regulated data and for sovereignty requirements. Check what your regulator or auditor expects for the specific data class.
Can keys live in a different region from the data?
They can, but it usually weakens your residency position. Keep keys and data in the same jurisdiction unless your counsel advises otherwise.
Does BYOK work with on-prem and air-gapped tiers?
Yes — on-prem HSM integration is supported, and air-gapped deployments keep key operations entirely inside your perimeter.