Your agent handles secrets.
Now it can protect them.

Deniable encryption for AI agents via MCP, SDK, or REST API. Same maths. Zero trust required.

↓
NEW

The problem with agent credential storage.

Your agent has API keys for Stripe, AWS, databases, third-party services. They're stored in environment variables, config files, or encrypted vaults. If the server is compromised, the attacker gets everything.

Standard encryption helps, but it has a fatal flaw: if someone compels you to hand over the decryption key, your agent's entire secret store is exposed. There's no plausible alternative to show them.

With deny.sh, the same encrypted credential store decrypts to dummy API keys under a different control file. Real keys stay hidden. The attacker gets valid-looking credentials that go nowhere.

Credential vaults

Encrypt your agent's API keys and tokens with deniable encryption. If the vault is compromised, the decoy control file produces dummy credentials that look real but aren't.

Sensitive tool outputs

Agent processes confidential data (financial records, medical info, legal docs). Encrypt the outputs. If compelled to decrypt, the decoy produces benign alternatives.

Multi-agent secret sharing

Split credentials across agents using Shamir's Secret Sharing. No single agent holds the full key. M of N agents must cooperate to reconstruct access.

Audit-safe logging

Log encrypted operation data with full audit trails. Compliance teams see encrypted records. Under deniable encryption, those records can produce innocent decryptions on demand.

MCP integration. One config block.

deny.sh ships as an MCP (Model Context Protocol) server - the standard way AI agents connect to external tools. Add it to Claude Desktop, OpenClaw, Cursor, or any MCP-compatible agent in 30 seconds:

{
  "mcpServers": {
    "deny": {
      "command": "npx",
      "args": ["deny-sh-mcp"],
      "env": { "DENY_API_KEY": "dk_your_key" }
    }
  }
}

Your agent gets these tools:

deny_encrypt
Encrypt any text. Returns ciphertext + control data.
deny_decrypt
Decrypt with control data + passwords.
deny_create_decoy
Generate new control data for a different plaintext. Same ciphertext, different truth.
deny_vault_store
Store encrypted data in the vault.
deny_vault_list / deny_vault_get
List and retrieve vault items.
deny_usage
Check API usage and plan limits.

Or use the SDK directly.

// Node.js agent
import { encryptBytes, decryptBytes, denyBytes } from 'deny-sh';

// Encrypt agent credentials
const creds = JSON.stringify({ stripe: 'sk_live_...', aws: 'AKIA...' });
const { ciphertext, controlData } = encryptBytes(
  Buffer.from(creds), agentPassword1, agentPassword2
);

// Create decoy credentials
const fakeCreds = JSON.stringify({ stripe: 'sk_test_dummy', aws: 'AKIAEXAMPLE' });
const decoyControl = denyBytes(ciphertext, agentPassword1, agentPassword2, Buffer.from(fakeCreds));

// Store both control files. Under compulsion, hand over decoyControl.
# Python agent
from deny_sh import encrypt_bytes, deny_bytes

creds = b'{"openai": "sk-proj-...", "db": "postgres://..."}'
ct, ctrl = encrypt_bytes(creds, "agent-pw1", "agent-pw2")

fake = b'{"openai": "sk-test-dummy", "db": "sqlite://test.db"}'
decoy_ctrl = deny_bytes(ct, "agent-pw1", "agent-pw2", fake)

Agent tier

$199
/month
  • 1,000,000 API calls/month
  • Vault (10,000 items)
  • Dead man's switch (50 switches)
  • Steganography API
  • Full audit log
  • Priority support + SLA
  • MCP server included
Get your API key

Free tier (500 calls) available for testing. All plans

Why deniable encryption for agents?

Standard encryption protects data at rest. It doesn't protect against compelled disclosure, insider threats, or server compromise where the attacker also obtains the key.

Agents are especially vulnerable because they operate autonomously. Their credential stores are high-value targets. A compromised agent server exposes every API key, every user secret, every tool credential the agent has ever touched.

deny.sh doesn't just encrypt your agent's secrets. It makes the encryption deniable. An attacker who gets the ciphertext and compels the key gets a valid decryption. Just not the real one.

Read the whitepaper for the full cryptographic specification.