AI Engineer

Security Firewall for Agents — Ryan Dahl, Deno

1848 summary words 8 min summary Watch video

Start with the signal

8 min read

Summary

At-a-Glance

  • Verdict: Watch fully
  • Core thesis: Treat production agents as untrusted software and enforce their authority outside the model—at the network/action layer—because model alignment, MCP-tool permissions, and conventional credential controls can all be bypassed by subprocesses and compositional access paths.
  • Why it matters: This is a concrete control-plane pattern for allowing agents to investigate and remediate production incidents with broad context and write access without giving them unconstrained ability to damage databases, Kubernetes, AWS, or other critical systems.
  • Best use: Use it to pressure-test OpenClaw or SRE-agent architecture: identify every outbound path an agent can create, then evaluate whether a protocol-aware enforcement proxy, centralized secret injection, versioned policy, and approval workflow should sit outside the agent.

Executive Summary

Ryan Dahl describes Deno Deploy's use of agents, including OpenClaw, to handle PagerDuty incidents. The agents can inspect operational context across Postgres, Kubernetes, ClickHouse, AWS, GitHub, and Slack, and in some cases receive write access. This has enabled resolution of incidents that previously required a human SRE, but it creates an unacceptable failure mode: an agent prompted incorrectly or compromised through external support inputs could execute destructive production actions.

His key architectural position is that agents cannot be the security boundary. Even a well-aligned model such as Opus may refuse plainly malicious instructions, but alignment is not a dependable security guarantee—particularly when the agent ingests externally supplied data and can be prompt-injected. The meaningful boundary must instead control the actual network bytes leaving the agent, including traffic created by arbitrary subprocesses such as psql rather than only requests emitted through approved MCP tools or HTTP clients.

Deno's proposed implementation, Claw Patrol, is an open-source, protocol-aware outbound proxy. It parses and authorizes actions at a lower level than HTTP, injects credentials so agents never see secrets, applies granular rules defined in a Git-managed HCL policy file, and can deny, route for human approval, or submit actions to an LLM judge. A demonstrated policy blocks a Codex-created psql subprocess from deleting a Postgres users table.

The presentation is especially useful because it shifts the discussion from prompt guardrails to enforcement mechanics in complex infrastructure: tunneled paths, non-HTTP protocols, credential formats such as AWS SigV4, and policy regression tests. Its main limitation is that it is an architecture/product talk rather than an independent security evaluation; it asserts protocol coverage and efficacy without presenting attack-test results, performance data, or a full threat model for compromise of the proxy itself.

