Your AI agent handles secrets. Does it handle them well?

Every AI agent that's worth anything eventually needs to handle sensitive data. API keys. Database credentials. Customer PII. Payment tokens. Encryption keys.

Most of them handle it terribly.

The problem with plaintext

Here's what typically happens when an AI agent needs to store a secret: it writes it to a file, a database, or a context window. In plaintext. Maybe with a comment that says // TODO: encrypt this.

The secret then lives in conversation logs, tool outputs, checkpoint files, and potentially the model's training data. It's copied, cached, and replicated across infrastructure you don't control.

Environment variables help at the OS level. Vault services help at the infrastructure level. But at the agent level, where the AI is making decisions about what to store and how to store it, there's been no standard answer.

Why standard encryption isn't enough

You could teach your agent to encrypt secrets before storing them. That's better than plaintext. But the threat model agents face isn't "someone tries the wrong key." It's leakage. The agent's own context gets exfiltrated by a prompt injection. The vault store gets dumped from a misconfigured database. A backup of the agent's persistent memory ends up on the wrong S3 bucket. A multi-tenant runtime leaks one tenant's keys to another.

In every one of those cases, encryption did its job: the bytes are still ciphertext. But standard encryption gives the attacker exactly one outcome. Either they have the key, the file opens, and the secret is theirs. Or they don't, and they keep trying. There is no third dimension to the problem.

Deniable encryption adds the dimension that's been missing for at-rest agent storage. The same ciphertext decrypts to different content depending on which control file the decrypting party holds. The agent itself only ever sees a decoy in its working memory. The real key sits behind a control file held by a separate process or held off the box entirely. When the bytes leak, what surfaces is the decoy. The real key never appears in the leak.

MCP: the agent integration standard

Model Context Protocol (MCP) is becoming the standard way AI agents connect to external tools. Claude Desktop, OpenClaw, Cursor, and a growing number of agent frameworks support it natively.

deny.sh ships as an MCP server. That means any MCP-compatible agent can encrypt, decrypt, store, and split secrets without writing any integration code. Add the config block, and the tools appear:

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

That's it. The agent now has access to 11 tools:

• 4 local tools (encrypt, decrypt, deny, shamir) that run entirely on the agent's machine with zero network calls. True zero-knowledge.
• 7 API tools (vault store/retrieve, usage check, etc.) for server-backed features like the encrypted vault and dead man's switch.

What this looks like in practice

Credential vaults. An agent that manages deployments can store API keys in the deny.sh vault, encrypted client-side before upload. If the vault is compromised, the attacker gets encrypted blobs that decrypt to decoy credentials.

Sensitive tool outputs. An agent that queries a database might receive PII in the response. Instead of logging it in plaintext, it encrypts the output immediately. The conversation log shows encrypted hex, not customer data.

Multi-agent secret sharing. A team of agents working on the same project can use Shamir secret splitting to distribute access. Any 3 of 5 agents can reconstruct a secret, but no single agent (or single compromised node) can access it alone.

Audit-safe logging. Every encrypt/decrypt operation is logged with timestamps and usage counts, but the plaintext is never stored server-side. You can prove to an auditor that secrets were handled, without revealing what they were.

The zero-knowledge guarantee

The local tools are the key differentiator. When an agent calls deny_encrypt, the encryption happens on the agent's machine using the deny-sh npm package. No API call. No network request. The plaintext never leaves the process.

This matters for compliance (GDPR, SOC 2, HIPAA) and it matters for trust. If your agent handles customer data, you need to be able to say: "the data was encrypted before it left the machine." With deny.sh's local MCP tools, that's provably true.