Per-tenant deniability
for AI agents.

Multi-tenant agent runtimes concentrate credentials at scale. One platform, hundreds of customers, thousands of API keys, exchange creds, OAuth tokens, persistent user memory. A single compromise of the storage tier or the host process leaks all of it.

Standard envelope encryption helps, but the recovered plaintext is still the truth. If someone obtains the master key, whether through subpoena, insider access, or runtime compromise, every tenant's secrets decrypt to the real value, with no plausible alternative the operator can surface in its place.

deny.sh changes that. The same ciphertext can decrypt to different plausible plaintexts under different control files. Each tenant gets isolated keys, scoped audit logs, and the option to run a fully offline copy of the same primitive when network access is gone or undesirable.

After signup the same shapes are reachable via the MCP deny_create_decoy call or the SDK generateDeniableControl() helper. The bundles above are the marketing surface; the engine + audit chain + per-tenant scoping that backs them is the Agents Infrastructure tier.

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

Local mode is your continuity story. If deny.sh is unreachable for any reason, planned maintenance, network partition, regulatory egress block, your agents keep encrypting and decrypting locally with the same primitive. Same ciphertext format. Same deniability properties. No vendor lock-in surface.

This is the same pattern the security community has been advocating for years ("keep secrets out of the model"), wired into a primitive where even the credential store is deniable. If an attacker compromises the deny.sh vault entry along with one tenant's decoy control file, they decrypt to the decoy first; the real plaintext is only reachable with the matching real control file (which is never co-located with the ciphertext and never in the agent's context).

If you'd rather run the whole stack on your own infrastructure, the source is open: the SDK is Apache 2.0 (free for any use) and the application layer (vault, MCP orchestration, hosted-API server) is AGPL-3.0 with a commercial licence available for proprietary self-hosting. Application-layer tiers from $25K/yr include white-label rights and per-deployment support.

Two kinds of tripwire, same alert surface:

