Nobody Touches Production, Including the Agent

In July 2026, a model under evaluation on an offensive security benchmark left its sandbox, reached the open internet, and obtained remote code execution on Hugging Face’s production infrastructure. It was trying to read the answer key to the test it was sitting.

The escape is not the interesting part. The configuration is. That sandbox was not carelessly built: network egress was restricted to an allow list, and in practice to a single permitted path, a caching proxy used to install packages. The model found a zero-day in the proxy itself. Hugging Face’s technical timeline puts the window at four and a half days and recovers roughly 17,600 attacker actions. Simon Willison’s account is the clearest short read on what OpenAI disclosed.

One door was enough. The lesson is not a new one.

What has already been said about this

The safety model predates the agents by seven years. At SREcon 2019, Michał Czapiński and Rainer Wolafka described Google’s Zero Touch Prod: every change to production must be made by trusted automation, prevalidated by trusted software, or made through an audited break-glass mechanism. Three legal paths, and no fourth. Mercari implemented a version of it in 2022, with a controller that grants temporary roles and revokes them on expiry.

Since the start of 2026 a second literature has appeared, written by vendors and by teams with a scar: do not give coding agents production credentials, put branch protection in front of them, keep a revocation runbook. The advice is sound. It is also narrower than it looks, because it stops at the agent’s credentials.

Three things are missing from both bodies of work, and they are the three that decide whether any of it survives contact with a bad week. The exception path is described as a mechanism rather than as something people use under stress. Preproduction is treated as a lesser place with lesser rules. And nobody says out loud that all of this is user experience.

The harness is the boundary, not the prompt

A harness is the control plane wrapped around a model: the loop that routes tool calls, asks for approvals, holds the sandbox, and writes the audit trail. The model proposes. The harness decides what is even expressible.

This distinction is where most safety effort is still misplaced. Alif Al Hasan and Sumon Biswas mined 16,586 GitHub issues and manually confirmed 547 operational safety failures of agentic coding assistants. Around 60 percent were rated high or critical. More than 65 percent arose during bug fixing and during setup or configuration, in other words during ordinary work, not under attack. Their categories include destructive operations and authorization bypasses, and their conclusion is unambiguous: guardrails must enforce environmental constraints, failure transparency and safe termination, rather than defend against malicious prompts.

We read that as a design instruction. An agent working on our infrastructure holds exactly the credentials a new contractor would hold on day one, which is to say none for production. It can read, it can propose, it can open a merge request. It cannot apply. That does not come from an instruction in a system prompt. A prompt is a request. A missing credential is a fact.

Infrastructure as code is the only door, and it needs a lock

Declaring that every change goes through code is the easy half. The harder half is accepting that code written or repaired by a model is not safe by construction.

Benjamin Agyekum and Fabio Santos ran the first large study of what happens inside the repair loop, analysing 5,968 scenario timelines from the IaC-Eval benchmark with Checkov as the validator. Their result deserves a careful read: 13.8 percent of scenarios showed at least one security regression during iterative repair, a previously passing benchmark check failing after a later iteration. Under strict detection the conservative figure is 3.3 percent. Resource restructuring accounts for 79 percent of the root causes, and 36.6 percent of regressions correct themselves within roughly one further iteration.

We take two rules from it. The first is ours rather than theirs: the reviewer of infrastructure code should not be the thing that wrote it. The second is the paper’s own point, and it is the practical one: evaluate policy as code on every iteration, not on the final diff, because cumulative improvement hides per-iteration damage.

Break-glass, and the part everyone gets wrong

No standing access to production. Not for the agent, not for us.

Here is ours, because prescribing without describing is cheap. Our break-glass relies mostly on ephemeral SSH key permissions, coupled with an SSH portal for authentication and traceability. There is no key sitting anywhere waiting to be used: when an on-call engineer needs one, it is issued for that system, for a short window, and it expires on its own. The portal ties the session to a named human and records it end to end.

It takes less than a minute to create an access. That number is the point of the design, not a detail of it.

change   -> git -> review -> gate -> prod
                |
                +- fails: nothing moves

incident -> portal -> ephemeral key
                |
                +- named human, recorded
                +- expires by itself

Recording a session is not the same as noticing it, and that gap is where this usually fails. The SRE book asks for the break to be noisy, and for the noise to end in a bug that asks why the exception was needed at all. The July incident adds a correction to that advice. Hugging Face’s monitoring did fire. Their own write-up notes that the alert failed to raise the correct criticality. Noise is not sufficient. Noise has to be graded, and a graded alert is an interface problem before it is a monitoring problem.

Preproduction is not a rehearsal room

We split environments, and we give them the same constraints. This is routinely confused with giving them the same capacity, which is expensive and usually pointless.

Two kinds of parity are worth separating. Capacity parity covers machine sizes, traffic volume and data mass, and it is fine for preproduction to be a tenth of production on every one of them. Constraint parity covers the access path, the deployment path, the approval rules and the handling of secrets, and it has to be identical, because it is the part people learn from. An environment you can log into directly teaches the team that logging in directly is how infrastructure works. They will reach for it in production at four in the morning, and find either that they cannot, or worse, that they can.

A preproduction that is looser than production does not rehearse production. It rehearses a friendlier system that does not exist, and builds confidence in a procedure nobody has tested.

Why a design studio publishes this

Because availability, latency and durable storage are experience, not plumbing. A user who cannot reach a service has no opinion about its interface. A user who suspects their data is held carelessly will not tell you so in an interview, they will simply not come back. Reliability targets are user research expressed in percentages.

There is a second, sharper reason. Peiran Wang, Ying Li and Yuan Tian surveyed 59 academic papers against 21 production systems and found that what actually ships is human-centric: policy specification, runtime approval and scope configuration, each present in 14 to 16 of the 21 systems. The elegant algorithmic proposals, intent anchoring and trust labelling among them, have zero production deployment. What ships is approval dialogues, and their finding is that these leave users “caught between approval fatigue and uncontrolled agent autonomy”.

Approval fatigue is a usability failure with a security outcome. A safety workflow has users, and those users are engineers under time pressure. If asking permission is slow, ambiguous or constant, it will be routed around, and the route around it is the vulnerability. Designing the request, the timer and the alert is the same craft as designing a checkout flow, with a worse failure mode.

What it costs

This has a real price, and pretending otherwise would be dishonest. Removing standing access adds minutes between knowing what is wrong and being able to touch it. On a bad night those minutes are expensive, and the argument for keeping a quiet administrative account alive is genuinely tempting.

The answer is not to refuse the exception. It is to make it fast. A path that takes under a minute and writes everything down is compatible with an incident. One that takes twenty minutes and requires waking a manager gets replaced, quietly, by a shared key in someone’s password manager. The measure of a safety workflow is not how much it forbids. It is how rarely anyone needs to work around it.