What does a coding agent actually need to reach right now, and what should happen the instant it reaches for something it should not? If you cannot answer both for Claude, the guardrails are missing. The hard part is not deciding you want guardrails. The hard part is knowing exactly what they have to cover before you trust them.
So this is a checklist. Six things real guardrails around an AI coding agent have to cover, what each one means in practice, and how to tell when it is missing.
The six things guardrails must cover
- Identity. The guardrails tie to a specific agent identity, not a shared service account. If two agents look identical at the access layer, no rule can treat them differently.
- Scope. The agent can reach only the systems a task needs, named down to the specific database, host, or service. A guardrail that allows the whole network is a guardrail in name only.
- Time. Access opens for the task and closes on its own. Standing access is the absence of a guardrail, however tidy the policy looks.
- Approval. Higher-risk reach routes through a human or a policy decision before it is granted. Low-risk reads pass automatically so the agent stays fast where it is safe.
- Masking. Sensitive data is masked inline on the way back, so the agent works with the shape of the data and not the real values.
- Record. Every request, decision, denial, and session is written somewhere the agent cannot reach. A guardrail you cannot reconstruct later is one you cannot defend.
Run any agent setup against that list. Most fail on the last item first: the only record of what the agent did lives inside the agent, so a compromised agent can rewrite its own history.
Why guardrails have to live outside the agent
The six items are not independent, and they share one precondition. Every one of them has to be enforced by something the agent does not control. If Claude can edit the policy that scopes it, mint its own access, skip the masking step, or rewrite the record, then identity, scope, time, approval, masking, and recording are all suggestions. The guardrail is only a guardrail if the agent can run into it but cannot move it.
That requirement, controls enforced outside the process they constrain, is the architecture hoop.dev is built around. Claude connects through hoop.dev, a Layer 7 access gateway, instead of holding credentials to your systems. The gateway is where identity is checked, scope is enforced, access is time-boxed, approvals run, data is masked inline on the response, and the session is recorded. The six checklist items stop being parts you wire together and become properties of one access path. The getting-started docs cover fronting a system, and the learn pages go into how the controls are applied per connection.
A worked example of the checklist in action
Claude requests a connection to an internal billing service to reproduce a bug. The request carries the agent identity. Policy says this agent may reach that service for reads, so it matches the scope. The grant opens for ten minutes. Because the endpoint returns customer records, hoop.dev masks the sensitive fields inline. The session is recorded on the gateway side. Ten minutes later the access closes. Six guardrails, one connection, none of them administered by the agent.
Where the checklist usually fails
- Scope without time. A tight allow-list on access that never expires is still standing access.
- Approval on everything. Gating every harmless read trains approvers to click yes. Reserve approval for reach that deserves the friction.
- Record the agent can edit. A log inside the agent's trust boundary fails in exactly the scenario you keep logs for.
FAQ
Are guardrails the same as just telling the agent what not to do?
No. Instructions in a prompt are advice the agent can ignore or be tricked past. Guardrails are enforced outside the agent at the point it connects to a system, so the limit holds even when the agent misbehaves.
Do guardrails make the agent meaningfully slower?
The agent gains a connection hop and, for high-risk reach, an approval step. Everyday low-risk access passes automatically. The cost buys scoped, masked, recorded access in place of standing credentials.
hoop.dev is open source. To put enforceable guardrails around the systems your coding agent reaches, start with the repository on GitHub.
