Talk by Ryan Dahl (Deno) on securing AI agents with production access. Deno's incident response agents read and write to Postgres, Kubernetes, ClickHouse, AWS, GitHub, and Slack, so prompt injection through the support system becomes a real threat. Dahl argues agents are untrusted software and security cannot rely on model obedience. He presents Claw Patrol, an MIT-licensed proxy that inspects all bytes leaving the agent below the HTTP layer — including paths like spawning psql and tunneling to a production database via an EKS endpoint, which HTTP rules and MCP tool permissions miss. Rules are written in HCL, checked into git and unit tested against fixture requests. The proxy holds credentials (cookies, OAuth, AWS SigV4) so agents never see them, and can route actions to an LLM judge, a human approver in Slack, or both. Demo shows Codex in yolo mode attempting to delete the users table, blocked at the Postgres wire protocol. Covers the broader landscape of proxies and sandboxes, credential injection, and running over Tailscale/WireGuard. # Video Identity Observations — "Security Firewall for Agents — Ryan Dahl, Deno" ## Explicit Self-Description Evidence - **Speaker identity**: Ryan Dahl introduces himself directly: > "my name is Ryan... I'm the CEO at Dino [Deno]... You might know one of my projects, Node.js." - **Company affiliation**: The speaker explicitly states he is speaking about internal Deno infrastructure: > "a service that we're running at Dino called Dino Deploy." - **Product introduction**: The talk's central artifact is introduced as open source: > "the software that we've written to address this problem is called claw patrol. It's an open-source MIT license project." ## Observable Presentation Patterns ### Audience Addressed - **Technical practitioners running AI agents in production**: The speaker repeatedly assumes shared experience: > "I'm sure you're all very familiar with the very scary alarm sound that wakes you up in the middle of the night." > "we run agents and I assume many of you do the same on standalone VMs." - **Engineers at companies with complex real-world systems**: > "I think many of you work in companies where you have real world systems where things are very complic[ated]." - **Audience interaction confirms a live conference-style technical setting** — two audience questions (on testing, and on whether smarter agents shrink the problem) plus applause. ### Claimed Scope of Content - **A working pattern for securing production AI agents**, framed as shared experience rather than theory: > "we've found a pattern that is working pretty well for us that I want to share with you." - **Coverage of the existing security-tooling landscape** (demonstrated, not just claimed): the talk surveys LLM gateways (OpenRouter, LiteLLM), HTTP proxies (HTTP Jail, Brex's CrabTrap), credential injection (Agent Vault), and process sandboxes (Nvidia's OpenShell). - **A concrete product demo** of Claw Patrol: rules written in HCL, a Postgres-block demo ("delete the users table... ultimately reject"), dashboard, approval workflows (Slack, LLM judge), credential injection (including AWS SigV4, OAuth, cookies), and Tailscale/WireGuard deployment. ### Demonstrated Channel Characteristics (from this single video) - **First-party engineering authority**: The speaker grounds claims in his own company's operations ("a file that we check into git... like a thousand lines") rather than third-party analysis. - **Stated thesis, explicitly framed**: > "agents can't be trusted to police themselves... The security boundary has to be elsewhere." - **Honest positioning of the tool against alternatives**: The speaker explains why ACLs, read-only credentials, and MCP-scoped tools are insufficient — claims about limitations, supported by his tunneling example. ## Claims vs. Demonstrated Patterns | Creator Claim | Supporting Evidence in Talk | |---|---| | Agents solve many incidents without humans | "the agents are actually able to solve quite a lot of incidences where we previously would have a human in the loop" (stated experience, not shown) | | Claw Patrol blocks dangerous actions | A non-live recorded demo is described ("Unfortunately, not live") in which a `DROP TABLE` via psql is rejected | | Rules are production-tested | Q&A: "this rule file actually has a test system along with it... you can essentially create unit tests" | ## Notes for Synthesis - No curated metadata was supplied; identity observations rest solely on the title and transcript. - The title format ("Speaker Name, Company") indicates a **talk/keynote channel or event-recording format** rather than a personal vlog. - No private motivations are stated; all observations above trace to quoted transcript passages. # Delivery Observations — Ryan Dahl, "Security Firewall for Agents" (Deno) ## Tone & Overall Register - **Casual, low-key engineering talk style.** The delivery is conversational rather than polished keynote rhetoric, marked by heavy disfluency and filler: - "Um, my name is Ryan. Um, I'm going to I I'm I'm the CEO at Dino" - Frequent "you know" as a connective: "Um they could call cubecuddle delete namespace prod. Um, you know they they could decide somehow..." - **Understated humor** appears a few times, framed around shared operator pain: - "I'm sure you're all very familiar with the very scary alarm sound that wakes you up in the middle of the night." - "they could decide somehow that solving the incident it means you know removing all of the users." ## Vocabulary & Technical Lexicon - **Dense infrastructure/operations vocabulary** used without much explanation, assuming a practitioner audience: *Postgres, Kubernetes, ClickHouse, VPC, EKS, psql, PagerDuty, Tailnet, WireGuard, SIG v4, MCP, HCL*. - **Byte-level framing as a recurring conceptual vocabulary:** the speaker repeatedly reduces the security problem to "bytes": - "effectively every nefarious action... comes in the form of some network communication some some bites over the wire" - "we really want to understand what the bites are coming out of that agent in great detail" - "It understands each and every bite flowing through... out of your agent" - "We pars each and every bite" ## Recurring Phrases & Verbal Habits - **"You know" as a persistent discourse marker** — appears dozens of times across the talk (observable at [36], [147], [208], [360], [394], [443], [544], [1008]). - **Stuttered restarts for emphasis or self-correction**, a stable pattern: - "This is a system for hosting websites and it has incidences. It's it it has downtime" - "the agents are actually able to solve quite a lot of incidences where we previously would have a human s in the loop" - **"So yeah" / "So, uh" as a transition device** between topics: - "So yeah, just to just to highlight this..." - "So yeah, this I guess what I'm trying to uh say is..." - **Restating audience questions before answering** (a stable Q&A habit): - "Uh yeah. So the question is what what sort of testing do we do we do to make sure it works properly?" - "So the question is as as agents get smarter does this problem get bigger or smaller?" ## Teaching / Argumentation Patterns - **Threat-scenario walkthroughs with concrete destructive commands.** The speaker repeatedly illustrates danger with vivid, specific hypothetical commands: - "They could start a psql subprocess and issue a delete users table" - "they could call cubecuddle delete namespace prod" - "hey, delete the users table from from Postgres" - **Systematic survey of prior art before presenting the solution.** He walks through existing approaches (ACLs/credentials, MCP tool permissions, LLM gateways, HTTP Jail, Crabtrap, AgentVault, OpenShell), naming each and noting its limitation, before introducing Claw Patrol. - **Anticipating and voicing audience objections:** - "So you might ask, you might say, well, you know, there's ACL's, there's permissions, you can issue readonly uh Postgress credentials." - **A single thesis stated as a principle and returned to at the close** — "agents can't be trusted to police themselves" / "You can't put the guard inside the agent" (early) is echoed at the end: "The the security boundary has to be elsewhere." - **Audience-polling as a check-in** (isolated instance, low repetition): - "Uh who anybody familiar with HCL? This is like the Terraform the Terraform configuration language." ## Structure & Presentation Choices - **Narrative arc: personal context → problem → existing solutions' limits → product → demo → thesis recap.** Opens with self-introduction and incident-response pain ("we've got a pager duty that fires"), ends with the distilled principle. - **Caveating the demo:** "here's here's a little demo. Unfortunately, not live." — explicitly flags the demo is pre-recorded. - **Honest framing of limitations and trust in his own tool:** "Claw Patrol itself is holding all of these credentials to production systems. So you have to be very careful with it." - **Time-boxed Q&A:** "I might have time for one question or so." ## Uncertainty Notes - Repetition of "you know," "um," stuttered restarts, and question-restating is well-supported across the transcript. The audience-polling habit and humor are **isolated moments**, not stable patterns — insufficient repetition to call them habits. - Non-verbal delivery features (pauses, gestures, slide content) are not observable from the transcript; no claims made about them. # Observation Document: "Security Firewall for Agents" — Ryan Dahl, Deno ## Speaker - **Ryan Dahl**, CEO of Deno, creator of Node.js (self-identified in transcript). ## Context - Deno runs **Deno Deploy**, a website hosting service that occasionally has incidents and downtime, with PagerDuty alerts. - They have been experimenting with agents (notably **OpenClaw**, among others) to automatically service these incidents. ## Core Position > "Agents can't be trusted to police themselves." - Dahl argues the **security boundary must sit outside the agent**, not inside it — including not relying on security plugins or modifications to agent software. - Agents themselves must be treated as **untrusted software**. ## Key Claims and Reasoning ### 1. Broad agent access works but is dangerous - Agents are given access (including **rewrite access**) to Postgres, Kubernetes, ClickHouse, AWS, GitHub, Slack. - **Claimed benefit:** Agents can gather full context (traces in ClickHouse, production Postgres queries, Slack messages, GitHub logs) and resolve many incidents that previously required a human. - **Risk:** They could execute destructive actions, e.g., `psql` `delete users table` or `kubectl delete namespace prod`. ### 2. Model alignment is insufficient - They use **Opus**, which Dahl describes as "remarkably well aligned" — it refuses deletion attempts repeatedly. - **But:** security "can't just be wishful thinking that Opus will always obey." - Reasoning: agents are connected to support systems and thus **prompt-injectable from outside**, so they can be manipulated by unknown inputs. ### 3. Why existing approaches fall short (per Dahl) - **Credential provisioning / ACLs / read-only credentials:** good practice, but requires careful work across many systems, and *composition of access* can create holes (accessing one system, then another). - **MCP tools with careful permissions:** breaks down once the agent **spawns subprocesses** (e.g., psql) that bypass the boundary. - **LLM gateways** (OpenRouter, LiteLLM): only cover the LLM traffic, not database protocols. - **HTTP proxies** (HTTP Jail, Crabtrap): operate at HTTP layer only; Crabtrap (from Brex) uses an LLM-as-judge on HTTP requests. - **Credential-injecting proxies** (Agent Vault): agent never sees real credentials — "an important part of the problem but not a complete solution." - **Process sandboxes** (NVIDIA's OpenShell): OS-level guards; Dahl says less relevant because they run agents on **standalone VMs**, so filesystem isolation is already handled. ### 4. Design principle - Every agent action manifests as **bytes over the wire**, via MCP or subprocesses, including **non-HTTP protocols** like Postgres. - Therefore, inspect **every byte leaving the agent**, including tunneling scenarios (e.g., agent tunneling through an EKS endpoint into a VPC-hosted Postgres). ## Claw Patrol (Deno's Solution) - **Open-source, MIT-licensed proxy** sitting in front of agents, operating **below the HTTP layer**, parsing every byte. - Features: - **Credential injection** (like Agent Vault): agents never see secret values; supports bearer headers, cookies, Postgres, ClickHouse, OAuth, **AWS SigV4**. - **Rule system written in HCL** (Terraform's language); Deno's rules file is ~1,000 lines, checked into git, changes managed precisely. - Rules can block, e.g., specific Postgres functions, **even through tunnels**. - **Approval system**: rules can reject, request human approval (e.g., Slack), run an LLM judge, or combine them. - **Dashboard** for observing agent actions, including analytics; utilitarian in design. - Agent software treated as a **black box** — no changes required. - **Networking:** runs over Tailscale or WireGuard; Deno runs agents inside a tailnet with Claw Patrol as a Tailscale exit node; Tailscale identity authenticates the dashboard. - **Acknowledged caveat:** Claw Patrol itself holds production credentials, so "you have to be very careful with it." ## Q&A Positions - **Testing:** Rule files have a test system with fixture requests for unit tests asserting requests are blocked; Claw Patrol itself has a large test suite. - **As agents get smarter, does the problem shrink?** Dahl: "We will never be able to fully trust AIs." He holds two coexisting views: - The problem **lessens** as models get smarter and better aligned (Opus is more aligned than predecessors). - **Backstop security mechanisms will always be needed.** ## Preserved Qualifications - Alignment is "not a good thing" — actually stated as: "that's not to say that alignment is not a good thing, but for real world security systems, we really do need to control this at a higher level." - Credential-injecting proxies are "an important part of the problem but not a complete solution." - Demo was **not live** (pre-recorded). # Speaker Attribution & Provenance Record ## Video **Title:** Security Firewall for Agents — Ryan Dahl, Deno **Format:** Conference-style talk with audience Q&A ## Speakers | Speaker | Role | Evidence | |---|---|---| | **Ryan Dahl** | **Creator / Presenter** | Self-identified: "my name is Ryan... I'm the CEO at Dino [Deno]"; notes he created Node.js; delivers the full talk | | **Audience members (unidentified)** | **Other — Q&A participants** | Two questions asked ("What kind of email [sic] testing do you do..." and question about agents getting smarter); Ryan restates both questions | **Narrator:** None. No **guests** identified. ## Referenced Third-Party Systems & Products - **Agents/tools:** OpenClaw (agent), Codex, Opus (Anthropic model), MCP - **Infrastructure:** PostgreSQL, Kubernetes, ClickHouse, AWS (SIGv4), GitHub, Slack, EKS, PagerDuty - **Networking/security:** Tailscale, WireGuard - **Comparable projects cited by speaker:** OpenRouter, LiteLLM, HTTP Jail, CrabTrap (Brex, "LLM as judge"), Agent Vault, Nvidia's OpenShell - **Language/tech:** HCL (Terraform configuration language) ## Promotional Segments ⚠️ - **Claw Patrol** — speaker's own open-source (MIT) project from Deno; the majority of the talk (from "So the software that we've written to address this problem is called claw patrol" onward) promotes its features, dashboard, demo, and availability ("you can check it out here"). ## Provenance Facts - All claims about Deno Deploy, incident handling, and internal practices are **first-party claims by the creator**; no independent verification in transcript. - Demo was **pre-recorded, not live** ("Unfortunately, not live"). - Q&A questions were paraphrased/restated by the speaker, so original audience wording is uncertain (one question appears garbled in transcript: "email testing"). - **Comment availability:** No metadata supplied; unknown. - **Curated metadata:** None present beyond title. How's it going? \>\> Um, my name is Ryan. Um, I'm going to I I'm I'm the CEO at Dino and uh yeah, you been developing software for for quite a while at this point. You might know one of my projects, Node.js. Um, I want to talk about um a service that we're running at Dino called Dino 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 pager duty 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 incidences. 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. Postgress, Kubernetes, Clickhouse, AWS, GitHub, Slack, uh all all sorts of things. And we we do actually give them uh rewrite access to these systems. This is very powerful uh because the agents can actually get all of the context. They can see traces in ClickHouse. They can look in the production Postgress database at what the user what you what projects a user owns. They they can look through Slack for uh communications uh GitHub logs etc. Um this actually works quite well. Uh the the agents are actually able to solve quite a lot of incidences where we previously would have a human s in the loop. But it is very dangerous of course because these agents could do nefarious things. They could start a psql subprocess and issue a delete users table. Um they could call cubecuddle 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. We use Opus and Opus is remarkably well aligned. You can really not you you can try very hard to to get it to delete the user's table and it will refuse over and over again. But this is not sufficient, right? Security can't just be wishful thinking that Opus will always obey your your wishes. Um these S sur 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 sec 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 the agent. We run agents and I assume many of you do the same on standalone VMs. So we're not very concerned about agents touching files on the file system. You know, they're they're they're uh they're properly isolated at the system level. But \[clears throat\] so you know effectively every nefarious action that that an agent could take every good action that it takes comes in the form of some network communication some some bites over the wire and how these bytes are formed can happen in various ways. You can of course call through MCP but also subprocesses and if you think of Postgress for example this is a nonHTTP protocol that uh open clock can just spawn as as a subprocess and and start connecting to to services. Um so we take the stance that we really want to understand what the bites are coming out of that agent in great detail. \>\> \[clears throat\] \>\> 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 uh 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 psql, and drop the users table, right? We're 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 complic. So yeah, just to just to highlight this, this is an outbound path the agents host can't reach on a protocol that isn't HTTP that's gated by a rule that understands SQL. These are what human S surres 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. Um, so you might ask, you might say, well, you know, there's ACL's, there's permissions, you can issue readonly uh Postgress credentials. Um, and yeah, that's true up to a point. Um, you can do careful credential provisioning and you should. Um, but this this really requires uh working across many different systems, provisioning credentials in in incredibly careful ways. And as I just demonstrated, the composition of access can lead to holes when you can access one system and then another system. um MCP, you know, you can you can uh structure all of this as uh very careful MCP uh tools that uh have the proper permissions. But, you know, then then you can't spawn subprocesses, right? You you you can't you know, as soon as as soon as the open clause spawns the the PSQL, uh you're you're kind of out broken through the the security boundary. There are quite a few projects in this space um namely projects that kind of sit in front of an agent and under look at what it's sending and try to control based on on uh the the bytes that are flowing through this. Um, LLM gateways. I think we're all familiar with Open Router, Light LLM, for example. These often have a guard rails feature that can \[clears throat\] uh guard against prompt injection uh, you know, scan for for various uh, expressions, etc. that that are going back and forth between the the LLM uh, provider. But, of course, that's just the LLM. uh you know we're we're talking to databases and stuff. Um you have systems like HTTP jail and Crabtrap that are HTTP proxies that really sit at at the HTTP layer and you uh HTTP jail for example can will allow you to write rules that say well you can make get requests but not post requests or you can access this HTTP subpath. Um, Crabt Trap is a project from Brex that has a LLM as judge that operates on the HTTP requests flowing back and forth. you have uh proxies that inject credentials into uh as they're passing out of the agent. Uh agent vault uh being a popular one where the the agent itself never actually sees the credentials of the system that it's talking to but passes some placeholder out and the proxy itself injects those credentials. This is an important part of the problem but not a complete solution. And you have things like process sandboxes like Nvidia's OpenShell that you know really are kind of OS system level uh uh guards against say accessing different file system paths um accessing different SIS calls that sort of thing but as I said before we're we're not really concerned about that because we provision uh standalone VM for for our agents. So the software that uh we've written to address this problem is called claw patrol. Uh it's an open- source MIT license project and this is a proxy that sits in front of your agents. Um it operates not at the HTP level but at a lower level. It understands each and every bite 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 uh 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. These rules are are kind of the the key piece of the system and we write them in a configuration file using a language called HCL. Uh who anybody familiar with HCL? This is like the Terraform the Terraform configuration language. Uh it actually works really well here. So we have a file that we check into git and we manage very carefully that essentially defines the permissions for all of our services at Dino and these yeah it's it's a big long file. It's like a thousand lines and you know we we manage each and every change to that in in kind of precise detail. This is an example of a rule in our configuration file that blocks certain Postgress functions from being uh being called. And so yeah, again Postgress being a nonHTP protocol and these rules can be applied even when tunneling through other systems. Um, it supports uh a number of different protocols and has a plug-in system to extend it when you run into a protocol that it is not yet familiar with. So, uh, here's here's a little demo. Unfortunately, not live. Um, but we call claw patrol run codeex in yellow mode so that it just does what you say it should do. And you tell you tell Codex, hey, delete the users table from from Postgress and Codeex um properly uh obeys and starts a Psql subprocess where it deletes the the the users table. That uh Psql subprocess opens a network connection to to our to the the Postgress server that goes through claw patrol where we pars each and every bite. We understand the Postgress protocol. We apply our rules and ultimately reject that what we call an action from uh from doing something destructive. Claw Patrol has a dashboard that lets you see what your agents are doing. So at the top you can see a couple of different uh devices or agents and the the various requests that are flowing through. Some of them being denied, some of them need approval which I'll talk about in a second. And you can click into to each request or uh action as we call it because it's more general than HTTP requests and see the details of of what's going on. there's there's analytics and yeah it's it's very uh utilitarian driven. It's like what what we need to understand our own agents. Um there as I said there's there's an approval system in this. So you can route, you can define rules that don't just reject requests or actions but uh ask a human for example in a slack channel or run an LLM judge over over this um or any combination thereof, right? Maybe first first get an LLM judge and then get approval in Slack. uh so that you can have again very precise control over what your agents are doing outside of the agent software itself right we we treat the agent software as a black box right we we don't require any changes to to that software um I mentioned credential injection before uh claw patrol has very detailed support for all sorts of systems credentials come in many different forms they're not just uh bearer uh headers uh it handles cookies it handles Postgress as I mentioned uh click house supports all sorts of uh ooth protocols supports very complex things like AWS SIG v4 um so yeah this I guess what I'm trying to uh say is that this is this is really born out of utility here and meant for real world systems This is not just you know kind of an imaginary scenario. \[clears throat\] Um this system works over tail scale or wire guard. Um we ourselves run claw patrol run our agents inside of tail scale inside of a tail net and claw patrol acts as a tail scale exit node. Um we also lean on tail scale for authentication to the dashboard. So your your tail your tail scale identity actually allows you access to to the dashboard so that we don't have to layer on another authentication mechanism. But we also have this wire guard for people who have not bought into the wonderful tail scale ecosystem. But this works very well for us because we know that all of our stuff is is off the internet and all of these very security sensitive things are are uh tightly controlled. Claw Patrol itself is holding all of these credentials to production systems. So you have to be very careful with it. Um so yeah, this the thesis here is is basically that agents can't be trusted to police themselves. that includes security plugins or or modifications to the to the agent software itself. The the security boundary has to be elsewhere. And that's not to say that alignment is not a good thing, but uh you know for for real world security systems, we we really do need to control this at at a higher level. And uh claw patrol is our attempt to uh make this work for ourselves. Um and yeah, you can you can check it out here. \>\> \[applause\] \>\> I might have time for one question or so. \>\> Yes sir. \>\> What kind of email testing do you do on this to make sure it's working? \>\> Uh yeah. So the question is what what sort of testing do we do we do to make make sure it works properly? Um I I didn't mention but but there this rule file actually has a test system along with it where you can provide uh fixtures action like fixture requests that can flow through the rules and then you can uh essentially create unit tests to make sure that that fixture is always you know that request it will always be blocked by by your set of rules. And then of course for the claw patrol software itself we have a a large suite of of testing. Yes sir. \>\> So the question is as as agents get smarter does this problem get bigger or smaller? I think I think we can we will never be able to fully trust uh AIs. I think it becomes less and less of a problem as they are smarter, have better context, know that they're working with a company, know that that they shouldn't be doing bad things. Opus is more aligned than previous models, but I think we're always going to have to have uh backs stop security mechanisms. Um, cool. Well, I I'll be around for other questions, but thank you very much. \[applause\] \>\> \[music\]