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 agent runtimes still push those secrets through plaintext logs, context windows, or persistent memory stores.

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 leaves the attacker with a clean either/or. They have the key, the file opens, the secret is theirs; or they don't, and they grind on it. Whichever way it falls, the leaked file has already confirmed a real credential is in there. The bytes give nothing back except certainty that they're worth attacking.

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. In a separated-control deployment, the agent can work against the decoy control file while the real control file is held by a separate process or kept off the box entirely. When the agent's working state leaks, the real key is not in that state.

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 10 tools:

• 3 local tools (encrypt, decrypt, deny) 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 audit log.

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.

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, the encryption call happens in the agent's own process with no network request.