Question 09 · 🛡️ Security testing
What's the difference between a security agent and an uncensored model with a few tools?

It’s common to think that an AI model with safeguards removed is all you need for a powerful security tool. In practice, what makes the work effective is the system built around the model.
An “uncensored model” is an AI model with safeguards removed so it won’t refuse risky requests. That alone doesn’t make it a security tool: the software around the model determines which tools it can use, what it remembers, how it follows up on a finding, and what it tries when an approach fails.
A system built specifically for security testing gives a model a much more useful workflow than a generic chat window. Talks at security conferences like Black Hat are a good starting point for seeing how these agents and their tools are put together.
That’s why it’s useful to keep the model separate from the system around it: the same model can produce very different results depending on how the system is built.
What a harness is
A harness is the software that wraps around the model. It provides tools, keeps track of what’s been done, decides what to do next, and sets limits. The model suggests actions; the harness carries them out, checks the results, and sends them back to the model.
Without it, the model is just a conversation. It can explain a technique, but it can’t test anything or remember what it has already tried.
The four parts
Tools: scanners (programs that scan a system for known vulnerabilities), a browser, a terminal, each enabled for a specific task. Memory: a record of what was seen, the targets, and the hypotheses. Follow-up: when it finds something, the system investigates further instead of jumping to another topic. Plan B: when an approach fails, there’s a list of alternatives instead of blindly repeating the same attempt.
Tools are often connected through MCP (a standard for connecting external tools to AI models) or custom scripts.
Removing safeguards isn’t enough
An uncensored model just stops refusing requests. It doesn’t gain a method, memory, or access to tools. In many cases, a regular model in a well-built system with a clear scope is more effective. Anyone using a model without safeguards also needs to set the limits themselves: what can be accessed, how far to go, and when to stop.
How to evaluate a system
When comparing tools, replace the question "which model does it use?" with these: which tools does it call, how does it track progress, what does it do when a step fails, how does it stay within scope, and does it keep a record of what it did? Talks at security conferences like Black Hat show examples of these architectures.
- Define the scope and authorized systems in writing.
- Choose which tools the agent can use and enable only those.
- Create a persistent record of findings and attempts.
- Write down what the agent should try when a step fails.
- Compare systems by their structure, not just by the model name.
- Thinking that removing a model’s safeguards creates a security tool.
- Giving broad tool access without scope limits.
- Evaluating an agent without reviewing the record of what it actually ran.
- Model ≠ system.
- Tools, memory, and strategy make the difference.
- Same model, different results.