Key Takeaways

  • Claim: SRE agents can be operationally valuable only when they can access broad, cross-system context, including systems that permit consequential writes. | Evidence: Deno gives agents access to Postgres, Kubernetes, ClickHouse, AWS, GitHub, and Slack; Dahl says they can inspect traces, production project ownership, communications, and logs, and have resolved incidents previously requiring a human SRE. | Implication: Designing agents around narrow read-only tools may prevent useful remediation; the stronger pattern is broad operational capability constrained by an external authorization layer. | Caveat: Broad access is precisely what turns prompt injection or model failure into a production-risk problem, so this is not an argument for unrestricted credentials.
  • Claim: Model alignment and agent-internal guardrails are insufficient as the primary safety mechanism for agents connected to production systems. | Evidence: Dahl says Opus repeatedly refuses requests to delete a users table, but Deno still treats the agent as untrusted because support-system inputs can carry prompt injection and unknown inputs could manipulate the model into believing a destructive action is justified. | Implication: Do not make model behavior, system prompts, or a security plugin inside the agent the final authorization decision for irreversible external actions. | Caveat: He does not dismiss alignment; he expects better models to reduce the frequency of bad actions, but argues backstop controls will remain necessary.
  • Claim: The enforcement point must cover all outbound agent actions, including raw and non-HTTP connections created by subprocesses—not just MCP calls, LLM traffic, or HTTP requests. | Evidence: The example threat path is an agent tunneling through an EKS endpoint into a VPC-resident production Postgres database, spawning psql, and issuing a destructive SQL command. Dahl explicitly notes that careful MCP tools cease to be a boundary once the agent can spawn psql. | Implication: Inventory egress paths, tunnel paths, and process execution paths before declaring an agent contained; security reviews should be organized around reachable actions rather than the agent's nominal tool list. | Caveat: A proxy must understand each relevant protocol or have plugins for it; generic HTTP-only controls do not cover database-native traffic.
  • Claim: Claw Patrol is designed as an agent-agnostic, protocol-aware egress firewall that can inspect, authorize, and block actions independently of the agent runtime. | Evidence: The open-source MIT-licensed proxy sits in front of an agent, parses outbound bytes at a lower layer than HTTP, supports protocols including Postgres and ClickHouse, and has a plugin system for additional protocols. In the demo, Codex runs in an obedient mode, launches psql to delete the users table, and Claw Patrol rejects the action. | Implication: A reusable security control plane can protect multiple agent frameworks as black boxes, reducing dependence on each framework's individual tool-permission model. | Caveat: The transcript does not establish complete protocol coverage, bypass resistance, or how safely the proxy handles parser discrepancies and encrypted traffic.
  • Claim: Policy should be explicit, granular, version-controlled, and testable rather than embedded informally in credentials or prompts. | Evidence: Deno maintains roughly a thousand-line HCL configuration file in Git that defines service permissions; a cited rule blocks specific Postgres functions. The system accepts action-like fixtures so teams can unit-test that requests remain blocked as policies change. | Implication: Treat agent authorization policy like infrastructure code: require code review, maintain deny-regression fixtures for known dangerous actions, and make policy changes auditable. | Caveat: A large policy file creates its own operational burden: policy completeness, review quality, and rule drift become critical governance concerns.
  • Claim: Credential isolation and graduated approval routes complement hard allow/deny rules for high-risk production actions. | Evidence: Claw Patrol holds and injects secrets rather than exposing them to the agent, with support for cookies, Postgres credentials, OAuth flows, and AWS SigV4. Rules can reject actions outright, send them for Slack approval, invoke an LLM judge, or chain an LLM judgment before human approval. | Implication: Separate authority from reasoning: issue no raw production secrets to agent sessions, auto-allow only well-bounded actions, and reserve approval workflows for actions whose risk cannot be captured reliably in deterministic policy. | Caveat: The proxy becomes a highly sensitive credential holder; Dahl explicitly says it must be secured carefully.

Detailed Brief

How this differs from adjacent agent-security approaches

  • Claims: LLM gateways address model-provider traffic and may scan for prompt injection, but do not govern database or infrastructure protocols.; HTTP proxies can constrain HTTP methods or paths, but their control scope stops at HTTP.; Secret-injection proxies solve secret exposure but do not independently determine whether the action made with the credential is safe.; OS sandboxes are useful for filesystem and syscall restriction, but Deno considers network action governance the principal issue after provisioning agents in isolated VMs.
  • Evidence: Dahl names OpenRouter and LiteLLM as LLM-gateway examples, HTTP Jail and Brex's Crab Trap as HTTP-layer examples, Agent Vault for credential injection, and NVIDIA OpenShell for process sandboxing.; Crab Trap is described as using an LLM-as-judge over HTTP requests.
  • Caveats: These tools are not portrayed as useless; the argument is that each covers a necessary but incomplete portion of the problem.
  • Implications: Avoid selecting a single tool category based on its security label; evaluate its protocol boundary, credential boundary, and ability to prevent indirect access through connected systems.

Network placement and operational interface

  • Claims: Deno runs agents within a Tailscale tailnet and positions Claw Patrol as a Tailscale exit node, keeping sensitive systems off the public internet.; Tailscale identity is reused for dashboard authentication, while WireGuard is also supported for deployments outside Tailscale.; The dashboard exposes devices/agents, allowed and denied actions, actions requiring approval, action details, and analytics.
  • Evidence: Dahl states that the proxy itself stores production credentials and that Tailscale-based deployment helps tightly control this security-sensitive component.
  • Caveats: Reusing network identity for dashboard access simplifies authentication but makes identity and tailnet administration part of the security perimeter.
  • Implications: For a similar deployment, locate the enforcement point in the private connectivity fabric and give the proxy infrastructure-level hardening and monitoring commensurate with a production secrets broker.

