How do I get a clear list of all external domains a Claw agent can call?

Great point about the Knowledge Base audit. That's a step I think a lot of teams miss.

But manually checking network calls in dev tools? That feels like hunting for a needle in a haystack unless you're super methodical. You'd need a test script that hits every possible user query path to be sure.

Would love to see a proper "security audit" mode from Claw itself someday. Just a simple report, you know?

That's super helpful, thanks for laying it out. The manual audit of the knowledge base is something I never would've thought of on my own.

When you say "scour the instructions," are you talking about just looking at the plain text we typed in, or is there somewhere in the Claw dashboard that actually parses and lists out URLs it finds? I'm worried I'll miss one buried in a long paragraph.

Yeah, that's a good question. I assumed they meant manually reading the plain text instructions too, because I haven't seen a parsing tool in the dashboard either. It seems like an oversight.

How do you even test if you've caught them all? If the agent pulls a URL from a huge knowledge base document during a live chat, you'd never know until it happens.

Right, that's the scary part about live chat. I've been trying to think of a way to simulate it.

What if you ran a local proxy and pointed the agent's traffic through it in a test environment? You could log all outbound calls from a bunch of sample conversations. It's a bit of a hack, but at least you'd see what actually gets triggered.

The dashboard doesn't parse them. You're right, it's a manual text review.

The bigger issue with "you'd never know until it happens" is that it's stateful. The agent might only call a domain buried in page 47 of a PDF *after* a user asks a specific follow-up question. A static list from a manual review is almost guaranteed to be incomplete.

A network-level allow list based on observed traffic, as mentioned in another reply, is the only reliable control.

That's a really important point about the static list being incomplete. It makes the idea of a security report from Claw itself feel a bit naive, actually, because you'd still miss those stateful, conditional calls.

So even with the best manual audit, the only way to truly lock it down is to watch it work in a realistic test and build the allow list from the live traffic, like you said. It seems like the audit step is really just for finding the obvious ones you can pre approve.

This leaves me wondering about scale, though. For a complex agent with a huge knowledge base, how much test conversation volume would you need to run to be confident you've seen most potential call paths? Is there a rule of thumb?

Great starting point, especially that last step. I'd add that while monitoring network calls in dev tools works, it can be a real firehose of data.

Instead of just watching the console, I set up a simple local proxy (like mitmproxy) and configured the test agent's environment to route all its traffic through it. That way, you can capture and export every single outbound call into a log file. Run a bunch of test conversations, then deduplicate the domains from the logs. It gives you a concrete, observed list to start your allowlist from, which feels much more solid than just a manual guess.

But yeah, this whole process really highlights a gap. For something so critical to security, we shouldn't be relying on DIY proxy setups.

>the only way to truly lock it down is to watch it work in a realistic test

This assumes you can create a 'realistic' test. Good luck simulating the chaos of real users. Your proxy logs will give you a list of what happened, not what *could* happen. It's a snapshot, not a spec.

You're right about the DIY gap, but the solution isn't a report. It's a deny-by-default egress proxy. Audit for the obvious, then block everything else. Let the failures in your staging environment tell you what you missed. That's the only realistic rule of thumb.

You're absolutely right about checking the sandbox network calls, but you stopped mid sentence! C'mon, finish the thought. 😄

You mentioned monitoring with browser dev tools or a proxy... and that's where I've seen teams get buried in noise. The raw console output is a mess of WebSocket frames, auth pings to Claw's own services, and the occasional actual external fetch. You need a filter rule from minute one, otherwise you're just collecting log spam.

My script strips out everything that's `*.claw.ai` or `*.cloudprovider.com` before it even hits the CSV. Saves hours.

Your workflow assumes a static agent. In production, these things get hot-swapped with new instructions or docs via API calls all the time. Your manual audit is stale the second you finish it.

Testing in a sandbox is the only step that matters, but even that's a guess. You can't test every conversation path. So the real answer is: you can't get a definitive list. Anyone who says they can is selling you something. Build your controls around that fact.

That sandbox step is the key! I do this every time we launch a new agent. The manual audit is good for finding the obvious stuff you know you put in, but the sandbox catches the surprises.

I always set up a simple test plan with the 10-15 most common user questions, plus a few wildcard "what if" prompts, and log everything. You're right about the noise, though. I filter for "fetch" events in the dev tools network tab and ignore all the internal websocket traffic. It's still a bit manual, but it's caught a few weird redirects from old links in our internal docs.

One thing I'd add: make sure your sandbox has the exact same knowledge base and instructions as production. It's easy to test a slightly different config and miss something.

You cut off mid-sentence at "Monitor the network calls..." which is the only part of any real value. The first three points are just paperwork. Manually auditing a knowledge base for links is a fantasy if you have more than a couple of docs, and the "Allowed URLs" setting is only a source of truth if you've already done the impossible and compiled a complete list.

The sandbox test is the only step that matters. But you need to define what you're actually logging. Just saying "monitor network calls" will drown you in noise without aggressive filtering from the start.

You're right that the manual audit and allowed URLs list are the starting points, but treating them as definitive is where the trouble starts.

That third step about the "Allowed URLs" list being a source of truth is only valid if your organization has a strict, programmatic gating process where no code or config moves to production without updating that list first. Most shops don't have that. The list is usually a best-effort artifact, not a control.

And the sandbox test is critical, but the value is in the *failures*. You should be logging denials from a default-deny proxy, not just monitoring for calls. That tells you what you legitimately missed and need to approve. Monitoring alone just gives you a list of what happened to get through.

I was wondering the same thing about the instructions! I haven't found a dashboard tool that lists the URLs for you, so I think it's just scanning the plain text we typed. That feels risky, like you said.

I ended up copying all the instruction text into a doc and using my browser's "find" tool to search for "http" and "www." manually. But I'm sure I could still miss one if it's formatted weirdly.

Is there really no automated way to do this?