Stop using LLMs to guardrail LLMs. I built a deterministic security proxy for AI agents.

by

Hey everyone and hi product hunt,

I want to share what I’ve been working on. The current trend in AI agent security is using another LLM as a "guardrail" to check if a prompt is malicious. I think this is fundamentally broken—it's slow, probabilistic, and gets bypassed by indirect prompt injections.

AI agents are the ultimate "Confused Deputy." They hold high-privilege API keys, but their reasoning can be hijacked by untrusted data (like a Jira ticket or an email). The real damage doesn't happen at the prompt layer; it happens at execution.

So I built Relay—a runtime security proxy that sits between the agent's decision and the actual tool execution.

How it works:

  1. Deterministic Policy Gate: Instead of an LLM guessing if an action is safe, Relay does an O(1) hash lookup on the tool name. (e.g., github_delete_repo = blocked, github_read = allowed). Zero latency, zero hallucinations.

  2. Networkless Sandboxing: For coding agents, you can't regex-check every bash command. Relay routes shell tool calls into an ephemeral Docker container with --network none. If an agent gets hijacked and tries to curl an attacker's webhook to exfiltrate data, the command physically can't resolve DNS.

  3. Compliance: Every allowed/blocked action is signed (ed25519) and written to a tamper-proof Merkle append-log so enterprise teams have a cryptographic audit trail.

It's model-agnostic and works with Node, Python, LangGraph, and Claude Code. You can wrap your dangerous tools in about 3 lines of code.

Who it's for: Devs/Platform teams deploying autonomous agents with access to prod systems who need to get past their AppSec/CISO review.

It's free to test right now. Would love for you to tear it apart and give me feedback on the architecture.

Live app & docs:

What do you guys think about the "deterministic vs probabilistic" approach to agent security?

4 views

Add a comment

Replies

Be the first to comment