Audio brief · 2 min
Case Study · Agent infrastructure

The agent cannot leak what it never had

AI agents need access to repositories, clouds, SaaS APIs, and servers. This makes the agent the most credential-exposed worker in the building. This platform provides that access without giving the agent a real secret. It moves the credential boundary from the filesystem to the network. Built by a Pit Wall of two, an AI Product and a Forward Deployed Engineer, with the agent writing the code, at roughly 5× faster delivery and about 10× the volume of work for the same budget.

The challenge

Isolation protects the host, not the secret

The base open-source platform already handles isolation well. Each agent runs in its own locked-down container. It runs as non-root, with allowlisted mounts and no direct route to the internet. This limits what the agent can reach and break.

Isolation does nothing for a token already inside. Prompt injection can persuade an agent to reveal a real credential. A careless commit can publish it, or a debug log can store it.

The container registers no failure. From its point of view, nothing escaped. The credential did.

The solution

Substitutes stay inside, real credentials stay at the edge

The agent gets a fake token with the same format as the real one and randomized content. All agent traffic passes through a proxy on the host. At the network edge, it swaps the fake for the real credential only for approved destinations. Real secrets stay encrypted at rest outside any path a container can mount.

A leaked substitute authenticates nowhere. It can be invalidated without rotating the real credential. It still looks like a secret, so scanners and human reviewers catch it. Detection works without damage.

  • Refresh stays on the host. The host handles expiry and rotation. Refresh tokens never enter the container. The agent can be shielded from ever seeing an auth failure.
  • SSH is isolated, not substituted. The host authenticates, then hands the container an already authenticated connection socket. Passwords, keys, and passphrases never enter the container. Ordinary ssh, scp, and rsync still work. Agent forwarding is hard-disabled, and host keys are pinned.
  • Credentials have group boundaries. Each credential belongs to specific agent groups. Cross-group use needs an explicit bilateral grant. Every swap can be audited through a traffic log that redacts tokens.
The team

Two people and the agent

The platform is built by a Pit Wall of two: an AI Product role and a Forward Deployed Engineer, with the Silicon Software Engineer writing the code. There is no separate Pit Crew. The person who works out what the boundary has to guarantee is the person who implements it, which matters on security work, where a specification that loses precision in a hand-off loses the property it was protecting.

On the delivery estimates, that shape is worth roughly 10× the volume of work for the same budget and about 5× faster delivery, at held quality. These are delivery estimates comparing two staffing models, not a parallel measured build.

The RACE pattern

Agents get capability, humans keep authority, by mechanism

RACE Programming draws a consistent line: the agent executes, and a human keeps authority. This platform enforces that line one layer down, in the network. The boundary is a mechanism the agent cannot reach around. It is not a policy the agent could be talked out of.

The key security property here is a testing property. Substitutes need no hiding, so a leak becomes visible and harmless. Secret-scanning tools help instead of needing workarounds.

An automated Definition of Done gates changes on the same principle. It replaces trust in a careful review with a visible, cheap failure. That gives you a basis to move fast.

The result

Running in our own delivery

The platform runs inside First Line Software today. Slack-integrated agents use it for real project delivery and marketing work. It is offered to clients as a foundation for their own agent deployments.

Out of the box, the proxy handles auth for on the order of seventy SaaS and cloud providers. A broker tier supports enterprise secret vaults. Security-critical modules carry roughly a one-to-one test-to-source ratio. Live end-to-end tests cover the credential swap path rather than mocks.

This is an internal platform, not a client delivery. It follows the RACE Programming framework. It forks a community-audited isolation model and adds the enterprise layer.

More case studies → · Read the framework →

FAQ

Frequently asked questions

What was built in this engagement?
A secure runtime for autonomous AI agents, built as a hardened fork of an open-source agent platform. The base platform already isolates each agent in a locked-down container: non-root, allowlisted mounts, no direct internet route. The addition is credential isolation: the agent never possesses a real credential of any kind. It receives format-preserving substitutes, and a host-side proxy swaps them for the real thing at the network edge, only for approved destinations.
Why is container isolation not enough?
Because isolation protects the host from the agent, not the credential from exposure. Once a real token is inside the container, prompt injection, a careless commit, or a log line can carry it out, and the container boundary never sees a problem. The fix is to move the credential boundary from the filesystem to the network, so there is no real secret inside to leak in the first place.
What happens if a substitute token leaks?
Nothing, and that is the point. A substitute authenticates nowhere and can be invalidated without rotating the real credential. But it still looks like a secret, so scanners and reviewers catch it in code, docs, or chat. You get detection without damage, which turns a security failure mode into an observable, harmless event. It is a testability property applied to security.
How is SSH handled, since a token swap is impossible there?
By isolating the connection instead of substituting a secret. The host authenticates and hands the agent a pre-authenticated connection socket, so passwords, private keys, and passphrases never enter the container in any form, while plain ssh, scp, and rsync still work normally. Agent forwarding is hard-disabled and host keys are pinned. HTTP tokens can be swapped mid-request and SSH cannot, so it needed a different mechanism: the design is per protocol, not one trick stretched thin.
Who built it, and how much faster was delivery?
A Pit Wall of two, an AI Product role and a Forward Deployed Engineer, with the Silicon Software Engineer writing the code and no separate Pit Crew. On the delivery estimates, roughly 5x faster at about 10x the volume of work for the same budget, with quality held. These are delivery estimates comparing the two staffing models, not a parallel measured build. The structural reason is the absent hand-off: on security work a specification that loses precision crossing from analyst to developer to QA loses the property it was there to protect, and here the person who defines the boundary is the person who implements it.
How does this relate to RACE Programming?
Two ways. In delivery, it is built the way the framework says to build: a Pit Wall of two with the agent executing, the team compression that produces the 5x and 10x figures above. In architecture, it is the same stance enforced at the network layer: the agent gets capability, never authority. In a RACE delivery the Silicon Software Engineer executes while humans own acceptance. Here the agent can reach every system it needs to do real work, and still holds nothing it could give away. Scoping is explicit, cross-group use requires a bilateral grant, and every swap is auditable, which is the same instinct as gating a change before a Pit Stop rather than trusting it.
Developed in the open

Help develop this

RACE Programming is a working framework, not a final answer. If this was useful, I would like your feedback: what you think is right, what you think is wrong, and what you would change. Disagree with any part, send a better version, or use it in your own work and tell me how it went. It improves faster when people develop it together.

Write to me: paul@raceprogramming.com