Customer separation
Scope credential access to the customer behind each agent.
Integration guidance ↗For teams building AI agentsYour agent needs access.
Your agent needs access.
Not the secret.
For teams building AI agents, let the agent use your services without showing it the real API key.
HOW ACCESS WORKSLet the agent ask.
Let the agent ask.
Let your tool do the work.
The agent asks your software to act. Your software keeps the real key out of the conversation.
STEP 01 / THE AGENTGive the agent a fake key
Decoy (a believable fake secret or message) or reference. No live credential.
STEP 02 / YOUR SOFTWAREThe agent calls your tool
Check the request. Use the real key only inside software you control.
STEP 03 / THE SERVICE-SIDEYour tool uses the real key
The service receives the real key. The agent does not.
01 / Architecture
Keep real keys out of chat.
Keep the model and the live credential on different sides of the same tool call.
01 / Agent contextDecoy or reference
The model sees material you are prepared to expose, not the live credential.
02 / Trusted runtimeResolve the real key
Your tool enforces access to the real control file (the file that selects which message opens) and resolves the credential.
03 / ProviderAuthorised request
The tool uses the real credential without putting it in the model's context.
Separate detection path Registered fake → monitored decryption → alert Your integration handles rotation.
Protection depends on the agent being restricted to decoy material. Authorised-tool misuse and trusted-runtime compromise are outside this boundary. Full threat model →
02 / For your team
Fit your team’s requirements.
Choose the controls your deployment needs. Plan eligibility and limits are listed on the pricing page.
Keep your secrets manager
Add a deniable layer alongside your existing storage and access controls.
See the fit ↗Decoy generation
Create plausible structured decoys for the material your agents handle.
Explore decoys ↗Monitored tripwires
Register a fingerprint, a unique identifier for a decoy. Get alerts when a monitored decryption service observes it.
Detection boundaries ↗Customer-controlled keys
Use AWS Key Management Service (KMS) for BYOK (bring your own encryption key) and the operational model for your team.
BYOK walkthrough ↗Audit and response
Send verified event notifications (signed webhooks) to your tools and review the activity log.
Audit guide ↗03 / Start with your stack
Choose where the work runs.
Software development kits (SDKs) run in your app. Hosted APIs are online services. Model Context Protocol (MCP) connects agents to tools. Choose what may leave your systems.
Local SDKs
TypeScript, Python, Go and Rust. Run encryption inside your own application, without sending inputs to us.
Choose your language ↗Framework guides
Patterns for LangChain, CrewAI, OpenAI Agents and the rest of your stack.
Browse integrations ↗Hosted API + MCP
Follow the API quickstart and MCP setup guide. Keep live credentials outside model context.
Open developer docs ↗04 / Detection, precisely
A signal. Then your response.
A provider rejecting a fake key is not automatically a deny.sh detection event. Offline decrypts are not hosted observations.
01Armed decoyFingerprint registered
02Monitored decryptEndpoint observes it
03Your responseAlert to your workflow
Connect your rotation workflow to respond to an alert. Revocation depends on your integration and credential provider.
Implement tripwires ↗05 / Questions before code
Know what you are adopting.
The construction and its limitations should be inspectable before you integrate.
Does a password choose real or decoy?
For web and SDK encryption, both passwords are required together. The control file selects the plaintext. Switching control files does not change the password pair.
See the construction ↗Public construction and verification
Read the source, run the verification tools and review the construction’s status in the limits and scope section.
Review the evidence ↗Architecture questions
Questions before you choose.
What resolves the real key, what a decoy can tell you, and where the boundary ends.
Does my employee or agent still get the real key when legitimately working?
Your authorised tool runtime resolves the real credential and uses it for the provider call. The model can receive the result without receiving the credential. This depends on your integration keeping the real control file and passwords outside model-accessible tools, context, logs, and responses. Employees can retain access through your existing permissions.
How do you tell a prompt injection apart from a real request?
deny.sh does not classify a prompt as malicious to choose a plaintext. Your runtime enforces access to the real control file. A model restricted to decoy material cannot resolve the real value through that path. An alert means an armed fingerprint was observed at a monitored deny.sh decrypt endpoint, not that malicious intent has been proven. Authorised-tool misuse remains a separate risk.
Where does the control-file decision live?
In your trusted runtime and its access policy, not in the model. For web and core SDK encryption, both passwords are always required together; the control file selects real or decoy plaintext using the same password pair. Keep the real control file protected and expose only the intended decoy or reference. The protect-seed wizard and Telegram bot use a different wrapper, with each control file bound to its own matching password.
What if my existing proxy already keeps keys private?
A correctly enforced proxy is a sound baseline. Keep it. deny.sh adds a deniable representation and optional monitoring of armed decoy fingerprints. It does not make every proxy failure safe: if a bug exposes the real control file and passwords, or the resolved key, the protection is lost. It is useful only where you can maintain that separate boundary. Compare the layers.
Won't an attacker test the leaked key against the live API?
Yes. A provider can reject a fake credential, revealing that it does not work there. That provider request is not automatically a deny.sh tripwire (a monitor for use of an armed decoy) event. Detection requires an armed fingerprint to be observed at a monitored deny.sh decrypt endpoint. Connected alerts and rotation can support a response, but neither is guaranteed to complete before the attacker tests or reads a value.
Isn't this just Canarytokens or honeytokens?
Honeytokens and canaries are detection techniques; their visibility depends on where and how a token is used. deny.sh also offers a cryptographic representation in which one ciphertext (the encrypted data) can yield a real or chosen decoy plaintext, selected by the control file. Hosted tripwires are a separate monitoring layer. Neither approach makes a fake API key valid or guarantees that external evidence cannot distinguish a decoy. They can be used together.
Review the threat model and cryptographic construction before choosing your deployment.
Limits and scope
What to know before production.
The construction and verification tools are public. An independent cryptographic audit is planned and is not complete. Cyber Essentials covers organisational controls, not the cryptographic construction.
Tripwires observe registered decoys at monitored deny.sh decrypt endpoints. A provider rejecting a fake key and offline decryption are outside that path.
Keep real credentials inside trusted tools. This boundary does not prevent misuse of an authorised tool or compromise of its runtime.