Notable Concepts & Terms

  • Claw Patrol: Deno's MIT-licensed, protocol-aware proxy intended to act as an external action firewall for agents, including those that invoke arbitrary subprocesses.
  • Action: Claw Patrol's broader unit of authorization; it is deliberately more general than an HTTP request and can represent protocol-level operations such as database commands.
  • Protocol-aware egress enforcement: The central pattern: inspect and authorize outbound traffic according to the semantics of its protocol, rather than only filtering model prompts or network destinations.
  • Compositional access: The risk that individually acceptable permissions combine into a dangerous path, such as reaching an EKS endpoint and then using it to access a production database.
  • HCL policy: Terraform's configuration language, used here as a Git-managed rules language for describing permissible agent actions and blocking specific database functions.
  • Credential injection: A proxy-held-secret model in which agents use placeholders or mediated requests while the enforcement layer supplies the actual credentials only at egress.
  • LLM judge: An optional probabilistic approval mechanism that can evaluate an action before it proceeds; Dahl presents it as combinable with, not substituting for, deterministic policy and human approval.
  • Tailscale exit node: The deployment mechanism through which Deno routes agent traffic to Claw Patrol inside a private tailnet, making the firewall a network chokepoint.

Operator Notes / Why Ken Should Care

  • Run a threat-model exercise for each production agent that starts with every reachable outbound protocol, subprocess, tunnel, proxy, and private-network route—not its advertised MCP tools.
  • Require an external authorization point for all state-changing production actions; explicitly test whether psql, kubectl, cloud CLIs, SDKs, and direct sockets can bypass it.
  • Create a Git-reviewed action-policy repository with negative fixtures for destructive operations such as table drops, namespace deletion, credential mutation, and bulk user-impacting changes.
  • Classify actions into deterministic allow, deterministic deny, and approval-required tiers; define the human escalation channel and avoid treating an LLM judge as the sole gate for irreversible actions.
  • Keep production credentials out of agent context and sessions; assess the proposed credential broker/proxy as a tier-zero asset with dedicated hardening, access logging, recovery procedures, and compromise response.
  • Evaluate Claw Patrol specifically for protocol coverage needed by Ken's stack, proxy-bypass resistance, parser correctness, encrypted-traffic handling, audit export, and policy-test ergonomics before adopting it.

Source/Metadata

  • Title: Security Firewall for Agents — Ryan Dahl, Deno
  • Transcript words: 4026
  • Duration seconds: 1146
  • Timestamp note: No timestamps or chapter markers were present. The transcript substantially repeats the main presentation, so the effective unique content is shorter than the reported word count.
Search this video Resume transcript at 0%
Full transcript 2267 words · 18 min read
0:12

How's it going?

0:16

My name is Ryan. I'm the CEO at Dino, and you've been developing software for quite a while at this point. You might know one of my projects, Node.js. I want to talk about a service that we're running at Dino called Dino Deploy. This is a system for hosting websites, and it has incidences. It has downtime occasionally, and 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, and recently we've been playing around with using agents to automatically service these incidences, in particular OpenClaw, but other agents as well, and we've found a pattern that is working pretty well for us that I want to share with you.

0:28

We actually give OpenClaw access to all sorts of systems: Postgres, Kubernetes, ClickHouse, AWS, GitHub, Slack, all sorts of things, and we do actually give them rewrite access to these systems. This is very powerful because the agents can actually get all of the context. They can see traces in ClickHouse, they can look in the production Postgres database at what projects the user owns, they can look through Slack for communications, GitHub logs, etc. This actually works quite well. The agents are actually able to solve quite a lot of incidences where we previously would have a human SRE in the loop.

0:36

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. They could call kubectl delete namespace prod. They could decide somehow that solving the incident means removing all of the users. And of course, we don't want that. We use Opus, and Opus is remarkably well aligned. You can try very hard to get it to delete the users 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 wishes.

0:52

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. Who knows what sort of string of characters could send Opus into some bad state that allows it to think that it's taking the right action by doing something very undesirable. So we take the stance that the agents themselves have to be untrusted software. You can't rely on the agent itself to guard what it's doing. We're not very concerned about agents touching files on the file system. They're properly isolated at the system level.

0:57

