Who is winning the cybersecurity race?
If offensive teams can use agentic AI to discover assets, analyse code, validate exploits, and chain attack paths, do they gain the advantage? When defenders use that same technology to scan continuously, triage faster, and move towards self-securing software, does the balance shift back? And where does all this leave the human operator?
Two debates at the Cyber Security Coalition’s Solstice Event explored those questions from different angles. Wout Debaenst of Aikido Security and Thomas Vanderhoydonck of Refracted Security focused on the future of offensive security. Jeoffrey Canters and Teun Westbroek of ThreatWorks brought the discussion into software engineering, where AI is no longer only testing applications, but helping to build them.
Reframing offensive security with AI
Traditional penetration testing is valuable, but it is also episodic, expensive and dependent on a limited pool of skilled professionals. Vulnerability scanners run 24/7 at a lower cost but often produce noise. Agentic AI could narrow that gap: more scalable than human-led testing, more context-aware than a scanner, and increasingly capable of performing specialised offensive tasks.
In such a model, different agents would handle different parts of the process: discovery, code analysis, exploit validation, attack-path exploration and triage. The goal would be self-securing software: systems that identify vulnerabilities, suggest or apply fixes, and then retest whether the issue has been resolved.
This would alter the rhythm of security work. With continuous offensive testing, organisations could no longer treat pentesting as a periodic reassurance exercise. They would need processes able to absorb a faster flow of findings, assign ownership quickly, and distinguish exploitable risk from automated noise.
The operator, not oracle
Thomas Vanderhoydonck remains convinced that AI cannot replace human supervision, and that red teaming cannot be reduced to automation. The value of a red team lies not only in finding a path, but in knowing which path matters, what is in scope, when to stay quiet, when to escalate, and how to avoid creating unnecessary risk.
AI can help with reconnaissance, parsing, attack-path suggestions and repetitive analysis. It can also surface embedded credentials or identify possible routes for lateral movement at lightspeed. But that creates a new kind of risk: tools that act faster than the operator can interpret them.
A red team engagement is a controlled exercise in adversarial thinking. The operator decides what is relevant. AI can support that judgement, but it cannot take responsibility for it.
The strongest model is therefore not a black box that produces dozens of attack paths without prioritisation. It is a co-pilot that explains confidence, rationale and operational implications, while leaving the operator in control.
When AI also builds the target
The second debate showed why the same question matters before software even reaches the security team. When ThreatWorks looked at AI-assisted development, the issue was not only that AI could introduce insecure code but also that it could make architectural assumptions without anyone explicitly approving them.
In a hackathon example, an AI-built application could be compromised in minutes, even after critical data had been removed for the test. The weakness lay in both the implementation and in the assumptions AI had made about role-based access control, authorisation checks, database exposure, password policy and brute-force protection.
Code scanners can flag insecure dependencies, exposed secrets or obvious flaws. But when AI is asked to “build a feature” without much context, it fills in the blanks itself. Canters and Westbroek’s debate made clear that if you do not provide enough context, AI will make assumptions and take security decisions for you. That risk becomes sharper when companies allow vibe coding without a security framework.
The human shift
For security teams, human expertise is moving upstream. It is needed in the prompt, the threat model, the scope definition, the guardrails and the validation process. Waiting until AI has acted and then inspecting the result will no longer be enough.
It remains unclear which organisations will benefit most from AI. Automation speed will matter, but only if it is paired with the ability to steer these systems before they begin to shape security decisions on their own. That is true for both cybersecurity and coding. In these fields, the advantage will not go to those who simply use AI the fastest, but to those who define most clearly what AI is allowed to do.
Picture 1 – Thomas Vanderhoydonck & Wout Debaenst ; Picture 2 – Teun Westbroek & Jeoffrey Canters
