The inference boundary vs network boundary distinction is the fastest way to understand why prompt filtering alone never stops a determined AI agent. The inference boundary is where a model reads inputs and writes outputs; the network boundary is where the agent actually sends bytes to the outside world. Classifiers guard the first. Egress enforcement guards the second. You need both.
The inference boundary vs network boundary in one sentence
At the inference boundary, tools inspect prompts and completions to catch injection, jailbreaks, and toxic text. At the network boundary, a proxy inspects the outbound HTTP, DNS, and WebSocket calls the agent actually makes. A prompt can be flagged as suspicious yet still produce a tool call that exfiltrates data, because the model output and the network action are two different events at two different layers.
Agent G sits at the network boundary as a zero-trust egress proxy. It does not try to read the model's mind. It reads the wire: the exact host, path, headers, and body of every request the agent emits, then allows, denies, gates, or logs it against policy.
Prompt filtering vs egress control: what each layer sees
Treating these as competitors is the common mistake. They observe different data and fail in different ways. A prompt classifier can score intent but cannot guarantee the resulting action. An egress control cannot always understand why an agent wants to POST to an unknown domain, but it can deterministically stop the POST.
| Property | Inference boundary (prompt filtering) | Network boundary (egress control) |
|---|---|---|
| What it inspects | Prompts, completions, tool-call arguments as text | Actual outbound requests: host, path, headers, body, DNS |
| Failure mode | Probabilistic: misses novel phrasing or encoded intent | Deterministic: enforces policy regardless of intent |
| Blocks the action? | No, it advises the application | Yes, the request never leaves the boundary |
| Sees encoded exfil | Only if it decodes the text | Yes, with normalization passes on the wire |
| Audit evidence | Model-level logs inside the trust boundary | Out-of-band, tamper-resistant action records |
Why network-layer AI guardrails catch what classifiers miss
Network-layer AI guardrails matter because the model output and the network call diverge in ways classifiers cannot predict. Three concrete cases:
- Indirect prompt injection. A poisoned web page or retrieved document instructs the agent to send data to
attacker.example. The prompt classifier may never see the injected text because it arrives mid-tool-loop as a tool response, not as user input. The egress proxy still sees the outbound request and denies it under default-deny. - Encoded secrets. An agent base64-encodes an API key or splits it across headers. Text classifiers scan for obvious secret patterns and miss the transform. A wire-level DLP engine normalizes the payload (base64, hex, homoglyphs) before matching.
- DNS and side channels. Data can leave as subdomain labels in DNS queries or as WebSocket frames. These never appear as clean model output, so prompt filtering is blind. Egress inspection reads them directly.
Runtime AI security is enforcement, not advice
Runtime AI security means the control participates in the request path and can stop it. A classifier that returns a risk score is advisory: your application code still decides whether to honor it, and a bug, race, or bypassed code path lets the action through. An inline egress proxy is authoritative: if policy says deny, the connection is refused and the bytes never leave.
This is the deterministic property enterprises need for compliance. You can prove an action was blocked because there is a signed record from outside the agent's trust boundary, not a log the agent could have skipped writing.
How the two layers combine in practice
The strongest posture chains both boundaries. Here is the order of operations for a well-instrumented agent:
- Inference boundary, inbound. Classify the user prompt and any retrieved content for injection and policy violations. Reject or sanitize obvious attacks early.
- Agent reasoning. The model plans and selects a tool call. This is still just text and intent, not yet an action.
- Network boundary, outbound. Agent G intercepts the resulting request. It matches the destination against a default-deny allowlist, inspects tool-call arguments and request bodies, runs DLP normalization, and either allows, denies, or escalates for human approval.
- Inference boundary, response. Optionally re-classify tool responses before they re-enter the model context to reduce injection feedback loops.
- Audit. The proxy emits an out-of-band action record for every decision, ready for your SIEM.
Notice that steps 1 and 4 are probabilistic safety nets, while step 3 is the deterministic backstop. If the classifier misses, the egress boundary still holds. If the egress policy is too permissive, the classifier still adds friction. Defense in depth means neither single failure is catastrophic.
Common objections, answered
Is not a smarter classifier enough? No. Even a perfect classifier only advises. It cannot guarantee the code between it and the socket honors the verdict, and it cannot see non-text channels like DNS. The network boundary is where actions become irreversible, so that is where enforcement must live.
Does adding a proxy hurt latency? A well-built egress proxy adds low single-digit millisecond overhead per call, which is negligible next to model inference time. The trade is a rounding error against the cost of an unmonitored exfiltration event.
Where does policy-as-code fit? Both layers benefit from versioned, reviewable policy. At the network boundary, policy-as-code defines allowlists, argument constraints, and escalation rules that are enforced identically on every request, giving you the same rule in Git and on the wire.
What to implement first
If you have neither layer, start at the network boundary. It is the only layer that can deterministically contain a compromised or manipulated agent, and it produces the audit evidence auditors ask for. Add prompt classification next to reduce the volume of attacks that ever reach the egress decision. Together they cover the full path from a manipulated prompt to a blocked request.
Frequently Asked Questions
What is the difference between inference boundary and network boundary AI security?
Inference-boundary security inspects prompts and model outputs with classifiers and is advisory. Network-boundary security inspects the actual outbound requests an agent makes and can deterministically block them. The inference boundary vs network boundary split maps to detection versus enforcement, and robust systems use both.
Can prompt filtering alone stop data exfiltration?
No. Prompt filtering scores text intent but cannot guarantee the resulting network action, cannot always decode encoded payloads, and is blind to non-text channels like DNS and WebSockets. An egress proxy inspecting the wire is required to reliably block exfiltration attempts.
Does an egress proxy replace my WAF or network firewall?
No. A WAF filters inbound HTTP and a network firewall controls host and port level traffic. An AI agent egress proxy adds application-aware, per-action enforcement on outbound agent calls, inspecting tool arguments and payloads those tools cannot see. See our alternatives comparisons for details.
How does Agent G enforce the network boundary?
Agent G is a drop-in egress proxy that applies a default-deny allowlist, inspects tool-call arguments and request bodies, runs DLP normalization, escalates risky calls for human-in-the-loop approval, and emits verifiable action receipts for every decision.
Pairing prompt classifiers with wire-level enforcement is the practical answer to the inference boundary vs network boundary question: detection reduces noise, enforcement guarantees containment. If you are building agents that touch real data and real credentials, own the network boundary first. Request access to the Agent G private beta and start enforcing egress policy on every outbound agent call today.