How are agent guardrails different from chat guardrails?

A chat guardrail evaluates one request with a human reading the output. An agent runs a loop of model calls with no human between steps, so the same content check has to run on every iteration, authorization has to attach per step rather than per session, and the sequence of calls carries risk that no individual call displays.

Do guardrails stop an agent from being prompt-injected?

They limit what a successful injection reaches. An injected instruction still enters the context window, and scoped tools, per-step authorization, and egress constraints mean the agent that has been convinced to exfiltrate a customer table holds a credential that cannot read it. The injection succeeds at the model layer and fails at the authorization layer.

Where should agent guardrails run?

Across several layers, and the split matters. Tool permissions belong in the database, the cloud IAM, and the filesystem. Loop budgets and content policy on the model call belong at the HTTP request layer, where every agent and every provider passes the same control point. Guardrails written inside the agent's own code govern only that agent and change whenever its code changes.

What is the minimum viable agent guardrail set?

Constrained egress so every model call has one route, per-agent identity so calls are attributable, a step budget so the loop is bounded, and a per-decision audit record written outside the agent. Content classification and tool scoping layer on top and matter, and the four above are the ones that make the rest enforceable.

AI Agent Guardrails: Constraining a Loop That Chooses Its Own Next Call

Sysdig's JadePuffer disclosure on July 1, 2026 documented an LLM agent running a full ransomware operation, and one detail from it describes the guardrail problem better than any diagram. Partway through, a subprocess call failed on a PATH error. The agent read the error, switched to a direct bcrypt import, and continued. Elapsed time: 31 seconds. No human in the loop (Sysdig Threat Research).

A guardrail designed for a chat completion assumes the shape of that interaction: one request, one response, a person reading the output and deciding what happens next. An agent removes the person. It calls a model, parses the result, selects a tool, calls the model again with the tool output appended, and repeats until a goal condition is met or a step budget runs out. Twenty model calls in a single task is unremarkable. Each one is an opportunity for the trajectory to move somewhere nobody planned.

I want to walk the four controls that change when the caller is a loop rather than a person, and be specific about which of them sit on HTTP traffic and which do not.

Per-step authorization instead of per-session approval

A human user gets authorized once at login and their session carries that authorization forward. An agent inherits the same pattern in most deployments, receiving a token at start and spending the next 200 seconds making calls that all look identical to whatever sits downstream.

The trajectory is where the risk accumulates. Call 3 retrieves a document. Call 7 summarizes it. Call 14 drafts an outbound message containing content the document supplied. Each call passes a per-call content check on its own merits, and the sequence still moved data from an internal store to an external recipient. Authorization has to attach to each step, referencing the agent's identity and the specific action, rather than resolving once at the top of the loop. The mechanics of the token model are covered in AI agent authorization.

The practical shape of this is a policy that references the calling agent identity, not a shared service credential. VentureBeat's Q2 2026 agentic security research across 107 enterprises found roughly a third running agents on shared API keys or borrowed human and service-account credentials, and 54% had already had a security incident or near-incident involving an agent (Techzine coverage). With five agents behind one key, per-step authorization has nothing to reference.

Tool scoping as the real blast-radius control

The model layer decides what an agent wants to do. The tool layer decides what it can do. Those are different questions and only the second one is enforceable.

An agent granted a database tool with a broad connection string can read every table the credential reaches, regardless of what its system prompt says about scope. Narrow the tool instead of the prompt: a read-only connection to three tables, a filesystem tool rooted at one directory, an HTTP tool with an allow-list of four hosts. Then an injected instruction that convinces the model to exfiltrate the customer table hits a credential that cannot see the customer table, and the attack fails at a layer that does not negotiate. This is the argument developed in AI agent tool scoping and AI agent privilege scoping.

Tool scoping mostly lives outside an HTTP policy gateway. Database grants, IAM roles, and filesystem permissions are enforced by the database, the cloud provider, and the operating system. A gateway governs the model call, and I would rather say that plainly than imply a proxy fixes an over-broad Postgres grant. It does not.

Egress control so the loop has one route out

Per-agent identity at the gateway is enforceable only when the agent cannot reach a provider directly. An agent process with outbound internet access and a provider key in its environment bypasses every policy you wrote, not through cleverness but through routing.

With egress constrained at the network, the gateway becomes the single path every model call travels, which is what makes the identity binding and the audit record complete rather than best-effort. The implementation details are in AI agent egress control.

The per-decision record as the only reconstruction tool

When an agent trajectory goes wrong, the question is what it asked the model at step 11 and what came back. An agent's own logs answer that only if the agent chose to write them, and a compromised or malfunctioning loop is exactly the case where its self-reporting is worth least.

A record written at the request layer holds the agent identity, the prompt content class, the policy version, the decision, and a timestamp, committed before the response returns on a write path the agent never touches. Hugging Face's July 16, 2026 incident disclosure makes the value concrete: responders reconstructed an agent-driven intrusion by running analysis over the full 17,000-plus event action log, compressing days of work into hours (Hugging Face security disclosure). Without a per-decision record of the model calls, the agent-executed portion of that campaign would have been a gap in the timeline. The schema question is worked through in agentic AI audit trail.

What I would drop first

If a team can only build two of these before their next release, I would take egress control and the per-decision record over the more sophisticated content classification every time. Classification catches the attacks you anticipated. Routing and recording tell you what actually happened, including the attacks you did not anticipate, and the second category is larger.

The step budget nobody sets

One control gets left out of agent architectures more often than the other four combined: a hard cap on loop iterations and total model calls per task. An agent that has made 40 calls on a task budgeted for 12 has already left its intended trajectory, whatever the content of call 41 looks like. A ceiling enforced at the request layer converts an unbounded loop into a bounded one, and it costs a counter. The related consumption argument is in OWASP LLM10 unbounded consumption.

DeepInspect

This is the problem DeepInspect was built for. An agent's model calls are HTTP requests to a provider endpoint, and DeepInspect sits inline at that boundary between the agent and the model.

For every call in the loop, DeepInspect binds the request to the agent identity the caller presents, evaluates identity-aware policy against the prompt content and the calling context, and returns a deterministic fail-closed decision before the request reaches the provider. Per-step policy replaces the single session grant that most agent deployments hand out at loop start. Every decision commits a signed, identity-bound audit record before the response returns, which is what responders read when a trajectory has to be reconstructed. DeepInspect governs the model call and leaves the database grants and IAM roles to the systems that enforce them. If your agents run on a shared key and nobody can name which one made a given call, book a demo today.