Overview
- Speaker: Ryan Dahl
- Channel: AI Engineer
- Main topic: Security for AI Agents in Production Environments
- Purpose: To introduce Claw Patrol, an open-source solution for securing AI agents in production by enforcing fine-grained control over their interactions with external systems, emphasizing that external security boundaries are necessary even with aligned AI models. Ryan Dahl from Deno presents Claw Patrol, an open-source proxy designed to secure AI agents operating in production environments. He argues that even well-aligned AI models cannot be fully trusted to self-police, especially when granted read/write access to critical systems like databases, Kubernetes, and cloud infrastructure. Claw Patrol acts as an intermediary, terminating network connections from agents, holding sensitive credentials, and evaluating every action against meticulously defined rules written in HCL. This system aims to provide precise control over agent behavior, prevent prompt injection, and offer human-in-the-loop or LLM-based approval mechanisms for high-risk actions, ensuring that agents never directly access sensitive credentials while maintaining security across diverse protocols and complex network topologies.
Topic Map
The Challenge of Securing AI Agents in Production (33-245)
- Explanation: Deno Deploy uses AI agents (like OpenClaw) as first responders to PagerDuty incidents, granting them extensive read/write access to critical production systems (Postgres, Kubernetes, AWS, GitHub, Slack, Grafana). While powerful for automating incident response, this access is inherently dangerous as agents could be manipulated to perform destructive actions.
- Key claims:
- AI agents, like OpenClaw, are given broad read/write access to production systems for automated incident response.
- This level of access is powerful, allowing agents to diagnose and resolve incidents across diverse systems.
- However, agents with such access pose an 'exquisitely dangerous' risk, as they could be manipulated to execute harmful commands (e.g., dropping database tables, deleting namespaces).
- Examples:
- OpenClaw agent responding to PagerDuty fires on Deno Deploy.
- Agent accessing Postgres, Kubernetes, Clickhouse, AWS, Github, Slack, Grafana.
- Hypothetical destructive commands:
psql -c 'DROP TABLE users' or kubectl delete namespace prod.
- Terminology:
- AI agent
- Deno Deploy
- OpenClaw
- PagerDuty
- SRE
- Why it matters: Enabling AI agents with broad access to production systems can significantly improve incident response, but it also introduces critical security vulnerabilities that traditional alignment practices alone cannot address.
Limitations of AI Alignment for Security (245-399)
- Explanation: Even with well-aligned models like Opus, alignment is necessary but not sufficient for security. Agents can still be susceptible to prompt injection, especially when connected to support systems that expose them to external, potentially malicious, input. The fundamental problem is that the agent itself cannot be solely trusted to police its own actions; a robust external security boundary is required.
- Key claims:
- AI model alignment (e.g., Opus) is a necessary but insufficient condition for robust security.
- Prompt injection remains a significant threat, as agents often require access to external communication channels (like support messages) which can be manipulated.
- The core principle is that 'the agent is the thing being manipulated. You can't put the guard inside it.'
- Real security demands more than 'wishful thinking' about an agent's benevolent intent.
- Examples:
- Trying to get Opus to 'delete the user's table' and its refusal, highlighting alignment.
- SRE agents connected to support systems being vulnerable to external prompt injection.
- Terminology:
- AI alignment
- prompt injection
- security boundary
- Why it matters: Relying solely on AI model alignment for security is a false sense of security. External, verifiable security mechanisms are paramount because agents, by nature, can be compromised or manipulated, making internal policing unreliable.
The Need for External Security Proxies (Claw Patrol) (399-1101)
- Explanation: Since local system access for agents is easily sandboxed, the real security concern lies in network communications – the 'bytes on the wire.' Agents execute tool calls in various ways (MCP, subprocesses), making it difficult to control. Claw Patrol is proposed as an open-source proxy solution that sits in front of agents. It terminates network connections, holds credentials, and evaluates every action against rules written in HCL. This allows for careful and precise management of access across diverse systems and non-HTTP protocols like PostgreSQL, even when tunneling through other systems.
- Key claims:
- Every significant action an agent takes, whether good or nefarious, is manifested as network communication ('bytes on the wire').
- Local system sandboxing is not the primary concern; controlling network-bound actions is critical.
- Claw Patrol functions as a proxy that intercepts all agent communications, regardless of the underlying protocol (HTTP or non-HTTP like PostgreSQL).
- Claw Patrol is designed to terminate network connections, manage and inject credentials, and rigorously evaluate every outgoing action against a predefined set of rules.
- The agent itself never directly sees the sensitive credentials, reducing the risk of compromise.
- Examples:
- Agent trying to
DROP TABLE users through a psql subprocess, which is rejected by Claw Patrol. - Accessing a production PostgreSQL database inside a VPC via an EKS API server, requiring careful SQL-aware gating.
- Handling non-HTTP protocols like PostgreSQL where rules must understand SQL semantics.
- Terminology:
- network proxy
- HCL (HashiCorp Configuration Language)
- credential injection
- protocol parsing
- action (Claw Patrol term)
- Why it matters: A dedicated external proxy that deeply understands and controls network communications at the byte level, across various protocols, is essential to establish a robust and verifiable security perimeter for AI agents.
Claw Patrol Features and Architecture (1101-1631)
- Explanation: Claw Patrol's core is its rule system, written in HCL, which enables precise management of access. These rules can block actions or trigger approval workflows, either via human operators (e.g., Slack) or other 'judge agents' (e.g., LLMs with specific policies). It also supports credential injection for various systems (databases, HTTP, cloud infra, AI providers, SaaS APIs) so agents never directly handle secrets. For deployment security, Deno runs its agents on Tailscale, with Claw Patrol acting as a Tailscale exit node, leveraging Tailscale identity for dashboard authentication.
- Key claims:
- Claw Patrol uses HCL for its rule system, allowing detailed and version-controlled specification of agent permissions.
- The rules can enforce 'deny' verdicts or trigger 'approval' workflows (human-in-the-loop via Slack or LLM-based judge agents).
- Credential injection is a key feature, ensuring agents never see raw credentials for diverse systems (databases, HTTP tokens, AWS SigV4, SSH, AI APIs, SaaS APIs).
- Claw Patrol operates as an exit node within a Tailscale network, enhancing security by placing agents off the public internet and leveraging Tailscale identity for access control to the Claw Patrol dashboard.
- The system emphasizes a utilitarian, real-world approach to security for complex production environments.
- Examples:
- HCL rule
pg-banned-functions blocking dangerous PostgreSQL functions like pg_read_file or lo_get. - Human approval for sensitive actions via a Slack channel (
dagent-ops). - LLM judge agent (
claude-haiku) configured to 'Reject SELECTs that see secrets'. - Claw Patrol injecting AWS SigV4 credentials for agents interacting with AWS services.
- Terminology:
- HCL
- plugin system
- human-in-the-loop
- LLM judge
- Tailscale
- WireGuard
- exit node
- credential injection
- Why it matters: Claw Patrol provides a comprehensive framework that combines policy-as-code with dynamic credential management and approval workflows, addressing the multi-layered security challenges of integrating AI agents into complex, sensitive production systems.
The Fundamental Principle: Untrusted Agents (1631-1842)
- Explanation: The overarching thesis is that AI agents, regardless of their intelligence or alignment, cannot be trusted to police themselves. The security boundary must exist external to the agent's software. While alignment and internal security plugins are beneficial, they are not sufficient. Robust backstop security mechanisms are always necessary for real-world systems, and this problem will persist even as AI models become more advanced.
- Key claims:
- An agent cannot be trusted to police itself; its software should be treated as a black box.
- Security boundaries must be external to the agent's code, not relying on internal plugins or modifications.
- Even with advanced alignment in LLMs, 'backstop security mechanisms' will always be essential.
- The problem of securing agents is not diminished by increased agent intelligence but fundamentally requires external control.
- Examples:
- Terminology:
- security boundary
- black box
- backstop security
- Why it matters: This principle mandates a shift in security thinking, moving away from inherent trust in AI agents towards a model of external oversight and control, crucial for safely deploying AI in critical operations.
Key Points
AI agents in production require external security mechanisms, not just internal alignment.
- Explanation: While AI models are increasingly well-aligned, this doesn't guarantee security. Agents with read/write access to production systems are powerful but can be manipulated. Real security needs external enforcement, as agents cannot be fully trusted to police themselves.
- Evidence: Even highly aligned models like Opus can theoretically be prompt-injected, leading to destructive actions like dropping database tables. The speaker explicitly states, 'You can't put the guard inside it.'
- Practical implication: Organizations deploying AI agents in production must implement external proxies or firewalls that control and validate every action an agent attempts, independent of the agent's internal logic or alignment.
Claw Patrol provides granular, protocol-aware security for AI agent actions.
- Explanation: Claw Patrol acts as a proxy, inspecting and controlling all network communications from an agent, regardless of whether they are HTTP, database protocols (Postgres), or other system calls. It uses HCL rules to define precise access policies, preventing malicious or unintended actions.
- Evidence: Demonstrated blocking of a
DROP TABLE users command even when issued by a seemingly 'aligned' agent. The HCL rule example shows specific PostgreSQL functions being banned. - Practical implication: This allows SREs to define explicit, auditable security policies at the network layer, ensuring that agents can only perform allowed actions, thereby mitigating risks of data loss or system compromise.
Credential injection ensures agents never directly handle sensitive secrets.
- Explanation: A core security tenet is that agents should not possess direct access to credentials. Claw Patrol handles credential injection, allowing agents to issue requests using placeholders, while the proxy itself injects the correct, secure credentials before forwarding the request to the target system.
- Evidence: Claw Patrol holds credentials and injects them, supporting diverse types like bearer tokens, cookies, AWS SigV4, SSH, and various API keys (Anthropic, OpenAI, GitHub, Slack, etc.).
- Practical implication: This drastically reduces the attack surface, as a compromised agent would not immediately yield sensitive credentials, requiring an attacker to bypass Claw Patrol's rule engine as well.
Support for human-in-the-loop and LLM judge agents for approvals.
- Explanation: Beyond strict 'deny' or 'allow' rules, Claw Patrol enables dynamic approval workflows. High-risk actions can be routed for human review (e.g., Slack notifications) or evaluated by a specialized LLM judge agent, which can apply its own policies before granting approval.
- Evidence: HCL configuration examples for
human_approver in a Slack channel and llm_approver using Claude-Haiku with a policy to 'Reject SELECTs that see secrets'. - Practical implication: This hybrid approach allows for automation of routine tasks while retaining critical human oversight or leveraging advanced AI for nuanced decision-making on sensitive operations, ensuring a balance between efficiency and safety.
Integrated with secure networking solutions like Tailscale.
- Explanation: Claw Patrol is designed to operate within secure network overlays, such as Tailscale. This isolates agents from the public internet and leverages Tailscale's identity-based authentication for both agent operation and dashboard access, adding another layer of security.
- Evidence: Deno runs its agents on Tailscale, with Claw Patrol functioning as a Tailscale exit node, and the dashboard uses Tailscale identity for authentication.
- Practical implication: Organizations can build a highly secure private network for their AI agents, ensuring that only authenticated and authorized entities can access and control the agents and their proxy.
Frameworks, Models & Processes
Claw Patrol
- How it works: Claw Patrol is an open-source security proxy that sits between AI agents and the tools/systems they interact with. It terminates all outgoing network connections from an agent. For each 'action' (network request), it parses the raw bytes, identifies the protocol and content, applies a set of predefined rules (written in HCL), and, if allowed, injects necessary credentials before forwarding the request to the target system. It can also route actions for human or LLM approval. All actions are logged and visible in a dashboard.
- Components:
- Proxy: Intercepts and terminates agent network traffic.
- Rule Engine: Evaluates actions against HCL-defined policies.
- Credential Store: Securely holds and injects credentials for various systems.
- Plugin System: Extensible for custom protocols and circumstances.
- Approval System: Supports human-in-the-loop (e.g., Slack) or LLM judge agents.
- Dashboard: Provides live overview, analytics, and action details.
- Integration: Designed to work with secure network overlays like Tailscale/WireGuard.
- When to use: When deploying AI agents in production environments, especially those requiring read/write access to sensitive systems (databases, cloud infra, SaaS APIs). It is ideal for scenarios where fine-grained control over agent actions, credential management, and auditable security policies are critical due to the inherent untrustworthiness of AI agents themselves.
Examples & Case Studies
An AI agent attempted to execute DROP TABLE users on a PostgreSQL database.
- Illustrates: The necessity of an external security boundary to prevent destructive actions, even when an agent is considered 'aligned' or is in a testing ('yolo') mode.
- Lesson: AI models, despite alignment efforts, cannot be solely trusted. External mechanisms like Claw Patrol, which parse specific protocols (SQL in this case) and apply explicit rules, are crucial to prevent unintended or malicious operations. The security boundary must be outside the agent itself.
Actionable Takeaways
- Immediate:
- Implement external security proxies for all AI agents accessing production systems.
- Define granular access control rules using policy-as-code (e.g., HCL) for every agent action.
- Ensure agents never directly handle sensitive credentials; use a credential injection system.
- Leverage human-in-the-loop or LLM-based approval for high-risk agent operations.
- Strategic:
- Shift security paradigm: treat AI agents as untrusted software, regardless of their perceived alignment or intelligence.
- Invest in infrastructure that enables deep inspection and control of network traffic from agents, beyond basic HTTP proxies.
- Prioritize auditable and verifiable security mechanisms for AI deployments to maintain compliance and incident forensics.
- Integrate AI agent security with existing network and identity management solutions (e.g., Tailscale).
- Questions to investigate:
- How can existing security infrastructure (firewalls, IAM) be adapted to perform protocol-aware inspection and credential injection for AI agents?
- What are the best practices for writing and maintaining HCL rules for a diverse set of production systems and AI agent behaviors?
- How can LLM judge agents be reliably evaluated and secured against adversarial attacks that might bypass their policies?
- What is the performance overhead of running an external proxy like Claw Patrol for every agent action, especially at scale?
Claims Worth Verifying
- Alignment alone is not a sufficient security boundary for AI agents. (Security Principle)
- An agent cannot be trusted to police itself; the security boundary must be external. (Security Principle)
- All significant agent actions are communicated via 'bytes on the wire,' making network-level control paramount. (Technical Observation)
- Claw Patrol terminates the wire, holds credentials, and evaluates every action against HCL rules. (Product Feature)
- Claw Patrol's plugin system allows handling custom protocols and circumstances. (Product Capability)
Notable Quotes
"I want to talk about um a service that we're running at Deno called Deno Deploy. This is a system for hosting websites. And it has incidences, it's it it has downtime occasionally. And uh we've got a PagerDuty that fires. I'm sure you're all very familiar with the very scary alarm sound that wakes you up in the middle of the night. Um and recently we've been playing around with using agents to automatically service these incidents. Um in particular OpenClaw but other other agents as well. Um and we've found a pattern that is working pretty well for us that I want to share with you. Um we actually give OpenClaw access to all sorts of systems. Postgres, Kubernetes, Clickhouse, AWS, GitHub, Slack uh all all sorts of things and we we do actually give them uh rewrite access to these systems." (at 0:34) "But it is very dangerous of course because these agents could do nefarious things. They could start a P-SQL subprocess and issue a delete users table. Um they could call CubeCuttle delete namespace prod. Um you know, they they could decide somehow that solving the incident, it means, you know, removing all of the users. Uh and of course we don't want that." (at 3:36) "But this is not sufficient, right? Security can't just be wishful thinking that Opus will always obey your your wishes. Um these SRE agents that we have are connected to the support system and thus can be prompt injected from the outside. And that means that they can be manipulated somehow. Like who knows who knows what sort of uh string of characters could send Opus into some uh bad state that allows it to think that it's taking the right action by doing something very undesirable. So you know, we take the stance that the secure the agents themselves have to be untrusted software. You can't rely on the agent itself to guard what it's doing. You can't put the guard inside it." (at 4:10) "This can get very tricky in real-world systems. So, for example, we have a production Postgress database in AWS, um, that is inside a VPC that we can only reach really through an EKS endpoint. And what we'd really like to do is ensure that our agent, which we want to give access to everything essentially, can't somehow tunnel through this EKS server, spawn P-SQL, and drop the users table. Right? We're we're concerned about pretty crazy situations like this that get very complicated. And I think many of you work in companies where you have real-world systems where things are very complicated, have very complex network topologies. So, yeah, just to just to highlight this. This is an outbound path the agent's host can't reach, on a protocol that isn't HTTP, gated by a rule that understands SQL. These are what human SREs would do. And how can we you know, empower these these agents to to have kind of the the same access that that a human might?" (at 8:33) "So the software that uh we've written to address this problem is called Claw Patrol. Uh it's an open-source MIT licensed project. And this is a proxy that sits in front of your agents. Um it operates not at the HTTP level, but at a lower level. It understands each and every byte flowing through, flowing out of your agent. It holds credentials like Agent Vault and can inject those credentials so that your uh whatever agent software you're using doesn't actually doesn't ever actually see secret values. And um in particular it has a very advanced rule system that allows you to say in in precise details how how and and what requests get uh transferred out out of the agent and talk to the outside world." (at 16:39) "An agent cannot be trusted to police itself." (at 27:12)
Compressed Summary
- AI agents in production pose significant security risks due to broad access and potential for manipulation.
- AI model alignment is not sufficient for security; external controls are essential to prevent prompt injection and undesirable actions.
- Claw Patrol is an open-source proxy that inspects, controls, and logs all agent network traffic across diverse protocols.
- It uses HCL rules for fine-grained access management and implements credential injection so agents never handle secrets.
- Claw Patrol integrates with secure network overlays like Tailscale for enhanced authentication and isolation.
- The core thesis is that agents cannot be trusted to police themselves, necessitating external, verifiable security boundaries.
- Keywords: ai security, agent firewall, claw patrol, credential injection, hcl rules, production security
- Core insight: AI agents in production environments require external, granular security controls and credential management through a proxy like Claw Patrol, as their inherent alignment or internal mechanisms are insufficient to prevent malicious or unintended actions.
Why the Security Perimeter for AI Agents Must Live Outside the Model
Model alignment cannot be trusted as the primary defense because prompt-injected agents can still issue dangerous network calls; only an external egress proxy that observes and enforces policy on every network-level action provides a verifiable security boundary.
AngleArchitectural argument against relying on in-agent guardrails
Source video ↗SQL-Aware Firewalls Are the Minimum Bar for Agent Database Access
Network-level filtering cannot stop an agent from executing `DROP TABLE`; agent security requires protocol-aware parsing that evaluates SQL semantics before allowing database connections.
AngleCase for protocol-aware policy enforcement in agent infrastructure
Source video ↗Credential Injection Is Not Optional for Agentic Systems
Letting agents hold long-lived credentials turns prompt injection into credential theft; a proxy that brokers secrets and injects them only after policy approval limits blast radius and centralizes secret rotation.
AngleCredential brokering as a core design pattern for agent safety
Source video ↗Approval as a First-Class Policy Action for Autonomous Agents
Binary allow/deny is insufficient for safe automation of high-risk actions; agent policy languages must support human-in-the-loop and LLM-judge approvals as first-class outcomes, not bolted-on exceptions.
AnglePolicy design for human oversight in agentic systems
Source video ↗