Cut us off: the BYOK kill-switch drill

Every vendor security review arrives at the same question, usually around slide four: "So now you hold our data. Aren't you just our new breach target?"

Most vendors answer with adjectives. SOC 2. Encryption at rest. A trust portal with a green checkmark. All of it amounts to we promise, and the person running the review knows it. They've read the same breach postmortems you have, the ones where the trusted middle was the thing that broke.

We answer with a drill. Not a slide, but an exercise you run in your own AWS account, against your own logs.

The drill

Alyria's fleet data (the inventory, the MCP call records, the audit chain) is encrypted under a key that lives in your KMS, not ours. We hold ciphertext and wrapped data keys. The key-encryption key is yours: in your account, under your IAM policy, logged by your CloudTrail.

In every pilot, we schedule the kill-switch drill. Your team revokes our grant on that key. Then you watch, in your own CloudTrail rather than our dashboard, as our service loses the ability to decrypt anything of yours:

{
  "eventSource": "kms.amazonaws.com",
  "eventName": "Decrypt",
  "userIdentity": { "arn": "arn:aws:sts::…:assumed-role/alyria-tenant-acme/…" },
  "errorCode": "AccessDenied",
  "errorMessage": "The ciphertext refers to a customer master key that does not
                   exist, does not exist in this region, or you are not allowed
                   to access."
}

That AccessDenied is the whole argument. Our access to your stored data died, you did it yourself, and the evidence is in a log we cannot write to. Restore the grant and the pilot continues; leave it revoked and we go dark on your tenant. That is the standing arrangement, not a demo trick, and not something you have to take our word for.

What we claim — exactly, and no more

Precision matters here, so here is the claims ladder as we'd defend it in a review.

What we claim: static blobs stored with us are opaque to us. Data at rest in our systems is encrypted under data keys wrapped by your KMS key. Without an active grant from you, we cannot unwrap those keys, and the stored ciphertext is noise to us. You can verify the dependency exists by severing it.

What that means, precisely: "at rest" is doing real work in that sentence. When our pipeline processes fleet events, correlating an inventory or rendering your dashboard, plaintext exists in memory on our side during processing, under your revocable grant. We won't pretend otherwise. The guarantee is about custody and revocation: everything we persist is under your key, and your key is the single point at which you cut us off.

What we refuse to claim: that we can never see your data. That stronger claim requires client-side cryptography with keys we never hold, and it's only worth anything after an independent audit of the protocol and the implementation. We haven't shipped that audit yet, so we don't make that claim yet. A cryptographic guarantee without an external audit is a press release, and the industry has enough of those.

Why the smaller claim is the better one

It's tempting to say the maximal thing. Plenty of vendors do, and the pattern is always the same: a sweeping headline, a footnote that quietly scopes it down, and a security reviewer who trusts you less after reading both.

We think the credibility runs the other way. A claim you can check beats a claim you have to believe. "Revoke the key and watch us lose access in your own CloudTrail" is checkable in an afternoon. It survives a skeptical CISO reading it out loud, because every noun in it is something the customer controls: their key, their account, their log.

The same principle runs through the rest of the product. The audit chain is tamper-evident: hash-chained and signed, so your auditors can verify its integrity without trusting our database. Policy starts in monitor mode, so you see what enforcement would do before anyone feels it. Beacon is a signed, user-space agent with no kernel driver, because a vendor asking to load code into your fleet's most privileged layer at this stage of trust hasn't earned it. In each case the design goal is the same: shrink what you're asked to take on faith.

The roadmap: from keys you can revoke to keys we never hold

BYOK is not the end state; it's the honest present tense. The next rung on the ladder is Umbra, our client-side secrets layer: encryption and key exchange performed on the endpoint, with keys that never reach us in any form, wrapped or otherwise. The client cryptography and the protocol are the pieces we intend to publish, because a claim like that is only worth making if outsiders can read the code, run it, and confirm the ciphertext leaving a machine is opaque to the service by construction.

When that protocol has shipped and an external audit of it exists, we'll upgrade the claim, and not one day before. Until then, Umbra is roadmap, plainly labeled as roadmap, and the claim we make is the one we can prove today: your data lives under your keys, and you can cut us off, verifiably, whenever you choose.

Ask for the scissors

If you take one thing from this post, make it a procurement habit rather than an opinion about us. When a security vendor asks to hold your data, ask them to hand you the scissors. Ask what key their storage depends on, who controls it, and what you would observe in your logs when you revoke it. A vendor with a good answer will love the question.

Ours is thirty minutes long and ends with an AccessDenied in your CloudTrail. Run the drill with us. It's part of every pilot, right alongside the Agent Exposure Report.