The thing about things like this is that they're shop jigs. You can buy a crosscut sled if you really want to, but most woodworkers just make their own.
It was a different situation 2 years ago, when there was significant cost to building your own harness (but then: you probably weren't doing AI vuln research 2 years ago). Today, I think your best bet is to look at something like this for ideas, and then just ask for your own, to fit your own work style, with your own interface, your own notion of target and effort specification, and your own alerting.
"Shop jigs" is a great way to put it. I think a lot of software has gone from being made for general use to extremely individualised use. Before the Age of AI, it took so much human effort to write something that solved your problem that you might often go the extra mile so that others could re-use it. Now, it takes almost no effort, so the software stays ungeneralised. Some of the incentive has changed, I think. Most of the time I no longer share the things I've been building[0] because, for one thing they simply couldn't possibly have any benefit for others, and if they need something like it, they can build exactly the thing they want instead of having to extend or modify my thing. Like a jig!
Unless it is very specific to a proprietary product, craftspeople take their jigs with them from job to job, building up a personal library over a career. As a software developer I've always had a well-tuned IDE and shell config in a safe place.
Something I think about a lot is what is the equivalent for the software builders of today using AI tools? how do make these harnesses exportable and portable? You might think employers would be against this; make it more costly to leave. But I actually think most will favor this because it makes people more productive more quickly. But we have to find ways to normalize it and show that there are no security leaks in the process (like might make it in to a set of personal steering prompts).
Just nerding out here, not rebutting, but when you say "craftspeople take their jigs with them from job to job" --- sort of. Sometimes. I think if you put a woodworker in a position where they obliged to build a new miter sled or assembly table, they might actually be thrilled. You make a tool, you use it for awhile, you build up a mental list of things you'd like to improve about it, that you'd do differently if you got a do-over; now you have an excuse to do it.
"Humor
When you finish a job â completing a task, answering a question, fixing a bug, shipping a feature â end your final message with one short funny line. A quip, a dad joke, a wry observation, a playful self-roast. One line. No emoji spam. Make it land, then shut up."
whats the purpose of this? just fun or does it cause some desired behaviour?
I've imported and adapted my personal agentic dev framework to my team relatively successfully (as I've kept it relatively harness independent), but it requires actually owning it, vibed or bloated or conceptually inconsistent stuff bite a lot when porting things over.
Depends. With all the web agencies I've made, the only code that belonged to customers was the actual website part. Any of the "jigs" that we made for our workflow was not part of that.
And contractually, any code I made was my employer's if I made it during office hours. Some even made a claim for code I would've written that during my employ that would be "competitive". Luckily, there was a massive difference in what I would do in my own time versus what they did.
I'm curious how does it work, you handover the tools you wrote, .bashrc/.zshrc, etc?
When I'm hired in a company (not contract), they wipe the harddrive when I leave (well, I also do it before I hand it over sometimes). So they don't get the tools (I take them with myself, it would be a waste to loose them)
i have been thinking about this from a different direction: how do we make these shared within a company in a way that increases the productivity floor of the team/department/company. Sure, they can still be extended/enhanced by individuals, but we donât need everyone configuring mcps, building institutional memory, etc.
for me, itâs not about the cost to leave, itâs about lowering the cost of onboarding and change.
I've said many times that I believe "using the computer will transparently involve having it write and run code for you" (and if you're not technical you won't even know it!). What you're saying goes in that direction as well.
I feel that it's often better for us to create purpose-built tools for our lives, and with every model release, the complexity of those tools grows.
These are really personal tools: they solve a problem that other people might have, but are very tied to your own specific way of working, and would be hard to explain or adapt to someone else. So: shop jigs.
I have about 10 custom scripts and programs that are like this -- I haven't felt like this since college! Back then I had all the time in the world to customize my setup...now I have agents!
In a way, I want to show this to all my friends, but whenever I mentally trace how that would go, I realize they wouldn't really understand a bunch of the quirks they have, because they are _my_ quirks. They're reasonably complex pieces of tech that solve my problems very well, which are themselves particular versions of broader problems, and which I (at least for now) have no interest in supporting.
It's so clear we're heading in this direction, and yet so many people still believe code will be for the elites. Maybe production-code...As for the rest, I think soon your mom and dad are going to have their computer running code it wrote to serve them. Security-wise it's scary, but it's exciting to think about!
Just as Python is batteries included language, we similarly need batteries included harnesses as well. This is what I don't like minimalism setups like Pi.
Iâve been looking for a way to articulate this shift, and your analogy nails it.
The value of libraries and infrastructure components in software engineering is eroding fast.
I am sure that in many organizations, teams responsible for this sort of work have less and less users coming to them.
Maybe for developer tooling, but on the consumer app side I think it's the opposite: MusicKit is much more valuable than Music.app now, because Claude can one-shot most reasonable things you could ask it to do. I think there's actually more value in ambitious libraries than there was 5 years ago, when any serious use of a library entailed a minimum 5-figure investment of time.
I had a pleasant experience one-shotting a dashboard on top of a library designed for building dashboards. Because everything was abstracted away, the chatbot had relatively few places it could get into the weeds. If I'd asked for the same thing from scratch, I think the result would have been more inconsistent, and would have had more bugs.
So I can definitely see the value in a library for constraining the chatbot to some well-worn paths.
> As a rough guideline, expect ~10K uncached input tokens/min and ~2K output tokens/min per agent. You can scale parallelism up to your account's ITPM limit (roughly 10 agents per 100K ITPM).
My guess would be hundreds of dollars with Opus and thousands of dollars with Mythos.
The definition of "bad" from a security PoV is rapidly expanding, in light of relatively new capabilities and increasingly cheap access to exploitable vulnerabilities.
fair point. another way of putting it might be to say that, for all extant software, much more of it is "bad" than we realized even a month or two ago -- and the cost to create and maintain "good"
software is increasing (even as the naive / surface-level / apparent cost is plummeting)
For now, maybe, yes? But the most important targets of this kind of work aren't AI outputs; it's legacy code, particularly (but not exclusively) old memory-unsafe code. In those situations the figure of merit isn't the token cost of recreating the target code; it's the cost of finding the same bugs with humans or preexisting tools.
There's a parallel between looking for bugs and mining. As models get smarter, they'll find "deeper bugs".
I expect at some point formal verification will become more economical than red teaming. Writing it correctly is more expensive, but it may be cheaper than trying to secure incorrect software.
(Or rather, as hacking incorrect software becomes vastly cheaper, the amount of software worth writing properly will increase.)
I've been thinking, by Dijkstra's standards we have already been vibe coding for almost a century :)
Given the slop that's made its way to Github we can see that this is a great profit model. Ship slop and then "fix" slop. What an efficient use of our planet!
It's weird because why can't they train the AI to simply output secure code?
The basic security flaws with regards to input validation and overflows should never ever be output by an AI. For "security flaws due to bad design" I'll cut them slack until AGI is achieved.
> It's weird because why can't they train the AI to simply output secure code?
The most interesting security bugs have causes that are spread across large codebases, or networks of dependencies.
Training the AI to "output secure code" won't work if it doesn't also have access to the source code of every dependency that it's using... and even then, given current model speeds and prices most developers won't want to wait for an hour on every edit they make while the LLM reasons through all of the dependencies.
What's destabilizing the industry right now isn't vulnerabilities AI introduces into new code; it's a flood of sev:hi vulnerabilities in existing code, not introduced by AI but discovered by it.
> What's destabilizing the industry right now isn't vulnerabilities AI introduces into new code; it's a flood of sev:hi vulnerabilities in existing code, not introduced by AI but discovered by it.
Vulnerability discovery has essentially moved to a "proof of work" computation model with AI that has some similarities to crypto like BTC or ethereum 1.0. I don't see any reason a well funded adversary couldn't use this same process on open-source code to develop exploits. I'm sure AI would be happy to try and create exploits from the results rather than fixes.
This sort of proof of work has a notable difference from crypto in the asymmetric nature of what each side is targeting. In crypto, each miner was attempting to find a solution to the same problem and they would all move on to a new one once a solution is found. However with AI vulnerability scanning, the non-deterministic nature means an adversary is likely to find different vulnerabilities. Even if it doesn't, the adversaries have a different post-discovery workflow (i.e. probably less compute intensive aka cheaper due to only needing one viable exploit to win) than the software maintainers do.
Considering it's possible both the adversary and their target could both do all this while running Claude puts Anthropic in a real "Merchant of Death" position.
Even before that everybody was getting drowned in shitty reports from automated tools.
The goal of AI-generated code should not be that one needs a AI-based security review tool on top of it, but that the AI-generated code in itself is reasonably secure.
I think these audit tools can look beyond just security and can look for compliance audits as well. The ability to audit real targets in staging environments makes it easy to identify issues.
I think that the cost of Opus is already prohibitively expensive, so not sure how that would compare to Mythos.
Check this calculator- it shows that a company with 100 devs can hit ~2.5M cost on tokens annually, which is wild!
https://ai-cost-calculator.arnica.io
A 100 dev team is going to cost on the order of $25m a year (keep in mind cost is not just their salary, but also the HR/Management org to support a team of that size, benefits, office space, hardware/software). So if you think you get a 10% boost in productivity out of Opus, its not prohibitive at all.
Claude workflows in ultra code mode works in a very similar fashion and it consumes a moderate amount of the session usage limit, depending on the complexity of the task. With the API it would probably get expensive quickly though
If you compare to their managed service, that estimate is likely 1/10th expectation, depending on codebase.
But even this larger number, in turn, can be about 1/10th the cost of a formal engagement to discover the type of findings it seems to be going for: things that do not show up from PR reviews or even /security-review without the pre-work steps in the open-source framework guided by an expert. That's not counting the time and delay to figure out how to do that engagement.
Bluntly: if it matters, while this is a month's vibing budget for a single scan, it is also "pennies on the dollar" dirt cheap.
At the same time, its findings still need an expert. Its suggestions may be helpful, they may be actively harmful, depends on the prework quality.
Recommendation to IT department heads: spend a couple grand on this, use the scare page to rustle up the budget to build a relationship with a red team that can find, triage, help remediate if needed, and train your in-house team to be "security minded".
Just another example of an overextension of technology in a scenario where applying a proper harness would suffice.
Reminiscent of the early days of tax automation where importing a W2 cost hundreds of dollars until people realized typing in 6 boxes worth of data was easy and paying the automation fee ate up their entire tax return.
I mean, you don't need to run it all the time, right? You do it once over your entire existing codebase to start and then once over the diff in your CI/CD pipeline when you make a new change. I'm sure it's not literally that simple but I doubt these need to churn 24/7/365 either.
In the Mythos blogpost they revealed to run the model like a 1000 times on the same code-base maybe with slightly different prompt or temperature. That suggests it will just be pay to win. If the 'attacker' spends more money/tokens than the 'defender' you will eventually be outclassed.
It's even worse, it's loot box style. Not pay to win, but pay to have the chance to win. The result will always be non-deterministic, so for some cases it can give you what you're looking for from the first time, or it can take 1000 tries.
I agree the cost curve has shifted. But if we take the Mozilla team's Mythos report as a broad baseline, you need to hire something like 10 security engineers to equal the Mythos productivity. Put another way, everyone's under hiring security by a LOT right now, we just have been lucky enough to see similar under hiring on hackers.
Anthropic realized security and safety are their main value prop compared to the competition. Either mythos or anything else since seem purpose built to streamline the messaging. Itâs good, am not complaining, but i wonder how much this is intended to showcase what Claude can do over using it as is
> Maybe next they can sell something to find the bugs in the security scanner ?
So, tokens are used to produce sloppy code, and then this thing uses more tokens to fix vulnerabilities in the slop ? Whats not to like in this business model ?
Similar to microsoft's. Create an OS which is vulnerable, and then enable business models for anti-virus software. Everyone wins.
More seriously, linters are turned off in ci because the amount of time spent chasing false-positives is prohibitive.
They pretty much saying the efficacy of the tool can be tested by anyone to determine if it's worth purchasing the more polished and up-to-date commercial offering.
Our experience has been that without a good harness you don't really get much out of codex/claude. And you really need to spend time and energy figuring out why coding agents can't find bugs like you can.
Every week I see bugs (as an auditor) that our own harness (https://zkao.io/) can't find, and we have to figure out pretty interesting techniques in order to make the tool find them. Mind you I'm talking mostly about cryptographic vulnerabilities, not just webapp bugs. So IMO it's going to make a lot of sense for companies to have both their own harness (as
tptacek is talking about) and pay for services that focus on making a good harness from experience (and audit firms are going to be the best at doing this, as they see a lot of bugs and can spend time "teaching" their harness about these bugs)
On the other hand, you have to find equally as good techniques to triage, because otherwise you just have some machinery that I call "vibe auditing" that just produces enough false positives to tire all the developers (who are already overwhelmed with crappy AI submissions in bugbounties and other AI tool that review all of their PRs).
At the end of the day, when your harness doesn't return any bug, you're left wondering "does it mean there's no bugs?" We're basically back in this reputation game, where you want to use the best tool, or the best team (that knows what the best tools are), and need to figure out which one is.
To be sure, security is an amazing AI/LLM use case. A huge swath of the work is pattern matching known security issues against stuff that's very precise to analyze -- programming language text.
Something that stands out is that for the strongest use cases, AI companies will prefer to sell the technique as a service rather than its raw output. For use cases where the output is less valuable, tokens are sold. If AI tokens were so magical in creating new value in developing software applications generally, they wouldn't be selling tokens directly. They'd hoard the tokens are use them to dominate SaaS software in any industry they want.
The same way as someone selling an expensive course in the stock market is signaling that they have more to gain by selling the course rather than taking their knowledge and making money in the stock market directly.
> The same way as someone selling an expensive course in the stock market is signaling that they have more to gain by selling the course rather than
Or they want to diversify
> If AI tokens were so magical in creating new value in developing software applications generally, they wouldn't be selling tokens directly.
That requires to build and sell a whole product they have little experience with, competing with their own customers. Not a great place for an AI vendor still trying to establish itself. Itâs a lot of distraction, when you already have a lot to deal with the existing business. And strategically not too valuable
> They'd hoard the tokens are use them to dominate SaaS software in any industry they want.
I don't understand this argument. I've ran and sold a semi-successful SaaS. The exhausting and frustrating parts are all the things an LLM cannot help you with. Coding the product is not the bottleneck or what grants you success.
> Coding the product is not the bottleneck or what grants you success.
Agree, and I think that's the core of my point.
Not that it's irrational or doesn't make sense to sell tokens for purposes of software dev, but that if tokens were a true game changer for success in software dev, they wouldn't be leading with token sales, the same way they're not leading with token sales for security stuff -- it's more like "Contact Sales".
> If AI tokens were so magical in creating new value in developing software applications generally, they wouldn't be selling tokens directly. They'd hoard the tokens are use them to dominate SaaS software in any industry they want.
This doesn't follow at all. Anthropic's revenue is growing 10x year over year selling tokens. Their tokens can be super magical, let them enter established industries and displace incumbents, and get 100% annual growth in those industries, and they would still be better off prioritizing selling tokens, because it's a great business.
What your argument shows is that there are limits. Their tokens are not quite powerful enough to make infinite money instantly in every area of software. Admittedly, that does seem true.
what is doing the steering is the weights of the words that came before in context. there is no agent or agency. if your problems need median effort and are well represented in shape in the corpus then agents may work well. true inovation is impossible without careful prompting, wherein the agent becomes an associative engine (kind of a smart search engine) and you the human become the manager of the process.
Maybe, but an alternative argument that building an ecosystem is more valuable in the long run.
We started out with many companies forbidding their employees to use remote LLMs on their source code because of security concerns. Now many companies are starting to believe that they must analyze their all their source code with remote LLMs because of security concerns. When trusting Anthropic becomes normalized, that means they can sell more services that require access to the source code.
Surprised we havent gotten an integrated "MetaSploit" AI update where it calls and messages a ton of people in a company and once it starts to find someone possibly vulnerable lets a human red teamer take over or guide it more by hand.
> If AI tokens were so magical in creating new value in developing software applications generally, they wouldn't be selling tokens directly.
If hardware were so magical in creating new value generally, TSMC would be designing the chips instead of selling fabrication as a service.
That is what US chip companies used to do, by the way (back when there was silicon in Silicon Valley, before they got their lunch eaten by Taiwan). If TSMC had to design all of the chips they fabricate now, they would be doing a lot less business. Conversely, if any other company that wanted to design a chip had to build their own cutting-edge fab first, NVIDIA would not exist.
> They can only do that if they're a monopoly, which they're not
Why do you say that? I reckon lots and lots of companies sell software that arenât monopolies. Having competition, even stiff competition, isnât anathema to running a business.
Just to clarify, Iâm not the person you initially replied to.
> "They wouldn't be selling tokens directly ... They'd hoard them" But they can't do that because they aren't monopolies.
Hoarding themâ not selling any of them, but instead using them internally and selling the products created by them â doesnât at all seem like it would require a monopoly.
It will always be easier to find a single hole than it will be to seal every one. The hackers have all the same tools, so this is an arms race that cannot be won.
It seems clear that LLMs significantly change threat model math, but this observation alone does not explain how or why; the asymmetry that youâre describing is a property of pre-LLM software as well.
Same ratio of imbalance, just with matching multipliers distributed to each side, and everybody is probably worse off because of it: I cite post-LLM-ATS hiring/job hunting.
I have been struggling with false positives and using Claude + MCP as a poor manâs audit tool. As of last few days found better result with nvidia hosted models.
Ran this last night and it correctly identified a sql injection that could allow cross tenant data access via snowflake. It burnt A LOT of tokens to get there.
Like others I suspect this is exactly what they are going to paywall with product features going forward.
Looking forward to trying this tomorrow (it's late here). Has anyone run it on a real codebase yet? Curious about setup friction, cost, and signal/noise.
The thing about things like this is that they're shop jigs. You can buy a crosscut sled if you really want to, but most woodworkers just make their own.
It was a different situation 2 years ago, when there was significant cost to building your own harness (but then: you probably weren't doing AI vuln research 2 years ago). Today, I think your best bet is to look at something like this for ideas, and then just ask for your own, to fit your own work style, with your own interface, your own notion of target and effort specification, and your own alerting.
"Shop jigs" is a great way to put it. I think a lot of software has gone from being made for general use to extremely individualised use. Before the Age of AI, it took so much human effort to write something that solved your problem that you might often go the extra mile so that others could re-use it. Now, it takes almost no effort, so the software stays ungeneralised. Some of the incentive has changed, I think. Most of the time I no longer share the things I've been building[0] because, for one thing they simply couldn't possibly have any benefit for others, and if they need something like it, they can build exactly the thing they want instead of having to extend or modify my thing. Like a jig!
0: https://redfloatplane.lol/blog/17-why-share/ (and related posts, I guess)
Unless it is very specific to a proprietary product, craftspeople take their jigs with them from job to job, building up a personal library over a career. As a software developer I've always had a well-tuned IDE and shell config in a safe place.
Something I think about a lot is what is the equivalent for the software builders of today using AI tools? how do make these harnesses exportable and portable? You might think employers would be against this; make it more costly to leave. But I actually think most will favor this because it makes people more productive more quickly. But we have to find ways to normalize it and show that there are no security leaks in the process (like might make it in to a set of personal steering prompts).
Just nerding out here, not rebutting, but when you say "craftspeople take their jigs with them from job to job" --- sort of. Sometimes. I think if you put a woodworker in a position where they obliged to build a new miter sled or assembly table, they might actually be thrilled. You make a tool, you use it for awhile, you build up a mental list of things you'd like to improve about it, that you'd do differently if you got a do-over; now you have an excuse to do it.
This, for like 37 things in my workshop right now.
Using something like pi helps. I've made my own dotfiles for skills/extensions I like and can install them just like my normal dotfiles
https://github.com/anishthite/agent-dotfiles
"Humor When you finish a job â completing a task, answering a question, fixing a bug, shipping a feature â end your final message with one short funny line. A quip, a dad joke, a wry observation, a playful self-roast. One line. No emoji spam. Make it land, then shut up."
whats the purpose of this? just fun or does it cause some desired behaviour?
> does it cause some desired behaviour?
Fun is desirable.
I've imported and adapted my personal agentic dev framework to my team relatively successfully (as I've kept it relatively harness independent), but it requires actually owning it, vibed or bloated or conceptually inconsistent stuff bite a lot when porting things over.
> craftspeople take their jigs with them from job to job
Except for software gigs the software typically belongs to the customer so you'd need to rewrite it every time...
Depends. With all the web agencies I've made, the only code that belonged to customers was the actual website part. Any of the "jigs" that we made for our workflow was not part of that.
And contractually, any code I made was my employer's if I made it during office hours. Some even made a claim for code I would've written that during my employ that would be "competitive". Luckily, there was a massive difference in what I would do in my own time versus what they did.
Depends. If you are a contractor, like most craftspeople, your tools are your own.
My contracts always state I own tools created or byproducts of the work that don't end up in the work.
Only if you are self employed, otherwise it belongs to the agency.
Again: it depends. It is all about how the contract is written.
I never seen any other kind of contract, on my 50ys.
I'm curious how does it work, you handover the tools you wrote, .bashrc/.zshrc, etc?
When I'm hired in a company (not contract), they wipe the harddrive when I leave (well, I also do it before I hand it over sometimes). So they don't get the tools (I take them with myself, it would be a waste to loose them)
You're definitely right for most agencies; most will let you use it in a portfolio or something, but not necessarily retain the rights to the work.
Some agencies do, however; it's dependent on the contract specifics.
i have been thinking about this from a different direction: how do we make these shared within a company in a way that increases the productivity floor of the team/department/company. Sure, they can still be extended/enhanced by individuals, but we donât need everyone configuring mcps, building institutional memory, etc.
for me, itâs not about the cost to leave, itâs about lowering the cost of onboarding and change.
No effort? You are really drinking the AI marketing soup with that one.
"It takes less effort for some parts of the software development life cycle" would be more correct.
Thatâs an interesting way to say âcode quality in the age of ai has gone out the windowâ
Are you suggesting that performing a specific task without unnecessary abstractions is indicative of poor quality?
This is exactly it.
I've said many times that I believe "using the computer will transparently involve having it write and run code for you" (and if you're not technical you won't even know it!). What you're saying goes in that direction as well.
I feel that it's often better for us to create purpose-built tools for our lives, and with every model release, the complexity of those tools grows.
These are really personal tools: they solve a problem that other people might have, but are very tied to your own specific way of working, and would be hard to explain or adapt to someone else. So: shop jigs.
I have about 10 custom scripts and programs that are like this -- I haven't felt like this since college! Back then I had all the time in the world to customize my setup...now I have agents!
In a way, I want to show this to all my friends, but whenever I mentally trace how that would go, I realize they wouldn't really understand a bunch of the quirks they have, because they are _my_ quirks. They're reasonably complex pieces of tech that solve my problems very well, which are themselves particular versions of broader problems, and which I (at least for now) have no interest in supporting.
It's so clear we're heading in this direction, and yet so many people still believe code will be for the elites. Maybe production-code...As for the rest, I think soon your mom and dad are going to have their computer running code it wrote to serve them. Security-wise it's scary, but it's exciting to think about!
Sure itâs possible for anyone to build a harness if they had the inclination, but most people donât have the inclination to do that.
And even if you did⌠I spent months refining AI workflows that were just obsoleted by ultracode.
Just as Python is batteries included language, we similarly need batteries included harnesses as well. This is what I don't like minimalism setups like Pi.
Iâve been looking for a way to articulate this shift, and your analogy nails it. The value of libraries and infrastructure components in software engineering is eroding fast.
I am sure that in many organizations, teams responsible for this sort of work have less and less users coming to them.
Maybe for developer tooling, but on the consumer app side I think it's the opposite: MusicKit is much more valuable than Music.app now, because Claude can one-shot most reasonable things you could ask it to do. I think there's actually more value in ambitious libraries than there was 5 years ago, when any serious use of a library entailed a minimum 5-figure investment of time.
I had a pleasant experience one-shotting a dashboard on top of a library designed for building dashboards. Because everything was abstracted away, the chatbot had relatively few places it could get into the weeds. If I'd asked for the same thing from scratch, I think the result would have been more inconsistent, and would have had more bugs.
So I can definitely see the value in a library for constraining the chatbot to some well-worn paths.
100% concur and if you dig into any of these tools they are all frameworks and wrappers with prompt injections
In general this is the way I see open source going.
We won't reuse open source libraries as libraries we import, but as design inspiration for the bespoke tools we make.
It's too cheap to make your own stuff and too expensive to be stuck with someone else primitives.
But grounding AI Coding in existing tools is incredibly powerful.
I agree with this wholeheartedly.
I wonder how much this thing costs to run.
https://github.com/anthropics/defending-code-reference-harne... says:
> As a rough guideline, expect ~10K uncached input tokens/min and ~2K output tokens/min per agent. You can scale parallelism up to your account's ITPM limit (roughly 10 agents per 100K ITPM).
My guess would be hundreds of dollars with Opus and thousands of dollars with Mythos.
It's becoming apparent that it requires more tokens to secure code than it does to write it
May even be an order of magnitude more
In all seriousness, wasnât that always the case? Writing bad code is relatively cheap.
Ensuring code isnât bad is the expensive part.
Sort of?
The definition of "bad" from a security PoV is rapidly expanding, in light of relatively new capabilities and increasingly cheap access to exploitable vulnerabilities.
I don't think the definition of "bad" is expanding. Rather the ability to detect and exploit "bad" is.
fair point. another way of putting it might be to say that, for all extant software, much more of it is "bad" than we realized even a month or two ago -- and the cost to create and maintain "good" software is increasing (even as the naive / surface-level / apparent cost is plummeting)
Same thing happened with the growth of the internet. There was a time when there was basically no consideration of buffer overflow.
For now, maybe, yes? But the most important targets of this kind of work aren't AI outputs; it's legacy code, particularly (but not exclusively) old memory-unsafe code. In those situations the figure of merit isn't the token cost of recreating the target code; it's the cost of finding the same bugs with humans or preexisting tools.
Those costs can be extremely high.
Any newly produced AI code is immediately legacy and trash at the same time.
There's a parallel between looking for bugs and mining. As models get smarter, they'll find "deeper bugs".
I expect at some point formal verification will become more economical than red teaming. Writing it correctly is more expensive, but it may be cheaper than trying to secure incorrect software.
(Or rather, as hacking incorrect software becomes vastly cheaper, the amount of software worth writing properly will increase.)
I've been thinking, by Dijkstra's standards we have already been vibe coding for almost a century :)
Not if the original code is secure...
Are AI firms going to charge us to write code, and then charge us even more to secure it?!
Yes, obviously. Infosec has always been plagued by this. How many services make you pay for SSO?
Given the slop that's made its way to Github we can see that this is a great profit model. Ship slop and then "fix" slop. What an efficient use of our planet!
It's weird because why can't they train the AI to simply output secure code?
The basic security flaws with regards to input validation and overflows should never ever be output by an AI. For "security flaws due to bad design" I'll cut them slack until AGI is achieved.
> It's weird because why can't they train the AI to simply output secure code?
The most interesting security bugs have causes that are spread across large codebases, or networks of dependencies.
Training the AI to "output secure code" won't work if it doesn't also have access to the source code of every dependency that it's using... and even then, given current model speeds and prices most developers won't want to wait for an hour on every edit they make while the LLM reasons through all of the dependencies.
What's destabilizing the industry right now isn't vulnerabilities AI introduces into new code; it's a flood of sev:hi vulnerabilities in existing code, not introduced by AI but discovered by it.
Agreed -- and, compounding the challenge, the flood of _reported_ high-sev CVEs is itself a kind of DDoS attack on maintainers.
> What's destabilizing the industry right now isn't vulnerabilities AI introduces into new code; it's a flood of sev:hi vulnerabilities in existing code, not introduced by AI but discovered by it.
Vulnerability discovery has essentially moved to a "proof of work" computation model with AI that has some similarities to crypto like BTC or ethereum 1.0. I don't see any reason a well funded adversary couldn't use this same process on open-source code to develop exploits. I'm sure AI would be happy to try and create exploits from the results rather than fixes.
This sort of proof of work has a notable difference from crypto in the asymmetric nature of what each side is targeting. In crypto, each miner was attempting to find a solution to the same problem and they would all move on to a new one once a solution is found. However with AI vulnerability scanning, the non-deterministic nature means an adversary is likely to find different vulnerabilities. Even if it doesn't, the adversaries have a different post-discovery workflow (i.e. probably less compute intensive aka cheaper due to only needing one viable exploit to win) than the software maintainers do.
Considering it's possible both the adversary and their target could both do all this while running Claude puts Anthropic in a real "Merchant of Death" position.
This doesn't make sense. Claude isn't creating the vulnerabilities. They've been here the whole time. You just get to know about them now.
Even before that everybody was getting drowned in shitty reports from automated tools.
The goal of AI-generated code should not be that one needs a AI-based security review tool on top of it, but that the AI-generated code in itself is reasonably secure.
Hello Sam
I think these audit tools can look beyond just security and can look for compliance audits as well. The ability to audit real targets in staging environments makes it easy to identify issues.
I think that the cost of Opus is already prohibitively expensive, so not sure how that would compare to Mythos. Check this calculator- it shows that a company with 100 devs can hit ~2.5M cost on tokens annually, which is wild! https://ai-cost-calculator.arnica.io
A 100 dev team is going to cost on the order of $25m a year (keep in mind cost is not just their salary, but also the HR/Management org to support a team of that size, benefits, office space, hardware/software). So if you think you get a 10% boost in productivity out of Opus, its not prohibitive at all.
It's wild, but how many FLOPs in computation is occurring in those 2.5M in tokens doing? Might not sound quite as wild using that metric.
Claude workflows in ultra code mode works in a very similar fashion and it consumes a moderate amount of the session usage limit, depending on the complexity of the task. With the API it would probably get expensive quickly though
We actually created a calculator to estimate scanning costs (including whether you do this continuously or not) https://ai-cost-calculator.arnica.io
It's an estimate, so it might be wrong, but it gives the ballpark based on our experience. Happy to hear everyone's feedback.
If you compare to their managed service, that estimate is likely 1/10th expectation, depending on codebase.
But even this larger number, in turn, can be about 1/10th the cost of a formal engagement to discover the type of findings it seems to be going for: things that do not show up from PR reviews or even /security-review without the pre-work steps in the open-source framework guided by an expert. That's not counting the time and delay to figure out how to do that engagement.
Bluntly: if it matters, while this is a month's vibing budget for a single scan, it is also "pennies on the dollar" dirt cheap.
At the same time, its findings still need an expert. Its suggestions may be helpful, they may be actively harmful, depends on the prework quality.
Recommendation to IT department heads: spend a couple grand on this, use the scare page to rustle up the budget to build a relationship with a red team that can find, triage, help remediate if needed, and train your in-house team to be "security minded".
Just another example of an overextension of technology in a scenario where applying a proper harness would suffice.
Reminiscent of the early days of tax automation where importing a W2 cost hundreds of dollars until people realized typing in 6 boxes worth of data was easy and paying the automation fee ate up their entire tax return.
I mean, you don't need to run it all the time, right? You do it once over your entire existing codebase to start and then once over the diff in your CI/CD pipeline when you make a new change. I'm sure it's not literally that simple but I doubt these need to churn 24/7/365 either.
In the Mythos blogpost they revealed to run the model like a 1000 times on the same code-base maybe with slightly different prompt or temperature. That suggests it will just be pay to win. If the 'attacker' spends more money/tokens than the 'defender' you will eventually be outclassed.
It's even worse, it's loot box style. Not pay to win, but pay to have the chance to win. The result will always be non-deterministic, so for some cases it can give you what you're looking for from the first time, or it can take 1000 tries.
Itâs never not been âloot box styleâ. None of your past hired security audits were guaranteed to catch all issues?
You are supposed to run it on full codebase before any single PR gets merge.
Companies don't make production pushes yearly. For many, it's two week sprints..and that's one project.
This doesn't make any sense cost-wise. It would be cheaper to just hire a security engineer.
I agree the cost curve has shifted. But if we take the Mozilla team's Mythos report as a broad baseline, you need to hire something like 10 security engineers to equal the Mythos productivity. Put another way, everyone's under hiring security by a LOT right now, we just have been lucky enough to see similar under hiring on hackers.
Anthropic realized security and safety are their main value prop compared to the competition. Either mythos or anything else since seem purpose built to streamline the messaging. Itâs good, am not complaining, but i wonder how much this is intended to showcase what Claude can do over using it as is
They seem to be using this to advertise their "Claude Security" product which promises to find vulnerabilities in your software.
This makes for a somewhat amusing set of product offerings given that according to Dario 90% of all software is being AI generated.
Maybe next they can sell something to find the bugs in the security scanner ?
> Maybe next they can sell something to find the bugs in the security scanner ?
So, tokens are used to produce sloppy code, and then this thing uses more tokens to fix vulnerabilities in the slop ? Whats not to like in this business model ? Similar to microsoft's. Create an OS which is vulnerable, and then enable business models for anti-virus software. Everyone wins.
More seriously, linters are turned off in ci because the amount of time spent chasing false-positives is prohibitive.
>This repo is not maintained and is not accepting contributions.
Hm :)
Why isn't Claude maintaining it?
They must have solved coding that well.
They pretty much saying the efficacy of the tool can be tested by anyone to determine if it's worth purchasing the more polished and up-to-date commercial offering.
This one is and should be adapted to every frozen model ASAP.
https://github.com/space-bacon/SRT
Significantly improve every frozen model overnight. LFG.
Our experience has been that without a good harness you don't really get much out of codex/claude. And you really need to spend time and energy figuring out why coding agents can't find bugs like you can.
Every week I see bugs (as an auditor) that our own harness (https://zkao.io/) can't find, and we have to figure out pretty interesting techniques in order to make the tool find them. Mind you I'm talking mostly about cryptographic vulnerabilities, not just webapp bugs. So IMO it's going to make a lot of sense for companies to have both their own harness (as tptacek is talking about) and pay for services that focus on making a good harness from experience (and audit firms are going to be the best at doing this, as they see a lot of bugs and can spend time "teaching" their harness about these bugs)
On the other hand, you have to find equally as good techniques to triage, because otherwise you just have some machinery that I call "vibe auditing" that just produces enough false positives to tire all the developers (who are already overwhelmed with crappy AI submissions in bugbounties and other AI tool that review all of their PRs).
At the end of the day, when your harness doesn't return any bug, you're left wondering "does it mean there's no bugs?" We're basically back in this reputation game, where you want to use the best tool, or the best team (that knows what the best tools are), and need to figure out which one is.
To be sure, security is an amazing AI/LLM use case. A huge swath of the work is pattern matching known security issues against stuff that's very precise to analyze -- programming language text.
Something that stands out is that for the strongest use cases, AI companies will prefer to sell the technique as a service rather than its raw output. For use cases where the output is less valuable, tokens are sold. If AI tokens were so magical in creating new value in developing software applications generally, they wouldn't be selling tokens directly. They'd hoard the tokens are use them to dominate SaaS software in any industry they want.
The same way as someone selling an expensive course in the stock market is signaling that they have more to gain by selling the course rather than taking their knowledge and making money in the stock market directly.
> The same way as someone selling an expensive course in the stock market is signaling that they have more to gain by selling the course rather than
Or they want to diversify
> If AI tokens were so magical in creating new value in developing software applications generally, they wouldn't be selling tokens directly.
That requires to build and sell a whole product they have little experience with, competing with their own customers. Not a great place for an AI vendor still trying to establish itself. Itâs a lot of distraction, when you already have a lot to deal with the existing business. And strategically not too valuable
What market is hotter than AI models? Do you think their energy would be better making games or image editing software?
No, Iâm saying the opposite
> They'd hoard the tokens are use them to dominate SaaS software in any industry they want.
I don't understand this argument. I've ran and sold a semi-successful SaaS. The exhausting and frustrating parts are all the things an LLM cannot help you with. Coding the product is not the bottleneck or what grants you success.
Good point but I do think LLM helps with those frustrating parts while not being able to outright solve them.
> Coding the product is not the bottleneck or what grants you success.
Agree, and I think that's the core of my point.
Not that it's irrational or doesn't make sense to sell tokens for purposes of software dev, but that if tokens were a true game changer for success in software dev, they wouldn't be leading with token sales, the same way they're not leading with token sales for security stuff -- it's more like "Contact Sales".
> If AI tokens were so magical in creating new value in developing software applications generally, they wouldn't be selling tokens directly. They'd hoard the tokens are use them to dominate SaaS software in any industry they want.
This doesn't follow at all. Anthropic's revenue is growing 10x year over year selling tokens. Their tokens can be super magical, let them enter established industries and displace incumbents, and get 100% annual growth in those industries, and they would still be better off prioritizing selling tokens, because it's a great business.
What your argument shows is that there are limits. Their tokens are not quite powerful enough to make infinite money instantly in every area of software. Admittedly, that does seem true.
kind of funny tokens don't prompt and steer themselves. it almost as if the value still lies with the human holding the tool.
They kinda do though, that's sort of how agents work. At least that's how it's always felt to me.
what is doing the steering is the weights of the words that came before in context. there is no agent or agency. if your problems need median effort and are well represented in shape in the corpus then agents may work well. true inovation is impossible without careful prompting, wherein the agent becomes an associative engine (kind of a smart search engine) and you the human become the manager of the process.
Maybe, but an alternative argument that building an ecosystem is more valuable in the long run.
We started out with many companies forbidding their employees to use remote LLMs on their source code because of security concerns. Now many companies are starting to believe that they must analyze their all their source code with remote LLMs because of security concerns. When trusting Anthropic becomes normalized, that means they can sell more services that require access to the source code.
Surprised we havent gotten an integrated "MetaSploit" AI update where it calls and messages a ton of people in a company and once it starts to find someone possibly vulnerable lets a human red teamer take over or guide it more by hand.
Isnât this analogous to saying if farming equipment is so productive why doesnât John Deer hoard all the tractors and do the farming themselves?
> If AI tokens were so magical in creating new value in developing software applications generally, they wouldn't be selling tokens directly.
If hardware were so magical in creating new value generally, TSMC would be designing the chips instead of selling fabrication as a service.
That is what US chip companies used to do, by the way (back when there was silicon in Silicon Valley, before they got their lunch eaten by Taiwan). If TSMC had to design all of the chips they fabricate now, they would be doing a lot less business. Conversely, if any other company that wanted to design a chip had to build their own cutting-edge fab first, NVIDIA would not exist.
They can only do that if they're a monopoly, which they're not
> They can only do that if they're a monopoly, which they're not
Why do you say that? I reckon lots and lots of companies sell software that arenât monopolies. Having competition, even stiff competition, isnât anathema to running a business.
You said "They wouldn't be selling tokens directly ... They'd hoard them"
But they can't do that because they aren't monopolies.
> You said
Just to clarify, Iâm not the person you initially replied to.
> "They wouldn't be selling tokens directly ... They'd hoard them" But they can't do that because they aren't monopolies.
Hoarding themâ not selling any of them, but instead using them internally and selling the products created by them â doesnât at all seem like it would require a monopoly.
Sligthly off topic: it seems that someone is in a dead/flag rampage killing all good links to Github in this post, why?
It will always be easier to find a single hole than it will be to seal every one. The hackers have all the same tools, so this is an arms race that cannot be won.
It seems clear that LLMs significantly change threat model math, but this observation alone does not explain how or why; the asymmetry that youâre describing is a property of pre-LLM software as well.
Same ratio of imbalance, just with matching multipliers distributed to each side, and everybody is probably worse off because of it: I cite post-LLM-ATS hiring/job hunting.
Defenders have context that attackers don't though.
Very interesting.
I have working on and using a similar tool for a while now :
https://github.com/bobinson/vulture
I have been struggling with false positives and using Claude + MCP as a poor manâs audit tool. As of last few days found better result with nvidia hosted models.
Ran this last night and it correctly identified a sql injection that could allow cross tenant data access via snowflake. It burnt A LOT of tokens to get there.
Like others I suspect this is exactly what they are going to paywall with product features going forward.
Itâs clear that Anthropic is building harnesses for specific use cases now and turns them into products.
This is the equivalent of Claude Design but for security.
Different harness, different packaging and obviously different distribution because the persona is different.
Itâs funny because from all the posts Iâve read from companies reporting on Mythos, everyone is building their own harness for it.
Cisco even published a specification for one.
But Anthropic is the one who has figured out how to package and distribute this. Great GTM!
This post is misleading and so is the GitHub org. Anthropics vs Anthropic.
That is their actual account. We have this discussion every time they post something sadly
Oh, bummer. That is really confusing.
This isn't as useful as it sounds, unless we know that Claude efficiently spends tokens using this harness
Let's see how better it is in comparison to ZAP and Burp. I will test on https://github.com/SasanLabs/VulnerableApp which i built under SasanLabs
"This repo is not maintained and is not accepting contributions."
Nice
https://github.com/Mainframework/Anthropic-Cybersecurity-Ski...
Be aware: the .py/s will not pass the antivirus but basically they do the job.
This is a good addition tool for people are in the security Practitioners. To save time for hunting vulnerability.
I wonder how this sort of product is going over at Coverity and others like it. Proper SAST vendors I mean. Is it an existential threat?
If I had to guess, they'l eventually just add it into their own product and hike the prices up to cover tokens lol.
I don't trust it and I cannot test it (gated by what ng cartel web engines).
Anthropics vs Anthropic.
That repo is Anthropics.
This post title should clarify that it is not Anthropic (no "s").
Anthropics is Anthropic's user name on GitHub
Anthropic, no s, is owned by some Australian guy.
I wonder if he is using Anthropic's claude code to work on his Anthropic Github account.
TIL, thank you
`anthropics` is Anthropic's GitHub username.
The last time this Anthropic GitHub got posted I made a similar comment.
Is Anthropic still majority French-owned? It would explain a lot about their entire approach to the wider ecosystem.
Seems like you are confusing crack and tar as a healthy breakfast.
If anyone wonders how much it can cost to run scans like this on your entire codebase with SOTA models: https://ai-cost-calculator.arnica.io
tl;dr - not that it's surprising, but it's not cheap, especially if you want to do this continuously.
Interesting it's in python!
Open source crap to connect to an LLM blob.
> Anthropic engineers on average ship 8x as much code per quarter
Are they making 8x more features or the same amount just with more code?
Going by the issues on their repos, it's 2x features and 6x regressions of bugs that were "already fixed".
I still find it so weird that they haven't bought out whoever controls the `anthropic` github username.
Or hacked them...
Looking forward to trying this tomorrow (it's late here). Has anyone run it on a real codebase yet? Curious about setup friction, cost, and signal/noise.
'open source' crap to connect to their LLM blob.