Docs · Security
Built so the secret never lands in the pod.
A coding agent gets 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.
Three lines of defense
- Isolation - every pod is a disposable Podman container with its own filesystem, process space, and network egress. Nothing persists between runs unless you mount it.
- Injection - the pod never holds a vendor secret. It carries an opaque
poddle_…handle; the broker resolves it to the real credential and sets the authorization header on the broker→provider hop. - Redaction - on that same egress path the broker scans outbound bodies and scrubs stray secrets, so an agent can’t exfiltrate a key it read from your repo by pasting it into a prompt.
What a request actually does
The harness calls its provider exactly as it normally would - poddle just changes where the request goes and what authenticates it:
# the harness sees a broker URL and a handle, never a key
ANTHROPIC_BASE_URL = https://broker.local
ANTHROPIC_AUTH_TOKEN = poddle_9f2a… # opaque, revocable- The broker resolves the handle to the real credential in its sealed vault and sets the true authorization header.
- It scans the request body and redacts any stray secrets to
«redacted:poddle». - It reverse-proxies to the real upstream. The provider sees valid auth and a clean body; the pod never saw the key.
The egress knobs
Two template fields govern the redaction path. Set them once in a shared base and every pod inherits them.
egress - what the broker does with secrets in outbound bodies:
| Value | Default | Behavior |
|---|---|---|
redact | default | Scan outbound request bodies and replace stray secrets with «redacted:poddle». Traffic still flows. |
block | - | Refuse outbound requests that carry a detected secret instead of scrubbing them. |
off | - | No body scanning. Injection still applies; only the redaction pass is disabled. |
secret_scan - what happens if a mounted host path carries a credential file:
| Value | Default | Behavior |
|---|---|---|
warn | default | Print a warning if a mount carries a credential file, but start the pod. |
block | - | Refuse to start the pod if a mount carries a credential file. |
off | - | Do not scan mounts. |
And block_paths names host paths that must never enter a pod at all - a pod refuses to start if a mount would pull one in, so ~/.aws or ~/.ssh can’t leak by accident.
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.
- Not your provider key - it is never materialized inside the pod, only injected at the egress boundary.
- Not the secrets in the prompt - scrubbed before they leave the broker.
What poddle does not claim
The real credential is present on the broker→provider hop - that is unavoidable, since the provider must authenticate you. poddle’s guarantee is narrower and exact: the raw secret is never materialized inside the pod, and never rides in a body it shouldn’t. Revoke a handle at the broker and the pod is locked out immediately.