Portunus - Secrets That Never Touch the LLM
Completed: Present
A secret broker between AI agents and a real vault — resolves credentials to a tempfile path or a command's result, never the raw value, enforced fail-closed at the tool boundary rather than by policy.
The Problem
Wiring an LLM/agent into real infrastructure means it inevitably needs to authenticate to things — cloud APIs, deploy targets, third-party services. Putting the secret directly in an env var or a prompt the agent can read means the model itself sees the raw credential — a real exposure surface across logs, transcripts, and the model's own context.
The Solution
Built Portunus, a secret broker that sits between an agent and an underlying vault and never lets the resolved value reach the agent's own context. Two primitives make this enforceable rather than just a policy: resolve-to-tempfile, which returns only a 0600-permission file path, never the value; and resolve-exec, which runs a given command with a secret substituted into its arguments and returns only that command's result, never the secret or the resolved command line. Both fail closed on anything ambiguous or not currently injectable. One CLI, one UI, and this MCP server all share a single implementation. Adjacent capabilities: leak-scanning across configured paths (agent transcripts, logs, shell history) for accidental secret exposure, reporting only the reference/file/line — never the value — and per-project vault bindings for routing different repos to different backend accounts and sync modes.
The Impact
Live and actively used across two real projects: this site's own deploy secrets and Firefly Events' CI/CD pipeline, both resolving against Google Cloud Secret Manager. Stated honestly rather than overclaimed: writing a brand-new secret currently lands in a local-encrypted vault only (no GCP/AWS write path yet), and rotation bindings exist as a concept but every provider currently reports as a stub — no real credential rotation has fired yet.