AI-powered offensive security

Your adversary already uses language models to prepare their campaigns. We use them in the parts of offensive work where they genuinely help, and not in the parts that demand judgement. This page sets out exactly where that line sits.

What changes when the attacker uses AI

What has changed is not the technique. It is the cost. Writing a flawless phishing email, in your company’s language and internal register, used to take time and sector knowledge. Today it takes a well-written prompt. The same goes for reconnaissance: cross-referencing old breaches, public profiles and technical documentation to rebuild your org chart was days of work.
The practical consequence is that targeted campaigns are no longer reserved for well-funded adversaries. If your last phishing simulation used generic templates with spelling mistakes, you measured a scenario that no longer exists.

Where we use AI in an offensive engagement

Reconnaissance
Your real attack surface
Correlating open sources, breach data and exposed infrastructure to rebuild your perimeter as an attacker sees it, including what your inventory does not list.
Social engineering
Credible pretexts
Phishing and vishing campaigns written in the register of your sector and your organisation, with scope and limits agreed in writing before we start.
Analysis
Code and binary review
Assisted reading of large volumes of code to locate suspicious patterns that are then verified by hand. The model flags; the analyst confirms or discards.
Detection
Controlled variants
Generating variants of the same technique to measure how far your EDR and SIEM actually reach: not whether they catch the known sample, but the whole family.
Reporting
Triage and prioritisation
Classifying findings by exploitability and business impact, so the team spends its time exploiting rather than writing.
And where we do not use it. No finding is accepted because a model said so: exploitation and validation are always manual, and anything that cannot be reproduced step by step does not go in the report. Nor does your data go to third-party services: the work runs on models deployed on infrastructure under our control. It is the same technology we build for clients in our private, on-premise AI line, applied here to our own work.

How we work

1
Scope and rules of engagement
We define objectives, systems in and out of scope, the execution window and a direct line to stop the engagement at any moment.
Before we start
2
Reconnaissance
Rebuilding your exposed surface and the human context of the organisation: who is who, who talks to whom, and what has been published without meaning to.
3
Execution
Manual exploitation of what we identified, logging every action and its timestamp so your team can correlate it afterwards against your own records.
4
Debrief with your defenders
We go through what your team saw, what they missed and why. This part usually delivers more value than the report itself.
5
Report and action plan
An executive report for the board and a technical one with every vulnerability reproducible, prioritised by real impact.

What you get

An executive report in business language, with risk expressed as consequences rather than scores.
A technical report with every finding reproducible step by step, so your team can confirm it independently.
A full timeline of the engagement, with timestamps, to check against your logs and measure what you detected.
A debrief with your defence team, aimed at improving detection rather than assigning blame.
A remediation plan prioritised by impact and effort, not by theoretical severity.
Verification of the fixes for the findings included in the agreed scope.

Frequently asked questions

Does AI replace the pentester?
No. It shortens repetitive work and widens reconnaissance coverage, but the decision to exploit, the chaining of vulnerabilities and the impact assessment remain human. A model does not know what it means for your business if one particular system goes down.
Will our data end up training a model?
No. The work runs on models deployed on infrastructure under our control, not on third-party services, and that is set out in the scope of the contract.
How is this different from a classic penetration test?
In the breadth of the reconnaissance and the realism of the social engineering. If what you need is the classic test against one application or network with a closed scope, the service you want is the penetration test, and we will tell you so.
Do you also audit our chatbot or assistant?
That is the other side of the coin and has its own service: in the AI security audit we attack your AI system, rather than using AI to attack you.
Is all of this legal?
Everything runs under written authorisation, a defined scope and an agreed window. Without that signed document, nothing gets touched.
Want to know how they would attack you today?
A thirty-minute call is enough to scope this and tell you whether this is the service you need or whether another one fits better. If it is not for you, we will say so.

Book 30 min with a specialist

ENES