Security

Built so the secret never lands in the pod.

poddle gives a coding agent everything it needs to be productive and nothing it can leak. The raw credential lives in the broker; the pod carries a revocable handle. If a pod is compromised, there is no vendor key to steal.

Get started See the flow

Three lines of defense

Isolation

Every task runs in a disposable, Podman-backed pod - its own filesystem, process space, and network egress. Pods are created on demand and destroyed on teardown; nothing persists between runs unless you mount it.

Injection

The pod never holds a vendor secret. It carries an opaque, revocable handle; the broker resolves that handle to the real credential and sets the authorization header on the wire, then proxies upstream. The raw key exists only on the broker→provider hop.

Redaction

On the same egress path the broker scans outbound request bodies and replaces stray secrets - cloud keys, tokens, private keys - with «redacted:poddle». An agent can’t exfiltrate a secret it read from your repo into a prompt.

What a request actually does

  1. The agent calls its provider as usual - ANTHROPIC_BASE_URL points at the broker, and ANTHROPIC_AUTH_TOKEN is a poddle_… handle, not a key.
  2. The broker gateway resolves the handle to the real credential in its sealed vault, strips the handle, and sets the real authorization header.
  3. It scans the request body and redacts any stray secrets to «redacted:poddle».
  4. It reverse-proxies to the true upstream. The provider sees valid auth and a clean body; the pod never saw the key.

The real secret is present on the broker→provider hop only - that is unavoidable, since the provider must authenticate you. What poddle guarantees is that it is never materialized inside the pod and never rides in a body it shouldn’t.

If a pod is compromised

A malicious dependency, a prompt-injected agent, a leaked pod - here is exactly what it gets:

  • An opaque handle revocable in one call and worthless anywhere but your broker.
  • A scoped, disposable pod no long-lived vendor keys on disk, in env, or in memory.
  • Your real provider key it is never materialized inside the pod - only injected at the egress boundary.
  • Secrets in the prompt body scrubbed to «redacted:poddle» before they leave the broker.

Identity & audit

Every pod is created under a real identity, and every action - who spun up what, which credential was used, and when - ties back to a person, not a shared token. Credentials are revocable at the broker in one call, so offboarding a teammate or rotating a key is immediate. Share a live pod and each driver still works through their own identity, keeping attribution per-person.

Compliance & residency

SOC 2 & ISO 27001
On our roadmap - the broker is built as a single, hardened, audited control plane to make certification a matter of evidence, not re-architecture.
DORA & EU AI Act
Per-user policy, revocable credentials, and a complete action trail map to the operational-resilience and traceability controls these frameworks require.
Data residency
Pods run on your own cloud or self-hosted compute, in the region you choose. The broker holds credentials in a sealed vault; your prompts and code stay on infrastructure you control.

Responsible disclosure

Found something? Email security@datadir.co. We acknowledge reports within two business days, credit reporters who want it, and will not take legal action against good-faith research. Please give us a reasonable window to ship a fix before public disclosure.