What a Credential Vault Can and Can't Do for AI Agent Security

AI agents are making real API calls to real services: payment processors, cloud providers, code repositories, email systems. That means they need credentials. And right now, most teams hand those credentials over as raw API keys in environment variables.

Dittwo exists to fix that specific problem. But we've seen too many security tools launch with vague promises and no honest discussion of limitations. So here's ours.

What Dittwo actually does

Dittwo is an HTTP gateway that sits between your AI agent and the APIs it calls. You store credentials in an encrypted vault (AES-256-GCM, decrypted only at request time). Agents get a proxy URL and an access token. When an agent makes an HTTP call, Dittwo matches the destination against host and path patterns, injects the correct credential, and forwards the request.

The result: your agent never holds a real API key in memory.

That's it. That's the product. Everything else follows from this one property.

What this protects against

Credential exfiltration via prompt injection. The OWASP Top 10 for LLMs ranks prompt injection as the #1 risk. A common attack pattern is tricking an agent into making an HTTP call to an attacker-controlled endpoint, leaking whatever credentials the agent has access to. If the agent doesn't have real credentials, there's nothing to leak. Dittwo makes this entire attack class a dead end.

Credential sprawl. When you have 5 agents across 3 environments, each with their own copy of your Stripe key in an .env file, rotating that key becomes a multi-hour project. With Dittwo, you rotate it once.

Blast radius from a compromised agent. If one agent is compromised, you revoke its access token. Other agents keep running. No key rotation needed across your entire fleet.

Lack of visibility. Without a gateway, you have no idea which agent called which API and when. Dittwo logs every request with agent identity, destination, and timestamp.

Accidental misuse in development. Junior dev spins up a new agent against production APIs? The agent only gets access to whatever you've scoped to its token. No surprise charges.

What this does NOT protect against

This is the section most security tools skip. We won't.

API misuse through legitimate access. If you grant an agent access to Stripe, Dittwo will faithfully inject your Stripe credentials into every request to api.stripe.com. If the agent hallucinates a charges.create call, that call goes through. Dittwo prevents credential theft, not credential misuse. These are different threat vectors requiring different controls.

For misuse, you need rate limiting, approval workflows, and API-level permissions (OAuth scopes, IAM policies). We're building rate limiting and approval workflows into Dittwo, but they're not shipped yet. Today, you should pair Dittwo with proper API-level access controls.

Proxy bypass. If an agent can make HTTP calls that don't go through the proxy, Dittwo can't intercept them. This is a network configuration problem. In Docker or Kubernetes, you can enforce proxy usage through network policies. On a bare host, you need iptables or equivalent rules. Dittwo doesn't solve network isolation for you. The same failure mode is far worse for gateways scoped to a single protocol, which is why we enforce at the network layer instead.

A fully compromised host. If an attacker has root on the machine running Dittwo, they can read credentials from the gateway's memory at request time. Dittwo raises the bar significantly (credentials are encrypted at rest, decrypted only in the Rust gateway's memory for the duration of a request), but it's not magic. Hardware security modules (HSMs) and TEEs address this threat, and they're on our long-term roadmap.

Malicious tool use that doesn't involve credentials. An agent with access to a shell can do plenty of damage without any API keys. Deleting files, modifying data, sending messages through already-authenticated sessions. This is a different problem. Projects like Sage and NanoClaw address it by sandboxing agent execution environments. Dittwo and these tools are complementary.

Where Dittwo fits in a security stack

No single tool secures an AI agent deployment. Here's how we think about the stack:

Execution isolation controls what the agent can do on the host. NanoClaw runs agents in containers. Sage intercepts tool calls. IronClaw sandboxes code execution.

Credential isolation controls what secrets the agent can access. This is Dittwo. The agent talks through a proxy, never holds real keys, and you have a full audit trail.

API-level permissions control what the agent can do with legitimate access. OAuth scopes, IAM roles, API rate limits. This is your responsibility at the API provider level.

Observability gives you visibility into agent behavior. Dittwo provides this for HTTP calls. You likely need additional logging for local actions.

Dittwo covers one layer. It covers it well. But you need the other layers too.

The roadmap

Based on feedback from our Hacker News launch and conversations with teams running agents in production, here's what we're building next:

Approval workflows. Before an agent's request hits the API, route it to a human for approval. Configurable by host, path, method, and agent.

Rate limiting. Per-agent, per-API rate limits. If an agent starts making 100 Stripe calls in a minute, cut it off. Update: rate limiting is now shipped.

Vault integrations. Pull credentials from 1Password, HashiCorp Vault, AWS Secrets Manager instead of storing them in Dittwo directly.

OpenAPI-aware routing. Upload an API's OpenAPI spec and Dittwo can enforce which endpoints an agent is allowed to call, not just which host.

Try it

If you're running AI agents that make HTTP calls to external services, Dittwo takes about 2 minutes to set up: sign up at app.dittwo.sh, add your keys to the vault, and run your agents through the gateway.

We'd rather you understand exactly what you're getting than be surprised by what you're not.