But effectively, every nefarious action that an agent could take, every good action that it takes, comes in the form of some network communication, some bytes 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 Postgres, for example, this is a non-HTTP protocol that OpenClaw can just spawn as a subprocess and start connecting to services. So we take the stance that we really want to understand what the bytes are coming out of that agent in great detail.

1:07

This can get very tricky in real-world systems. For example, we have a production Postgres database in AWS 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 PSQL, and drop the users table. Right? 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 complex network topologies.

1:15

So just to highlight this, this is an outbound path the agent's host can't reach on a protocol that isn't HTTP that's gated by a rule that understands SQL. These are what human SREs would do. And how can we empower these agents to have the same access that a human might?

1:22

So you might ask, you might say, well, there's ACLs, there's permissions, you can issue read-only Postgres credentials. And that's true, up to a point. You can do careful credential provisioning, and you should. But this really requires working across many different systems, provisioning credentials 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. MCP, you can structure all of this as very careful MCP tools that have the proper permissions. But then you can't spawn subprocesses, right? As soon as the OpenClaw spawns the PSQL, you've broken through the security boundary.

1:30

There are quite a few projects in this space, namely projects that sit in front of an agent and look at what it's sending and try to control based on the bytes that are flowing through this. LLM gateways, I think we're all familiar with: Open Router, Light LLM, for example. These often have a guardrails feature that can guard against prompt injection, scan for various expressions, et cetera, that are going back and forth between the LLM provider. But of course, that's just the LLM. We're talking to databases and stuff.

1:42

You have systems like HTTP jail and Crab Trap that are HTTP proxies that really sit at the HTTP layer, and HTTP jail, for example, 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. Crab Trap is a project from Brex that has an LLM as judge that operates on the HTTP requests flowing back and forth. You have proxies that inject credentials as they're passing out of the agent, Agent Vault being a popular one, where 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 really are OS system-level guards against, say, accessing different file system paths, accessing different syscalls, that sort of thing. But as I said before, we're not really concerned about that because we provision a standalone VM for our agents.

1:50

So the software that we've written to address this problem is called Claw Patrol. It's an open source MIT license project, and this is a proxy that sits in front of your agents. 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 whatever agent software you're using doesn't ever actually see secret values. And in particular, it has a very advanced rule system that allows you to say in precise detail how and what requests get transferred out of the agent and talk to the outside world.

2:03

These rules are the key piece of the system, and we write them in a configuration file using a language called HCL. Anybody familiar with HCL? This is the Terraform configuration language. 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 this, yeah, it's a big long file. It's like a thousand lines. And we manage each and every change to that in precise detail.

2:12

This is an example of a rule in our configuration file that blocks certain Postgres functions from being called. And so, again, Postgres being a non-HTTP protocol. And these rules can be applied even when tunneling through other systems. It supports a number of different protocols and has a plugin system to extend it when you run into a protocol that it is not yet familiar with.

2:23

So here's a little demo, unfortunately not live. But we call Claw Patrol run codex in yellow mode so that it just does what you say it should do. And you tell codex, hey, delete the users table from Postgres. And codex properly obeys and starts a PSQL subprocess where it deletes the users table. That PSQL subprocess opens a network connection to the Postgres server that goes through Claw Patrol, where we parse each and every byte. We understand the Postgres protocol. We apply our rules and ultimately reject that, what we call an action, from doing something destructive.

2:33

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 devices or agents and the various requests that are flowing through, some of them being denied, some of them needing approval, which I'll talk about in a second. And you can click into each request or action, as we call it because it's more general than HTTP requests, and see the details of what's going on. There's analytics, and it's very utilitarian-driven. It's what we need to understand our own agents.

2:40

As I said, there's an approval system in this. So you can define rules that don't just reject requests or actions, but ask a human, for example, in a Slack channel, or run an LLM judge over this, or any combination thereof. Maybe first get an LLM judge and then get approval in Slack so that you can have, again, very precise control over what your agents are doing outside of the agent software itself. We treat the agent software as a black box. We don't require any changes to that software.

2:46

I mentioned credential injection before. Claw Patrol has very detailed support for all sorts of systems. Credentials come in many different forms. They're not just bearer headers. It handles cookies. It handles Postgres, as I mentioned. ClickHouse supports all sorts of OAuth protocols. It supports very complex things like AWS SIG v4. So I guess what I'm trying to say is that this is really born out of utility here and meant for real-world systems. This is not just an imaginary scenario.

