BYOK isn't one thing.
These are the four models.
Bring Your Own Key means different things in different products. Some keep the key in the vendor's KMS with policy access. Some keep it in the customer's cloud KMS but require vendor APIs to use it. Some require you to run everything yourself. Lucairn's witness-key model isolates the load-bearing key from the operational runtime entirely.
BYOK varies in how much of your key Lucairn (or any AI vendor) ever sees. Vendor-managed keys never leave the vendor — not BYOK. CMK in cloud KMS means the vendor calls your key to use it. Fully self-hosted means you run everything. Lucairn's witness-key BYOK means we operate the runtime, but the load-bearing signing key is generated in your zone and never observed by Lucairn. Witness-key isolation is the fourth, narrowest, most protective model.
What "BYOK"
actually means today.
Vendors say "BYOK" and mean different things. The four below are the production patterns. Each protects you against a different threat model; pick the model that matches the regulator you have.
Vendor-managed (default)
Vendor generates and stores keys in their KMS. Customer has policy controls. The key never leaves the vendor. Branded as "managed encryption" rather than BYOK. This is not BYOK.
Fine for non-regulated SaaS. Loses you immediately under DORA Article 28 scrutiny.
CMK in customer cloud KMS
Customer holds a Customer-Managed Key (CMK) in their own AWS KMS / Azure Key Vault / GCP KMS. Vendor calls your KMS via IAM grants to use the key. Customer can rotate or revoke; vendor pauses on revoke.
Standard enterprise SaaS BYOK. Strong audit trail; vendor still touches keys at use time.
Fully self-hosted
Customer runs the entire inference stack on-prem or in their VPC. Vendor never touches keys; vendor never runs code in the customer's environment. Customer is responsible for upgrades, monitoring, incident response.
Right for sovereign deployments and air-gapped environments. Operationally heavy.
Witness-key isolation BYOK
Lucairn operates the runtime in EU-region SaaS. The witness key — the only key that produces valid receipts — is generated in the customer's zone and never crosses to Lucairn. Lucairn cannot produce a signed receipt; only your key can.
Right when procurement requires customer-held cryptographic claims but full self-hosting is operationally too heavy.
Eight criteria,
four key-custody models.
The criteria are what a CISO and a procurement team will actually push on. Lucairn's witness-key model wins on cryptographic claim isolation but is heavier than vendor-managed on operational simplicity.
Each model is the
right answer somewhere.
We won't pretend Lucairn is the right model for every team. The honest framing: pick the lightest custody model your regulator and procurement team will accept.
- You're already deep in AWS / Azure / GCP and need IAM continuity
- Your auditor accepts use-time vendor access to keys
- Operational simplicity outweighs cryptographic isolation
- Cloud-native procurement is your standard
- Sovereign deployment is a hard requirement
- Air-gap is a hard requirement
- Your team has the ops capacity to run the stack
- Vendor presence in any form is unacceptable to procurement
- Procurement requires customer-held cryptographic claims
- You need the runtime operated by someone (not your team)
- DORA Article 28 sub-outsourcing scrutiny is in your future
- Air-gap is a future option, not a current requirement
- EU-region SaaS is acceptable for the operational layer
BYOK AI platform — questions,
answered.
Why isn't "vendor-managed encryption" BYOK?
Because the vendor still generated and holds the key. The customer has policy controls (rotation, revoke) but the cryptographic material lives in vendor infrastructure. If the vendor is compromised, the keys are compromised. Marketing calls it BYOK; security teams shouldn't.
What's the practical difference between CMK and witness-key BYOK?
CMK: the vendor calls your KMS at use time to operate on data. The vendor briefly handles your key material. Witness-key BYOK: the vendor never touches the load-bearing signing key. The only thing that crosses to the vendor is data the vendor needs to operate on (de-identified payloads in Lucairn's case). Vendor compromise risk is bounded differently in each model.
Can I use a customer-managed HSM with Lucairn?
Yes, on the Enterprise tier. The witness key can be generated and held in your YubiHSM, AWS CloudHSM, Azure Dedicated HSM, or any PKCS#11-compatible HSM. Lucairn's gateway invokes the HSM-held key for each signing operation; the private material never leaves your HSM.
Does BYOK mean I bring my LLM provider key too?
Yes — that's the second BYOK layer in Lucairn. You bring your Anthropic / OpenAI / Mistral / self-hosted vLLM key, and Lucairn never sees it. Combined with the witness-key model, this means Lucairn never holds either of the two cryptographically interesting keys in your deployment. That's by design.
If Lucairn's runtime is compromised, what's the blast radius?
Without the witness key, an attacker on Lucairn's runtime cannot produce valid receipts. They can disrupt new signings (denial of service) but cannot forge signatures or rewrite history. Receipts already in Sigstore Rekor are unaffected. The witness-key isolation property is exactly the protection you want under attack.
From assessment
to production.
Run the self-serve assessment against your AI workflow and see which key-custody model actually matches your procurement and regulator constraints. 15 minutes. Output goes to your DPO.