• controlData kind — you hash a decoy controlData file. We check the hash before decrypt against the controlData parameter. Fires even if the attacker's password is wrong, because the hash match is independent of decryption. This is the surface for honeytoken control files dropped in README/wiki/S3 prefixes where an attacker would grab them and call /api/decrypt.
• plaintext kind — you hash a decoy plaintext (the bytes you'd want to look interesting if compelled to decrypt). We check the hash after a successful decrypt against the recovered plaintext. This is the surface the /agents “Arm This Bundle” CTA uses — it hashes the sample .env values your decoys would expose if an attacker phished them and decrypted with the wrong password pair.

The mechanism is one-way and privacy-preserving in both directions. Only the 32-byte hash and a free-form label cross the network. The real bytes stay offsite. The decrypt response shape doesn't change when a tripwire hits, so the attacker can't tell whether they tripped a wire.

Available on the Scale tier ($299/mo) and above. The webhook fan-out reuses the existing /dashboard/webhooks configuration, so no new integration plumbing for teams already on Datadog / PagerDuty / Slack.

Here is the precise mechanic, because it matters to the security buyer: deny.sh never rotates your keys. On a tripwire hit we send one signed webhook to an HTTPS endpoint you host. Your own code, on the other end, performs the revoke-old + issue-new + redistribute against your provider, using your credentials and permissions. deny.sh never sees the real key, old or new, and never holds a provider credential. If deny.sh could rotate your Stripe key, deny.sh would be holding your Stripe credentials — and the entire zero-knowledge story would collapse. It doesn't, so it can't.

Eligibility: auto-rotation requires a programmatically-managed secret (AWS/GCP Secret Manager, HashiCorp Vault, Stripe restricted keys, GitHub App tokens, IAM roles, etc). Hand-issued dashboard keys that can only be regenerated by hand cannot be auto-rotated; for those, deny.sh alerts you. Available on Agents Infrastructure ($999/mo), Enterprise, and Institutional tiers — the tiers that already run programmatic secret management.

1. 1~30s

   Get a tenant API key.

   Sign up at deny.sh/register, pick the Agents Infrastructure tier (or Free for 500 calls/month while you test). Your dashboard shows a dk_-prefixed key.

2. 2~30s

   Add the MCP server to your agent runtime config.

   Show code — ~10 lines, json

   // claude_desktop_config.json (or equivalent)
   {
     "mcpServers": {
       "deny": {
         "command": "npx",
         "args": ["deny-sh-mcp"],
         "env": { "DENY_API_KEY": "dk_your_tenant_key" }
       }
     }
   }

3. 3~60s

   Encrypt your first credential.

   Restart the agent runtime. From the agent's chat surface (or programmatically):

   Agent: please call deny_vault_store with name="stripe-prod",
   plaintext="sk_live_...", tenant_pw1=<set in env>,
   tenant_pw2=<set in env>

   In production you wire the tenant passwords into the agent's privileged tool layer, never into the LLM context.

4. 4~90s

   Wrap the credential resolver.

   Replace direct env reads with a thin wrapper that calls deny_vault_get. The wrapper performs the privileged call (Stripe / OpenAI / etc.) and returns the result, never the key, to the agent.

   // privileged tool boundary, NOT a tool the LLM calls directly
   async function getInvoice(invoiceId) {
     const stripeKey = await mcp.call('deny_vault_get', { name: 'stripe-prod' });
     const r = await fetch(`https://api.stripe.com/v1/invoices/${invoiceId}`, {
       headers: { Authorization: `Bearer ${stripeKey}` }
     });
     return r.json(); // agent sees this, not stripeKey
   }

5. 5~60s

   Generate a decoy for compelled-disclosure scenarios.

   For any vault entry, generate a decoy control file that decrypts to a plausible-but-wrong credential. Hand that one over under compulsion, audit the call, the real one keeps working.

   Agent: deny_create_decoy(
     name="stripe-prod",
     decoy_plaintext="sk_test_decoyKeyForDisclosure_4ABC..."
   )

Total: ~5 minutes from npm install to deniable-credential-resolving agent. Local mode (no network, no auth, same primitive) is identical except you skip step 1 and use the deny_local_* tools in step 4.

// npm install @anthropic-ai/sdk deny-sh
import Anthropic from '@anthropic-ai/sdk';
import { vaultGet } from 'deny-sh/client';

const client = new Anthropic();

const tools = [{
  name: 'get_invoice',
  description: 'Look up a Stripe invoice by id',
  input_schema: { type: 'object', properties: { id: { type: 'string' } }, required: ['id'] }
}];

async function runTool(name, input) {
  if (name === 'get_invoice') {
    // resolve credential inside the tool boundary
    const stripeKey = await vaultGet('stripe-prod', vaultPw);
    const r = await fetch(`https://api.stripe.com/v1/invoices/${input.id}`, {
      headers: { Authorization: `Bearer ${stripeKey}` }
    });
    return JSON.stringify(await r.json()); // model sees this
  }
}

const msg = await client.messages.create({
  model: 'claude-sonnet-4-6', max_tokens: 1024, tools,
  messages: [{ role: 'user', content: 'Look up invoice in_1Abc123XYZ' }]
});

# pip install openai deny-sh
from openai import OpenAI
from deny_sh.client import vault_get
import requests, json

client = OpenAI()

tools = [{
    "type": "function",
    "function": {
        "name": "get_invoice",
        "description": "Look up a Stripe invoice by id",
        "parameters": {"type": "object", "properties": {"id": {"type": "string"}}, "required": ["id"]}
    }
}]

def run_tool(name, args):
    if name == "get_invoice":
        # key resolved inside the tool boundary, not visible to the model
        stripe_key = vault_get("stripe-prod", vault_pw)
        r = requests.get(
            f"https://api.stripe.com/v1/invoices/{args['id']}",
            headers={"Authorization": f"Bearer {stripe_key}"}
        )
        return json.dumps(r.json())  # model sees this

resp = client.chat.completions.create(
    model="gpt-5.4", tools=tools,
    messages=[{"role": "user", "content": "Look up invoice in_1Abc123XYZ"}]
)

// npm install @mastra/core deny-sh
import { createTool } from '@mastra/core';
import { vaultGet } from 'deny-sh/client';
import { z } from 'zod';

export const getInvoice = createTool({
  id: 'get_invoice',
  description: 'Look up a Stripe invoice by id',
  inputSchema: z.object({ id: z.string() }),
  execute: async ({ context }) => {
    // vault_get runs in the tool boundary, not in the model context
    const stripeKey = await vaultGet('stripe-prod', context.vaultPw);
    const r = await fetch(`https://api.stripe.com/v1/invoices/${context.id}`, {
      headers: { Authorization: `Bearer ${stripeKey}` }
    });
    return r.json(); // model sees the invoice, not the key
  }
});

Same pattern wires into every major framework: dedicated 30-LOC reference pages live for Vercel AI SDK, LangChain, the OpenAI Responses API, CrewAI, LlamaIndex, AutoGen, Pydantic AI, and n8n. Cline / Continue / Cursor / Claude Desktop / OpenClaw all work via the MCP server config in the previous section. The deniable bit is the credential resolver, not the framework. Full index at /integrations.

Standard encryption protects data at rest. It doesn't protect against insider threats, server compromise, or any scenario where the attacker also obtains the key. Once the bytes leak together with a key, there is one plaintext to recover. Deniability is the answer to that specific failure: an at-rest leak or a coercion demand can resolve to a plausible decoy instead of the truth.

In the agent runtime the work is split across layers. Scoping keeps the real credential out of the model context in the first place. The realism engine makes every decoy shape-correct, so a recovered decoy looks exactly like the credential it stands in for. Decoy tripwires page your on-call the moment a decoy fingerprint hits a deny.sh-instrumented decrypt path. Deniability sits behind all of that, for the at-rest and coercion cases where the bytes and a key are already in hostile hands. Agent platforms are especially exposed because the credential store is concentrated, the runtime is autonomous, and the blast radius of a single compromise is the union of every tenant's secrets. deny.sh doesn't just encrypt the secrets. It scopes them, shapes the decoys, wires the tripwire, and makes the at-rest store deniable.

Read the whitepaper for the full cryptographic specification. Or talk to the team about your tenant model.