2:56

This system works over TailScale or WireGuard. We ourselves run our agents inside of TailScale, inside of a TailNet, and Claw Patrol acts as a TailScale exit node. We also lean on TailScale for authentication to the dashboard. So your TailScale identity actually allows you access to the dashboard so that we don't have to layer on another authentication mechanism. But we also have this WireGuard for people who have not bought into the wonderful TailScale ecosystem.

3:05

But this works very well for us because we know that all of our stuff is off the internet and all of these very security-sensitive things are tightly controlled. Claw Patrol itself is holding all of these credentials to production systems, so you have to be very careful with it.

3:16

So the thesis here is that agents can't be trusted to police themselves. That includes security plugins or modifications to the agent software itself. The security boundary has to be elsewhere. And 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. And Claw Patrol is our attempt to make this work for ourselves. And you can check it out here. I might have time for one question or so. Yes, sir. What kind of e-mail testing do you do to make sure it's working properly?

3:40

Yeah, so the question is what sort of testing do we do to make sure it works properly? I didn't mention, but this rule file actually has a test system along with it where you can provide fixtures, action-like fixture requests that can flow through the rules, and then you can essentially create unit tests to make sure that that fixture, that request, will always be blocked by your set of rules. And then, of course, for the Claw Patrol software itself, we have a large suite of testing. Yes, sir.

4:09

So the question is, as agents get smarter, does this problem get bigger or smaller? I think we will never be able to fully trust 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 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 backstop security mechanisms. Cool. Well, I'll be around for other questions, but thank you very much.

4:23

But, so, you know, effectively every nefarious action that an agent could take, every good action that it takes, comes in the form of some network communication, some bytes over the wire. And how these bytes are formed can happen in various ways. You can, of course, call through MCP, but also sub-processes. And if you think of Postgres, for example, this is a non-HDP protocol that OpenClaw can just spawn as a sub-process and start connecting to services. So, we take the stance that we really want to understand what the bytes are coming out of that agent in great detail. This can get very tricky in real-world systems. So, for example, we have a

5:19

production Postgres database in AWS 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 PSQL, and drop the users table. Right? 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 complex network topologies. So, yeah, just to highlight this. This is an outbound path the agent's host can't reach on a

6:12

protocol that isn't HTTP that's gated by a rule that understands SQL. These are what human SREs would do. And how can we, you know, empower these agents to have kind of the same access that a human might?

6:35

So, you might ask, you might say, well, you know, there's ACLs, there's permissions, you can issue read-only Postgres credentials. And yeah, that's true, up to a point. You can do careful credential provisioning, and you should. But this really requires working across many different systems, provisioning credentials 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. MCP, you know, you can structure all of this as very careful MCP tools that have the proper permissions. But, you know,

7:25

then you can't spawn sub-processes, right? You can't, you know, as soon as the open clause spawns the PSQL, you're kind of out broken through the security boundary. There are quite a few projects in this space, namely projects that kind of sit in front of an agent and look at what it's sending and try to control based on the bytes that are flowing through this. LLM gateways, I think we're all familiar with, Open Router, Light LLM, for example, these often have a guard rails feature that can guard against prompt injection, you know, scan for various expressions, et cetera, that are going back and forth between the LLM

8:23

provider. But of course, that's just the LLM, you know, we're talking to databases and stuff. You have systems like HDP jail and Crab Trap that are HDP proxies that really sit at the HDP layer and HDP 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 HDP sub path. Crab Trap is a project from Brex that has a LLM as judge that operates on the HDP requests flowing back and forth. You have proxies that inject credentials as they're passing out of the agent. Agent Vault being a popular one where the agent itself never

9:18

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 guards against, say, accessing different file system paths, accessing different syscalls, that sort of thing. But as I said before, we're not really concerned about that because we provision a standalone VM for our agents. So the software that we've written

10:04

to address this problem is called Claw Patrol. It's an open source MIT license project, and this is a proxy that sits in front of your agents. It operates not at the HDP 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 whatever agent software you're using doesn't actually, doesn't ever actually see secret values. And in particular, it has a very advanced rule system that allows you to say in precise details how and what requests get transferred out of the

