Kernel-level egress enforcement for every API call, tool invocation, and MCP connection your agents make. Default deny. No code changes.
"You built the agent. It works. It calls APIs, invokes tools, connects to MCP servers. Then security reviewed it and said: 'This agent can reach any endpoint on the internet. We can't approve this for production.'"
— ML Platform Lead, Fortune 500
An attacker embeds instructions in data the agent processes. The agent follows them — calling tools it shouldn't, connecting to endpoints it shouldn't. This is not theoretical; 43% of MCP implementations have injection vulnerabilities.
Agents can reach any destination the host network allows. There is no per-agent egress policy. A compromised agent has the same network access as a legitimate one.
Your agent trusts its MCP servers. A compromised or malicious MCP server exploits that trust — and your agent has no way to limit which MCP servers it connects to at the network level.
The most dangerous outcome of a prompt injection isn't a wrong answer — it's the agent sending sensitive data to an attacker-controlled endpoint. Application-layer filters can't prevent a raw TCP connection.
Every outbound connection from every agent process is intercepted at the kernel, checked against per-agent policy, and allowed or denied before the first byte leaves the host. The agent cannot bypass, disable, or circumvent the policy.
Each agent process gets a unique, verified identity — assigned automatically based on what Riptides can attest about the workload. No agent code changes required.
Write egress policies that specify which destinations each agent identity can reach — by domain, IP, port, or protocol.
Connections to approved destinations proceed normally — with mTLS and credential injection if configured. Everything not explicitly allowed is denied before the TCP handshake completes.
POST api.openai.com:443 → ALLOW (rule: llm-access) → credential injected ✓
POST evil-exfil.com:443 → DENY (no matching rule) → blocked at kernel ✗
POST mcp-server.internal:8080 → ALLOW (rule: mcp-internal) → mTLS established ✓
POST unknown-api.com:443 → DENY (no matching rule) → blocked at kernel ✗
The research agent reaches approved APIs. The coding agent reaches approved MCP servers. Neither can reach anything not explicitly allowed. This is the policy your security review requires.
Even if an injection controls the agent's behavior, it can't create connections to unapproved destinations. The kernel blocks them before the TCP handshake. There's nowhere for stolen data to go.
Two agents on the same host have completely different egress policies, bound to their individual identities. The research agent and the coding agent don't share network permissions.
Works with LangChain, CrewAI, AutoGen, LangGraph, custom frameworks — anything that makes network calls. No SDK, no proxy configuration, no framework plugin. Learn how →
Deploy policies in observe mode first — every connection is logged and evaluated but nothing is blocked. Review the audit trail, tune the allowlist, then switch to enforce. No outage risk.
AI gateways proxy specific API calls — typically LLM requests — but agents make many other connections: MCP servers, databases, internal APIs, SaaS tools. An agent can bypass the gateway by making direct connections. Prompt guardrails try to prevent the agent from being told to do something bad, but a novel injection bypasses them. Kernel-level egress enforcement catches every outbound connection regardless of how it was initiated — because it operates at the TCP layer, below the application, below the gateway, below the guardrails.
Pick your highest-risk agent — the one with the most external connections or the most sensitive data access. Define its allowed destinations. Deploy the egress policy. The agent continues to function normally; everything not explicitly allowed is now blocked.
Bring the before/after to your security review: "Here's every connection this agent can make. Here's what's blocked. Here's the audit trail."
| AI Gateway | Prompt Guardrails | Riptides | |
|---|---|---|---|
| What's controlled | LLM API calls routed through gateway | Prompts/responses filtered by framework | Every TCP connection from the agent |
| Agent can bypass | Direct connections skip gateway | Novel injections bypass filters | Cannot bypass — kernel level |
| MCP server control | Not covered | Not covered | Per-agent MCP server allowlists |
| Per-agent policies | Typically per-service | Per-chain/per-prompt | Per-agent SPIFFE identity |
| Exfiltration prevention | Only for proxied calls | Best-effort prompt filtering | All unapproved destinations blocked |
| Code changes | Route traffic through proxy | Framework-specific integration | None |
| Enforcement layer | Application / proxy | Application / model | Kernel (below all application layers) |
| Audit trail | Gateway logs | Framework logs (suppressible) | Kernel-level, tamper-proof |
How overprivileged MCP tool access becomes a security problem, and what runtime enforcement looks like in practice: Our AI Is Helpful. Also Slightly Overprivileged. →
Tool call security means enforcing which external endpoints, APIs, and MCP servers each AI agent is allowed to call, at the kernel level, regardless of what the agent's LLM decides to do. Without tool call security, an agent can call any reachable endpoint. With Riptides, egress policy is enforced below the framework, so even a jailbroken prompt or compromised tool response cannot cause the agent to reach unauthorized destinations.
Riptides gives each agent a SPIFFE identity and enforces an egress policy that specifies which MCP servers and tool endpoints that identity is allowed to reach. Connections to any endpoint outside the policy are blocked at the kernel before the packet leaves the host. The policy is independent of the MCP client, the agent framework, and the LLM output.
Yes. If an agent receives a prompt that instructs it to call an endpoint outside its allowed egress policy, the connection is blocked at the kernel regardless of what the LLM output says. The agent cannot be socially engineered into reaching unauthorized destinations.
Policies are bound to SPIFFE identities, which can be scoped as finely as a single agent process. You can define different policies for different agent types, different user sessions, or different deployment environments. Policy decisions are logged with full identity context, so you can audit exactly what was allowed and denied for each agent.
Content filtering and prompt guardrails operate at the application layer. MCP tool calls operate at the network layer. The three attack vectors that matter most in agentic systems all route around application-layer defenses entirely.
An attacker embeds instructions in data the agent retrieves — a document, a web page, a database record. The agent is told to call a tool with a parameter pointing to an internal metadata endpoint such as 169.254.169.254 (the AWS instance metadata service). The prompt content filter never sees a malicious URL; it sees a tool invocation with a parameter. Kernel egress policy blocks the outbound connection before it completes, regardless of what the LLM decided to do.
A malicious or compromised MCP server returns a response crafted to cause the agent to include sensitive values in a subsequent API call. The agent is not "told" to exfiltrate anything — the response is structured to make exfiltration the natural next step in the agent's reasoning. Content filtering on outbound prompts does not catch values that were never in the prompt. Secretless injection means the agent was never given credentials to begin with, so there is nothing to exfiltrate.
The agent calls Tool A as intended. Tool A's response contains instructions — embedded in returned data — that cause the agent to call Tool B on an internal network segment it was never meant to reach. Each individual tool call looks legitimate in isolation. The lateral movement only becomes visible when you look at the destination of the second call. Per-agent egress policy means Tool B's internal address is not in the allowlist, and the connection is blocked before the packet leaves the host.
An AI gateway or content inspection proxy sits in the request path for the calls it knows about. An agent that makes a direct TCP connection to an internal endpoint, or routes a tool call through a side channel, bypasses the proxy entirely. This is not a configuration gap — it is an architectural one. Kernel enforcement cannot be bypassed because it does not sit in the request path; it controls whether the connection is permitted to exist at all. Every outbound connection from every agent process is subject to policy, regardless of which framework, library, or tool initiated it.
Identity, access control, and a full audit trail for every agent and service — enforced on the host, with no code changes. Up and running in an afternoon.