A coding agent finishes a refactor at 2am, and to verify it the agent reaches straight into the production database with a connection string somebody pasted into its config a month ago. Nobody approved that read. Nobody can say which rows it touched. That is the default state of production access for AI coding agents like Claude, and it fails in a handful of predictable ways before it ever fails in a surprising one.
Start with the pitfalls, because the correct design is mostly the result of refusing to repeat them.
The pitfalls that show up first
- Standing credentials inside the agent. The agent holds a long-lived key or connection string to a production system. It can reach that system at any time, for any reason, whether or not a task needs it. Standing access has no resting safe state.
- Access the agent can widen. If the agent process also holds the configuration that decides what it may reach, a confused or compromised agent can expand its own reach. The thing being controlled controls the control.
- No task boundary. The agent runs in a loop and the access never closes between iterations, so there is no point where you could say this grant ended and that one began.
- A record the agent writes about itself. If the only log of what the agent did lives inside the agent, a compromised agent can edit it. A log a process keeps about itself is a claim, not evidence.
Each pitfall has the same root. The boundary that should govern production access sits inside the agent process instead of outside it.
What production access for an agent has to require
Turn the pitfalls around and the requirement appears. Production access for a coding agent has to be requested per task, scoped to the one system the task needs, granted for a short window, and recorded by something the agent cannot reconfigure. The agent should hold nothing at rest. Between tasks it should have no path to production at all.
The load-bearing requirement is the last one. The policy decision and the record both have to live outside the process the agent controls. If Claude can rewrite the rule that governs its own reach, or edit the log of what it reached, the control is theater. The boundary has to be somewhere the agent can connect through but never administer.
That requirement is the architecture hoop.dev is built around. Claude connects through hoop.dev, a Layer 7 access gateway, instead of holding production credentials. The agent asks the gateway for a connection to a database, an SSH host, a Kubernetes cluster, or an internal HTTP service. hoop.dev checks the request against the agent identity and the policy, opens a short-lived connection, and records the session on the gateway side. The agent never becomes a holder of the production credential, and it has no write path to the policy or the record. The getting-started docs cover fronting a production system, and the learn pages describe how access is scoped and recorded.
A worked example
Claude needs to confirm a migration ran by reading one table in the production database. Under controlled production access the sequence is: the agent requests a connection to that database through hoop.dev, policy matches the agent identity to an allowed scope, a short-lived connection to that one database opens, the agent runs its read, hoop.dev records the session, and the connection closes. The agent held no database credential at any point, and nothing about that access survives the task.
Contrast the same task with a connection string in the agent's config. The string grants the read now, it grants the same read next week, and if the agent is ever turned against you, the access is already live. One model ends access when the task ends. The other leaves a door open and trusts nobody walks through it.
A quick test for your current setup
Ask one question: if your coding agent were fully compromised this minute, what production systems could it reach without asking anyone, and could it erase the evidence afterward? If the answer to the first is more than nothing, you have standing access. If the answer to the second is yes, your record lives in the wrong place. Both are fixed by moving the boundary outside the agent.
FAQ
Can't I just give the agent a read-only production credential?
Read-only narrows what can change, not what can leak. A standing read credential is standing access to production data, which is exactly what an incident exposes. Scope the access per task and let it expire instead.
Does routing production access through a gateway slow the agent down?
The added cost is the connection hop, which is the same hop you take on to remove standing credentials. In exchange every production access is scoped, time-boxed, and recorded.
hoop.dev is open source. To put production access controls in front of the systems your coding agent reaches, start with the repository on GitHub.
