by Dmitry CreedThe loudest AI-dev thread of the week wasn’t about a model. It was about a key.
On July 23, OneCLI hit the Hacker News front page with a deceptively simple pitch: a network gateway that sits between your AI agents and the services they call, and — in the founders’ own words — “swaps the placeholder for the real credential, and forwards the request.” The agent asks to call an API; it never holds the API key. Days earlier, Infisical shipped Agent Vault , an open-source credential proxy built on the exact same premise, framing the goal as giving agents access to services without them reading any secrets. The comment section filled up with a dozen more takes on the same idea — gh-proxy, varlock, “just use OIDC” — everyone circling one conclusion at once.
Here’s the thesis they all landed on, and it’s correct: an agent is the last place a raw credential should live. An agent is non-deterministic, prompt-injectable, and — crucially — it writes things down. It puts secrets in memory, in session files, in the text it generates. As the OneCLI founders put it, agents “keep them in their memory and also write them down to local files and their sessions as plain text,” and can be “easily fooled into giving up those API keys.” Once a secret enters an agent’s context, you’ve lost control of where it goes next.
That’s the problem the whole feed rediscovered this week. It’s also the problem Forge decided couldn’t exist in the first place.
The tool you never had to bolt on
The pattern trending on HN is a gateway you add — a proxy you stand up, point your agent at, and hope every call routes through. It’s a good pattern. But a bolt-on proxy has a seam: the agent still runs somewhere, and if any path skips the proxy, the secret is back in the agent’s hands.
Forge doesn’t have that seam, because credential resolution isn’t a component you add — it’s how the platform runs a tool call. When a Forge agent calls an external API, queries analytics, or drives a browser, the platform injects the credential server-side, at the egress boundary. The value is substituted into the outbound request after it leaves the agent’s reasoning context. The agent composes the request with a reference to the credential — an alias — and the real secret is stitched in on its way out the door. The plaintext never enters the transcript the model sees, never lands in a session file, and never appears in the tool-result blocks that get persisted for audit.
You can watch this in the shape of the tooling itself. When a Forge agent needs a secret directly, the fetch writes the value to a locked-down (0600) file and returns only metadata — bytes, a hash prefix — to the agent’s context. The plaintext is on disk for a downstream step to read; it is not in the conversation. And the platform actively guards the exit: completions that contain credential-shaped strings are redacted and quarantined. The agent isn’t asked to be careful with secrets. It’s structurally prevented from carrying them.
One commenter under the OneCLI launch put the ideal out loud: “I happen to know a solution where credentials wouldn’t get to the agent. It’s structurally impossible.” That’s the bar. Structural impossibility, not disciplined intent.
Scoping, so a leaked reference is worthless
Keeping the secret out of the context is half of it. The other half is making sure the reference the agent does hold can’t be turned into leverage. This is where the week’s discussion got sharp — a top comment on the OneCLI thread pushed back that you’re “still giving the agent a static token that can be exfiltrated and used elsewhere.” It’s the right question to ask of any credential-fronting scheme.
Forge’s answer is multi-axis scoping. Secrets and egress are restricted per agent, per runtime, per workflow, and per team — so a credential reference is only meaningful inside the exact context it was granted to. We proved the load-bearing version of this with browser agents: an agent drove a real Chrome inside an isolated stack , and the same scoped token, replayed against production infrastructure, returned a hard HTTP 401. Not rate-limited — structurally rejected. A reference that escapes its scope doesn’t unlock anything, because it was never a key to begin with; it was a coordinate that only resolves inside its own boundary.
Human-in-the-loop is a network fact, not a prompt
The third pillar the HN crowd converged on was approval — a human gate on sensitive actions, enforced below the agent so it holds no matter what the agent does. OneCLI enforces it at the network layer precisely so it survives whether the agent “goes through MCP, CLI, curl, or code it wrote on the fly.”
Forge has been making that same argument in a different room. When an agent discovers follow-up work, it doesn’t get to spawn that work itself — the action waits at a human Approve gate . The agent proposes; a human authorizes. Combine the three and you get the full boundary: the agent never holds the secret, the reference it does hold only resolves inside its scope, and the consequential actions wait for a human. Each layer covers a different failure of the one above it.
The takeaway
This week the industry wrote the thesis down in public: agents shouldn’t hold raw credentials, so front them at the network, scope them tightly, and gate the risky calls behind a human. It’s the right thesis. We didn’t need to bolt a new tool onto Forge to satisfy it — the platform resolves credentials server-side at the egress boundary as a matter of course, so the secret was never in the agent’s context to lose. The best way to keep an agent from leaking a key is the same as it’s always been for people who’ve done security for a while: don’t hand it the key. Hand it a placeholder, and swap in the real thing after it’s out of reach.
Try it
See the Workflow Engine for what runs the loop, revisit how we contain browser agents with a scoped token that 401s against production , or reach out at [email protected] if you want autonomous agents that do real work without ever holding your keys.