Here is a puzzle that sounds like it shouldn’t have an answer. You want to hand someone a file — the whole working thing, theirs to copy, fork, email onward — and yet you want one part of it to stay unreadable to that very person, unless and until you say otherwise. You’re giving them everything, and keeping a secret inside the gift.
That feels impossible, and most of the tricks people reach for to fake it are exactly that: fakes. Let’s be honest about why the obvious answers don’t work, then look at the one that does — because once you see it, it’s almost embarrassingly clean.
why the obvious tricks are theater
Think about how you’d “protect” part of a file you’re about to give away. You might draw a password box over the data. You might tuck it in a “hidden” sheet. You might scramble it into a blob that looks like noise unless your app unscrambles it. These feel like locks.
They are not locks. They are suggestions.
Here’s the fatal flaw they all share. They assume the program reading the file will enforce the rule — check the password, keep the sheet hidden, refuse to unscramble. But the person you handed the file to owns the file and the program. Any check the program runs, they can skip. Any data the file actually contains, they can dig out, byte by byte, no matter how it’s dressed up. A gate the holder’s own software is supposed to enforce is a gate the holder walks straight through.
So real protection can’t be “the file contains the secret, and we politely ask not to look.” It has to be something stronger: the secret simply isn’t there to find.
locked in the open
That’s the move. A sealed section is part of the shipped file that, to everyone holding the file, is genuine gibberish — properly encrypted noise, not a disguise. Anyone can copy it, but the bytes mean nothing. And here’s the crucial part: the key that turns that noise back into sense never rides inside the file. It was never shipped at all.
Picture the cases where you’d want this. A free demo that carries a paid dataset locked inside it. A dashboard you share widely, where the chart is public but the salary column is not. A deliverable you hand a client where the result ships but your private workings stay yours. In every one, the project should travel freely — and one slice of it should stay illegible to whoever holds the copy.
The seal makes that real because it changes where the secret lives. The lock travels with the file; the key stays home. There is nothing in the file to bypass, because there’s nothing in the file to find — only ciphertext, and a key that’s somewhere else entirely.
Which raises the obvious next question: somewhere else where? And who decides you get it?
the key is a decision, not a thing
This is the heart of it, so it’s worth saying slowly. The key isn’t a thing hidden somewhere clever. The key is a decision someone makes the moment you ask for it.
The key lives at the runtime — the always-on engine behind your workbook — held in a small store, not baked into any copy you’ve sent out. When a copy of the file wants to open its sealed section, it doesn’t unlock anything itself. It asks the engine for the key. And the engine, before it hands anything over, checks who’s asking.
That check is strict on purpose. It demands a real, authenticated identity — someone who has genuinely proven who they are. An anonymous request, an empty one, or a stand-in “just-for-testing” identity is refused flat. If you can’t prove you’re allowed, you get a plain refusal, and that refusal looks exactly like every other refusal the engine ever gives. There’s no special “wrong password” message, no hint that you got close, no signal that the key even exists. A denied key request is indistinguishable from any other denied request. That sameness is deliberate: a refusal that leaks nothing can’t be poked at to learn anything.
Only after you’ve proven you’re allowed does the engine reach into its store and hand back the actual key, so your copy can finally read its own sealed section. The decision happens live, every time. It’s a doorman, not a hidden compartment.
one key opens exactly one door
There’s a sneaky attack the design has to kill, and seeing how it’s killed tells you how careful this is.
Suppose a file has two sealed sections — a cheap one and an expensive one. A clever holder might take the expensive ciphertext, relabel it as the cheap one, and try to open it with the cheap key. Or the engine itself might glitch and hand out the wrong key for the wrong section. Either way, you’d hope the secret stays shut.
It does, because each key is welded to exactly one section. When a section is sealed, the engine bakes that section’s identity into the lock itself — into the cryptographic seal — so the key and the section are bound together at a level no relabeling can fake. Give the right key to the wrong section, move the ciphertext around, hand out a mismatched key by accident or on purpose — and the lock simply doesn’t open. Not with garbled, wrong contents. With a clean, uniform failure, the same closed error as any other failure.
And the name of each lock is no secret at all. It’s mechanical — derived openly from the section’s path, plainly readable, nothing hidden about it. The name of the lock is public. What stayed home is the handful of bytes that open it. Knowing a lock’s name gets you precisely nowhere.
the dead-man switch
Now the property that surprises people most, and the reason this approach is quietly stronger than anything that ships the key.
Because every copy of your file — the one you emailed, the one on a USB stick, the one a stranger forked and passed along — reaches back to the same key, held in the same one place, you can revoke them all at once. Delete that one key from the store, and every copy everywhere goes dark in the same instant. There’s no key left to fetch, nothing left to decrypt. The sealed sections become permanent noise, simultaneously, no matter where they’ve drifted.
This is the real power of keeping the key home rather than in the file. It isn’t a remote wipe — you can’t reach across the world and erase files you no longer hold. It’s the quieter, stronger thing: the files stay exactly where they are, untouched, and simply stop meaning anything. Keys are kept per section, too, so cutting off one secret never unlocks the rest.
what the seal does not do
Honesty is the real trust here, so a few plain limits.
This is access control, not a magic leash. The seal decides whether you get the key — not what you do once you have it. A recipient who is genuinely allowed in, gets the key, and reads the plaintext can keep that plaintext. Anyone who promises software can control what you do after you can read the bytes is selling you the same password-box theater from the top of this page.
And the key lives at the runtime. If that engine is gone, the key is gone, and the ciphertext is permanent noise — even to you. The same delete that lets you cut off a stranger can cut off yourself. So keep an unsealed copy of anything you truly can’t afford to lose.
That’s the whole strange, lovely trick. You hand someone the entire thing, copyable forever, and one part of it stays locked — not because you’ve hidden a key cleverly, but because the key was never in your hands to give. It’s a decision, made fresh, somewhere else, every time the door is knocked on.