Deniability infrastructure
for AI agents.

Yes. Nobody is handed a fake key to work with. The real credential is resolved inside your tool boundary, the deterministic code that actually executes a call, and that path uses the real value to do the real work. What never holds the real value is the model's context, the part that reads emails, documents and user input and can be prompt-injected. Same credential, two doors: the legitimate runtime door opens the truth, the injectable model door only ever reaches a decoy.

We don't, and that's the point. deny.sh does not run a runtime classifier asking "is this prompt malicious?" That detection is unreliable and you'd never trust your secrets to it. The protection is architectural, not a yes/no judgement: the real secret simply never enters the surface that can be injected. There's nothing to decide per-request, because the only thing reachable from the injectable context is a decoy, by construction.

The selector lives in the control file you hold, never in the agent. The real password sits in your runtime / orchestration layer (the privileged code that runs a tool call or a DB query) and resolves the true plaintext there. The model only ever has a reference and the decoy control file. So deny_decrypt called from the legitimate path returns the real value; the same call reachable from an injected context returns a decoy, and the decrypt against it is logged. The agent has no theory of mind, it can't suspect a second plaintext that isn't in its context.

If you've genuinely quarantined the key and the agent can never reach the store, that proxy pattern is the correct baseline, and deny.sh sits underneath it, not instead of it. The delta is what happens when quarantine fails open (an over-scoped tool, a path traversal, a misconfig, a future capability). Quarantine is a prevention boundary; prevention boundaries fail open, and the day it fails the live key is in context. With the credential stored as a deny ciphertext, that same breach yields a believable decoy instead, and the decrypt pages your on-call. It also does the thing access-control structurally can't: make the disclosed value deniable under coercion. Quarantine reduces the odds of a leak; deny.sh makes the leak survivable. See the full architecture →

That test is the tripwire. The moment they try to use the decoy, two things have already happened: the decrypt that produced it paged your on-call, and on programmatically-managed secrets your rotation hook revoked the real key. So the attacker's own verification step is your earliest breach signal and your containment trigger in one. The decoy doesn't have to survive scrutiny forever; it only has to be believable for the seconds it takes them to reach for it. By the time it fails their test, the real credential is already dead and you already know. The breach you were dreading becomes the alert you needed.

Honeytokens are bait placed next to the real key: the live credential is still sitting there reachable, and the canary only tells you after something tripped on the decoy beside it. deny.sh inverts that. The real key is unreachable from the injectable surface in the first place (architectural, not bait), the value the attacker does get is a cryptographically indistinguishable decoy of the same credential (not an obviously-different tripwire token), and the alert fires its own rotation so containment is automatic. Honeytokens are detection bolted beside the asset; deny.sh makes the asset itself leak-survivable. You can absolutely run both.