10:58

agent and talk to the outside world. These rules are kind of the key piece of the system, and we write them in a configuration file using a language called HCL. Anybody familiar with HCL? This is like the Terraform, the Terraform configuration language. 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 a big long file. It's like a thousand lines. And we manage each and every change to that in kind of precise detail. This is an example of a rule in our configuration file that blocks certain Postgres

11:48

functions from being called. And so, yeah, again, Postgres being a non-HDP protocol. And these rules can be applied, even when tunneling through other systems. It supports a number of different protocols and has a plugin system to extend it when you run into a protocol that it is not yet familiar with. So here's a little demo, unfortunately not live. But we call Claw Patrol run codecs in yellow mode so that it just does what you say it should do. And you tell codecs, hey, delete the users table from Postgres. And codecs properly obeys and starts a PSQL subprocess where it deletes the users table. That PSQL subprocess opens a network connection

12:50

to the Postgres server that goes through Claw Patrol where we parse each and every byte. We understand the Postgres protocol. We apply our rules and ultimately reject that, what we call an action from doing something destructive.

13:14

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 devices or agents and 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 each request or action as we call it because it's more general than HTTP requests and see the details of what's going on. There's analytics and yeah, it's very utilitarian driven. It's like what we need to understand our own agents. As I said, there's an approval system in this. So you can route, you can define

14:03

rules that don't just reject requests or actions, but ask a human, for example, in a Slack channel or run an LLM judge over this or any combination thereof. Maybe first get an LLM judge and then get approval in Slack so that you can have, again, very precise control over what your agents are doing outside of the agent software itself. We treat the agent software as a black box. We don't require any changes to that software. I mentioned credential injection before. Claw Patrol has very detailed support for all sorts of systems. Credentials come in many different forms. They're not just bearer headers. It handles cookies, it handles

14:59

the place. Postgres as I mentioned. ClickHouse supports all sorts of OAuth protocols. Supports very complex things like AWS SIG v4. So yeah, I guess what I'm trying to say is that this is really born out of utility here and meant for real world systems. This is not just kind of an imaginary scenario.

15:29

This system works over TailScale or WireGuard. We ourselves run our agents inside of TailScale, inside of a TailNet, and Claw Patrol acts as a TailScale exit node. We also lean on TailScale for authentication to the dashboard. So your TailScale identity actually allows you access to the dashboard so that we don't have to layer on another authentication mechanism. But we also have this WireGuard for people who have not bought into the wonderful TailScale ecosystem. But this works very well for us because we know that all of our stuff is off the internet and all of these very security sensitive things are tightly controlled.

16:22

Claw Patrol itself is holding all of these credentials to production systems, so you have to be very careful with it. So yeah, the thesis here is basically that agents can't be trusted to police themselves. That includes security plugins or modifications to the agent software itself. The security boundary has to be elsewhere. And 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. And Claw Patrol is our attempt to make this work for ourselves. And yeah, you can check it out here.

17:17

I might have time for one question or so. Yes, sir. What kind of e-mail testing do you do to make sure it's working properly? Yeah, so the question is what sort of testing do we do to make sure it works properly? I didn't mention, but this rule file actually has a test system along with it where you can provide fixtures, action like fixture requests that can flow through the rules and then you can essentially create unit tests to make sure that that fixture is always, you know, that request will always be blocked by your set of rules. And then of course for the Claw Patrol software itself, we have a large suite of testing. Yes, sir.

18:10

So the question is as agents get smarter, does this problem get bigger or smaller? I think we can, we will never be able to fully trust 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 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 backstop security mechanisms. Cool. Well, I'll be around for other questions, but thank you very much. I'll be around for now. I'll be around for now. I'll be around for now. I'll be around for now. I'll be around for now. I'll be around for now. I'll be around for now.

18:50

I'll be around for now. I'll be around for now. I'll be around for now. I'll be around for now. I'll be around for now. I'll be around for now. I'll be around for now. I'll be around for now. I'll be around for now. I'll be around for now. I'll be around for now. I'll be around for now. I'll be around for now. you

Reading tools

Type to find a passage

Appearance
Ask this transcript

Notebook

Export Markdown

Add a note