VISA open sourced an expense-to-run harness they developed under glasswing, and I used that as the basis of a skill that I've found to be pretty effective with Claude Code: https://github.com/atgreen/secscan-skill
So, you have these models that you put things into (like text), and get things out of.
For many models, you can include a "tool definition" in that text input. Remember this definition is just JSON :)
Let's say you send a tool definition to the model, plus a text question.
The model responds with a request for you to call the tool. It's also JSON.
What shall you, the human, do with it? :) That's what the harness is for: In this case, it interprets that JSON request and returns a JSON response that the model can understand.
In general, a harness is anything that manipulates the model input and output for your benefit: It may recall memories and place them into your context automatically, handle tool requests, prune long conversations, injecting parts of old conversations, and so on.
The harness is the tool you use to communicate with the model.
It can be as basic as a simple conversation tool (like ChatGPT back in the day), or more advanced like GitHub Copilot, Claude Code, etc.
Advanced harnesses will give precise instructions to the model to tell him what tooling / skills / MCPs / etc are available, and will orchestrate all the actions around the model (like starting subagents, calling external tools, etc).
The harness is the software that runs the model, and, in the case of agents, implements the agentic loop, and provides capabilities external to the model (either directly or by interfacing with other systems.)
You need a harness for ANY use of a model because otherwise you just have a bunch of numbers that are the weights and no actual software that does anything with them, and you can’t have agents without a harness that provides the capabilities that define agents.
I think that is what OP was fishing for. Wrong answers ;).
Llama.cpp is not harness, setting up prompt template to have instruct model is also not what people call harness.
What people call harness nowadays is software that you interact with and it proxies model interactions. It can do agentic loop but the loop is not really much use for models that do “thinking” unless you want to layer your own loop on top for dealing with results and good harness can help - but usually if something runs loop it is called an agent not a harness.
So if harness proxies all interaction with model it also provides tools for model. It can provide context management and security features, where as security features would be preventing injections and making sure model doesn’t access stuff it shouldn’t.
The off-the-shelf player in this space (structured red-team search) is probably https://github.com/usestrix/strix (no affiliation). But any frontier model, if you tell it "here's how the authentication system works, go looking for bugs" will probably do a good job.
This whole vulnerability thing is the first time I'm really feeling like AI tech is a shakedown more than a value-add to my job. So I have to take multiple different frontier models, burn tokens constantly scanning all my code bases with complicated harnesses that eat tokens by the hundreds of millions, burn tokens cross-checking the cross-checks of the cross-checks in some eight-phase process made out of non-deterministic agents, to feed them into another multi-stage multi-agent pipeline to try to turn them into actionable vulnerabilities, and if I ever stop or slow down this process I can expect to be explaining why I did that in a court case someday.
That's ridiculous.
And yet, presumably, the vulns are real.
What are businesses supposed to actually do with this?
What happens to the whole AI value proposition when instead of it being a way to pump out lines of code for crazy cheap it becomes a way for each line of code to become vastly more expensive than it was before?
I can't help but notice that in the section headed "What it costs" the $ symbol is conspicuously absent. I would definitely like to hear a much more concrete number on some sort of per-100k-line basis or something. I know that per-line isn't great but at least it would be something.
Maybe if the models get a lot better we wouldn't need all this cross-checking. And maybe they'd write fewer vulnerabilities for the other models to laboriously and expensively figure out in the first place.
But good gracious does this sound like the AI industry just asking for you to hand the a blank check, because it sure would be a shame if something happened to your code base, wouldn't it?
I don't have a solution to this. This is stricly a cri de coeur.
Except maybe to say that if this is going to be the way in the future that it becomes vastly, vastly more important to work out how to write more secure code from the very beginning. We've certainly been trending this way for the last few decades, hand-wringing aside security has gotten a lot better than it used to be, it's just the world has gotten more complicated and harsh as well so it doesn't always look like it. But it takes over a decade for things like "use parameters in your SQL query instead of concatenation" to go from some crazy guy's idea in some obscure open source package somewhere to common practice that can almost be counted on. That loop is going to have to close much faster and there's a lot of things that are barely registering on people's radars, like, the *at APIs for files (openat, etc.) need to be the default much, much sooner than their current trajectory has them on.
Agreed that they shouldn't be writing vulnerable code to begin with. You'd think the models would be trained to know when they are working on something that has security implications, and to validate the security of what they're building, as they're building it.
> What happens to the whole AI value proposition when instead of it being a way to pump out lines of code for crazy cheap it becomes a way for each line of code to become vastly more expensive than it was before?
I would consider that a good thing. Businesses should not able to make money by writing terrible, insecure code.
Anybody who prevents them from doing so surely deserves to capture the additional value created.
> What are businesses supposed to actually do with this?
A responsible business should increase an attacker's cost above the likely benefit. If your current threat model accepts the risk of a particular attack because "it would be too costly" and this model changes that, then you need to consider mitigating rather than accepting that risk.
Ah yes. It is clear that the root cause of this CVE last month is a lack of spend. Lessons learned: 2.1 trillion tokens is insufficient to detect obvious malware; increase token spend by 10x.
Are you aware that is a satirical story, not a real CVE? (Security was proof-of-work before LLMs, with humans as workers. A CVE getting issued before it's exploited in the wild means the defenders won this round.)
If I was doing this at scale, I'd be looking at two features in particular. Cached input tokens - leveraging the LLM's token cache to get a 10:1 cost advantage, and batch tokens, 2:1 cost saving.
The benefits of doing your own harness here is that you get to explicitly program around those specific things to optimize cost. And they both heavily benefit you in the way that these sorts of jobs work - at least for the hunt side of things.
TLDR - context management is pretty important for cost management when you're doing something repetitive in bulk.
VISA open sourced an expense-to-run harness they developed under glasswing, and I used that as the basis of a skill that I've found to be pretty effective with Claude Code: https://github.com/atgreen/secscan-skill
Dumb question: Can someone help me understand whag it means to have a “harness” for agents (and why you need one)?
I’ve done some reading on the topic and am just not getting it.
So, you have these models that you put things into (like text), and get things out of.
For many models, you can include a "tool definition" in that text input. Remember this definition is just JSON :)
Let's say you send a tool definition to the model, plus a text question.
The model responds with a request for you to call the tool. It's also JSON.
What shall you, the human, do with it? :) That's what the harness is for: In this case, it interprets that JSON request and returns a JSON response that the model can understand.
In general, a harness is anything that manipulates the model input and output for your benefit: It may recall memories and place them into your context automatically, handle tool requests, prune long conversations, injecting parts of old conversations, and so on.
The harness is the tool you use to communicate with the model.
It can be as basic as a simple conversation tool (like ChatGPT back in the day), or more advanced like GitHub Copilot, Claude Code, etc.
Advanced harnesses will give precise instructions to the model to tell him what tooling / skills / MCPs / etc are available, and will orchestrate all the actions around the model (like starting subagents, calling external tools, etc).
Hermes, OpenCode, Claude Code seem to be Harnesses.
"GitHub Copilot" seems to be a harness and five other products that share this name.
The harness is the software that runs the model, and, in the case of agents, implements the agentic loop, and provides capabilities external to the model (either directly or by interfacing with other systems.)
You need a harness for ANY use of a model because otherwise you just have a bunch of numbers that are the weights and no actual software that does anything with them, and you can’t have agents without a harness that provides the capabilities that define agents.
I think that is what OP was fishing for. Wrong answers ;).
Llama.cpp is not harness, setting up prompt template to have instruct model is also not what people call harness.
What people call harness nowadays is software that you interact with and it proxies model interactions. It can do agentic loop but the loop is not really much use for models that do “thinking” unless you want to layer your own loop on top for dealing with results and good harness can help - but usually if something runs loop it is called an agent not a harness.
So if harness proxies all interaction with model it also provides tools for model. It can provide context management and security features, where as security features would be preventing injections and making sure model doesn’t access stuff it shouldn’t.
The off-the-shelf player in this space (structured red-team search) is probably https://github.com/usestrix/strix (no affiliation). But any frontier model, if you tell it "here's how the authentication system works, go looking for bugs" will probably do a good job.
Curious how Strix/Shannon/Deepteam all stack up against one another
This whole vulnerability thing is the first time I'm really feeling like AI tech is a shakedown more than a value-add to my job. So I have to take multiple different frontier models, burn tokens constantly scanning all my code bases with complicated harnesses that eat tokens by the hundreds of millions, burn tokens cross-checking the cross-checks of the cross-checks in some eight-phase process made out of non-deterministic agents, to feed them into another multi-stage multi-agent pipeline to try to turn them into actionable vulnerabilities, and if I ever stop or slow down this process I can expect to be explaining why I did that in a court case someday.
That's ridiculous.
And yet, presumably, the vulns are real.
What are businesses supposed to actually do with this?
What happens to the whole AI value proposition when instead of it being a way to pump out lines of code for crazy cheap it becomes a way for each line of code to become vastly more expensive than it was before?
I can't help but notice that in the section headed "What it costs" the $ symbol is conspicuously absent. I would definitely like to hear a much more concrete number on some sort of per-100k-line basis or something. I know that per-line isn't great but at least it would be something.
Maybe if the models get a lot better we wouldn't need all this cross-checking. And maybe they'd write fewer vulnerabilities for the other models to laboriously and expensively figure out in the first place.
But good gracious does this sound like the AI industry just asking for you to hand the a blank check, because it sure would be a shame if something happened to your code base, wouldn't it?
I don't have a solution to this. This is stricly a cri de coeur.
Except maybe to say that if this is going to be the way in the future that it becomes vastly, vastly more important to work out how to write more secure code from the very beginning. We've certainly been trending this way for the last few decades, hand-wringing aside security has gotten a lot better than it used to be, it's just the world has gotten more complicated and harsh as well so it doesn't always look like it. But it takes over a decade for things like "use parameters in your SQL query instead of concatenation" to go from some crazy guy's idea in some obscure open source package somewhere to common practice that can almost be counted on. That loop is going to have to close much faster and there's a lot of things that are barely registering on people's radars, like, the *at APIs for files (openat, etc.) need to be the default much, much sooner than their current trajectory has them on.
Agreed that they shouldn't be writing vulnerable code to begin with. You'd think the models would be trained to know when they are working on something that has security implications, and to validate the security of what they're building, as they're building it.
> What happens to the whole AI value proposition when instead of it being a way to pump out lines of code for crazy cheap it becomes a way for each line of code to become vastly more expensive than it was before?
I would consider that a good thing. Businesses should not able to make money by writing terrible, insecure code.
Anybody who prevents them from doing so surely deserves to capture the additional value created.
> What are businesses supposed to actually do with this?
A responsible business should increase an attacker's cost above the likely benefit. If your current threat model accepts the risk of a particular attack because "it would be too costly" and this model changes that, then you need to consider mitigating rather than accepting that risk.
> burn tokens constantly
Only if you choose to use the most expensive option.
Did you see the article about how security is becoming PoW? Whoever spends more tokens wins
Ah yes. It is clear that the root cause of this CVE last month is a lack of spend. Lessons learned: 2.1 trillion tokens is insufficient to detect obvious malware; increase token spend by 10x.
https://nesbitt.io/2026/06/26/incident-report-cve-2026-lgtm....
Are you aware that is a satirical story, not a real CVE? (Security was proof-of-work before LLMs, with humans as workers. A CVE getting issued before it's exploited in the wild means the defenders won this round.)
If I was doing this at scale, I'd be looking at two features in particular. Cached input tokens - leveraging the LLM's token cache to get a 10:1 cost advantage, and batch tokens, 2:1 cost saving.
The benefits of doing your own harness here is that you get to explicitly program around those specific things to optimize cost. And they both heavily benefit you in the way that these sorts of jobs work - at least for the hunt side of things.
TLDR - context management is pretty important for cost management when you're doing something repetitive in bulk.
> The benefits of doing your own harness here is that you get to explicitly program around those specific things to optimize cost.
I've toying with pi.dev to do something like that.
It's nearly as if, in the end, we'll still be coding after all.
or just let pi create that approach - i.e. slap the above input into a clanker's input field and see what comes out.