> If you have a limited budget of tokens as a defender, maybe the best thing to spend them on is not red teaming, but formalizing proofs of your code's security.
You can only do this if you have a very clear sense of what your code should be doing. In most codebases I've ever worked with, frankly, no one has any idea.
Red teaming as an approach always has value, but one important characteristic it has is that you can apply red teaming without demanding any changes at all to your code standards, or engineering culture (and maybe even your development processes).
Most companies are working with a horrific sprawl of code, much of it legacy with little ownership. Red teaming, like buying tools and pushing for high coverage, is an attractive strategy to business leaders because it doesn't require them to tackle the hardest problems (development priorities, expertise, institutional knowledge, talent, retention) that factor into application security.
Formal verification is unfortunately hard in the ways that companies who want to think of security as a simple resource allocation problem most likely can't really manage.
I would love to work on projects/with teams that see formal verification as part of their overall correctness and security strategy. And maybe doing things right can be cheaper in the long run, including in terms of token burn. But I'm not sure this strategy will be applicable all that generally; some teams will never get there.
What it adds is making this kind of thing easy for normies, even if it's neither the best way to do things nor very difficult for hobbyists to do using existing tech.
Maybe it's the wrong approach, maybe what people really want is more deterministic software that they use agents to help write. But this kind of thing can maybe serve as a prototyping phase for that. Perhaps in the future, people's assistants will offer to "solidify" frequently used workflows into software that minimizes or eliminates the LLM's role. For existing Claude Code users, its like "please just skip to that step! its cheaper and more secure and more reliable". But to many people who are interested in automation, perhaps that seems out of reach as a first step.
That's actually the best hypothesis I've heard to date.
My immediate reaction to anything someone says they're using OpenClaw for is "That's great, but it would have taken the same amount of effort to ask your LLM to write a script to do the same thing, which would be better in every possible way."
My approach to automation projects is just about the polar opposite of something like OpenClaw. How can I take this messy real-world thing and turn it into structured data? How can I build an API for the thing that doesn't have one? How can I define rules and configuration in a way that I can understand more about how something is working instead of less? How can I build a dashboard or other interface so I can see exactly the information I want to see instead of having to read a bunch of text?
It wasn't really until people started building things with coding assistants that I even saw the value in LLMs, because I realized they could speed up the rate at which I can build tools for my team to get things OUT of chat and INTO structured data with clean interfaces and deterministic behavior.
> "That's great, but it would have taken the same amount of effort to ask your LLM to write a script to do the same thing
As a no-longer-Claw-user, hard disagree. The convenience is being able to ask it to do something while I'm grocery shopping and have it automatically test it etc. Sure, I can set up Claude Code or some other tool similarly, but the majority of us aren't going to take the time to set it up to do what OpenClaw does out of the box.
I had OpenClaw do a lot of stuff for me in the 2-3 weeks I used it than I have with pi/Claude since I stopped using it.
Lots of simple one offs. Stuff like "Here's the URL for a forum thread that has 10 pages of messages. Go through all of them and tell me if information X is in there." Or "Here is the site to after school activities. Check it once a day and notify me if there is anything that begins in March."
Also, got it to give me the weather information I always want - I've not found a weather app that does it and would always have to go to a site and click, click, click.
I can add TODOs to my todo list that's sitting on my home PC (I don't have todos on the cloud or phone).
All of these can be vibe coded, but each one would take more effort than just telling OpenClaw to do it.
These are actually really great examples, because I've done several similar things with a more code-based deterministic approach, still utilizing an LLM.
I also have a number of sites that I query regularly with LLMs, but I use a combination of RSS and crawlers to pull the info into a RAG and query that, and have found the built-in agent loops in my LLM to be sufficient for one-offs.
I also hate most weather apps, so I have a weather section on my Home Assistant dashboard that pulls exactly what I want from the sources I want that my LLM helped me configure.
I also have my main todo list hosted on a computer at home, but since all of my machines including my phone are on the same virtual wireguard network, I use my editor of choice to read and write todos on any device I use as if it were a local file, and again, it's something my local LLM has access to for context.
I don't think either approach is wrong, but I much prefer being able to have something to debug if it doesn't behave the way I expect it to. And maybe part of the reason I'm skeptical of the hype is that a lot of the parts of this setup aren't novel to me: I had crawlers and RSS readers and a weather dashboard and private access to a well-organized filesystem across devices before LLMs were a thing - the only difference now is that I'm asking a machine to help me configure it instead of relying on a mix of documentation, example code, and obscure Reddit posts.
It gives me a pleasant interface to talk to my desktop from my phone. I can just send my computer a discord message and have it execute some arbitrarily complex task for me.
It does stuff like this all the time. It loves doing this with scripts with sed, so I'm not surprised to hear about it trying to do this with binaries. It's definitely wilder, though
It frequently gets indentation wrong on projects, then tries to write sed/awk scripts. Can't get it right, then write a python script that reformats the whole file on stdout, makes sure the indentation is correct, then writes requests an edit snippet.
And you might be thinking. Well, you should use a code formatter! But I do!
And then you might say, well surely you forgot to mention it in you AGENTS/CLAUDE file. Nope, it's there, multiple times even in different sections because once was apparently not enough.
And lastly, surely if I'm watching this cursed loop unfold and am approving edits manually, like some bogan pleb, I can steer it easily... Well, let me tell ya... I tried stopping it and injecting hints about the formatter, and it stick for a minute before it goes crazy again. Or sometimes it rereads the file and just immediately fucks up the formatting.
I think when this shit happens, it probably uses like 3x more tokens.
For a Rust project, it recently stated analysing binaries in the target as directory a first instinct, instead of looking at the code...
The bigger problem for me is that the realtime voice modes lack tool use, so they can't look anything up or do anything. Model strength definitely also matters, but even dumb models can be helpful when they can look things up and try things out. And smart models that don't do those things kinda suck.
It's not often presented as "we should be spending more", but it's absolutely true that cybersecurity is predominated by a reflexive "more is better" bias. "Defense in depth" is at least as often invoked as an excuse to pile on more shit as it is with any real relation to the notion of boundaries analogous to those in the context from which the metaphor is drawn.
The security industry absolutely has a serious "more is better" syndrome.
Companies spend a ton of money on very sophisticated, powerful, invasive, and expensive software to protect themselves against ransomware.
But the best antidote to many forms of ransomware isn't security software at all— it's offline backups.
Like so much in cybersecurity, an analysis by spending categories like this feels like vendors and their marketing teams driving the discourse. Even if we accept that dollars provide the right lens through which to look at this problem, companies that spend more on making sure they have good backups and good restore procedures aren't going to show up as spending more on cybersecurity in this kind of analysis.
The company losing access to the data is only one half of the ransomware thread. The other half is unauthorized parties gaining access to the data. Backups only protect against the former.
Is that something anyone wants? It seems like being able to plug into other editors works well. What are the experiences people are trying to get but currently can't build because ACP sucks or whatever?
You can only do this if you have a very clear sense of what your code should be doing. In most codebases I've ever worked with, frankly, no one has any idea.
Red teaming as an approach always has value, but one important characteristic it has is that you can apply red teaming without demanding any changes at all to your code standards, or engineering culture (and maybe even your development processes).
Most companies are working with a horrific sprawl of code, much of it legacy with little ownership. Red teaming, like buying tools and pushing for high coverage, is an attractive strategy to business leaders because it doesn't require them to tackle the hardest problems (development priorities, expertise, institutional knowledge, talent, retention) that factor into application security.
Formal verification is unfortunately hard in the ways that companies who want to think of security as a simple resource allocation problem most likely can't really manage.
I would love to work on projects/with teams that see formal verification as part of their overall correctness and security strategy. And maybe doing things right can be cheaper in the long run, including in terms of token burn. But I'm not sure this strategy will be applicable all that generally; some teams will never get there.
reply