Treat prompt injection as a given, not a problem you will solve at the model. An AI coding agent reads files, tool output, web content, and tickets, and any of those can carry instructions you did not write. Assume some of those instructions will, occasionally, steer the agent. The operational question is not how to make the model immune. It is what the agent can actually do to your infrastructure once it has been steered. That is where prompt-injection risk in AI coding agents is contained or not.
This is a server-side, defensive framing on purpose. You harden the boundary the agent crosses to reach real systems, so that a steered agent runs into the same limits a compromised account would.
Why model-side defenses are not enough
Input filtering and model guardrails reduce how often injection succeeds. They do not reduce what a successful injection can reach, because the model is not where access decisions should be enforced. If a steered agent holds a broad standing database credential, the injection's impact is bounded only by that credential, which is to say barely bounded at all. The damage is a function of access, and access is governed below the model.
So the defensive posture is to assume the agent can be influenced and to ensure its access to infrastructure is constrained, recorded, and reversible regardless of why it issued a command.
Contain it at the infrastructure boundary
The control that matters is the one between the agent and your systems. It does not need to know whether a command came from a legitimate task or an injected instruction. It needs to enforce that the agent can only do what its scoped, just-in-time grant allows, route risky operations for human approval, and record everything so a steered session is visible.
An access gateway is built to be that boundary. With hoop.dev in front of the agent's database and infrastructure connections, a steered agent still authenticates as a named identity, still holds only task-scoped access, and still has every command recorded at the gateway. Be precise about what this does and does not address: hoop.dev does not read or filter the model's prompt or output, so it does not detect the injection itself. It governs the infrastructure actions the agent takes, which is exactly the reach an injection needs and the place to deny it.
The controls that blunt a successful injection
- Scoped, just-in-time access. A steered agent can only act within the grant it currently holds, so injected commands hit the same wall as any out-of-scope request.
- Approval on risky operations. Routing destructive or high-impact commands for human review means an injected "drop this" stops at a person, not a table.
- Command-level recording outside the agent. Every action is captured at the boundary, so a steered session is detectable and reconstructable rather than hidden in the agent's context.
- Inline masking. On connections that support it, sensitive fields are redacted in results, so an injection aimed at reading data gets less of it.
Stack these and a successful injection runs into the same wall a compromised low-privilege account would. It cannot reach beyond the current grant, its high-impact moves wait on a human, and whatever it does is recorded outside its own context for you to see and reverse. The model-side defenses still matter for reducing how often injection succeeds, but they are no longer the only thing standing between an injected instruction and your data. The boundary carries the weight, which is where you want it, because the boundary is the part you fully control and the part that does not have to be talked out of a bad decision.
FAQ
Does the gateway stop prompt injection?
No. It does not read the prompt or output, so it does not detect the injection. It contains the consequence by limiting and recording what the agent can do to infrastructure.
What is the single most effective control?
Removing standing access. A steered agent with only task-scoped, expiring access has little to act on, which caps the impact regardless of the injection.
Why route some commands for approval?
It puts a human between an injected high-impact instruction and the system, so the riskiest actions cannot execute silently.
You cannot make the model immune, so bound what a steered agent can reach. See scoped access and approvals on the hoop.dev getting started guide, and read the gateway code at github.com/hoophq/hoop.
