How AI strengthens whole brand offensive security

When a client asks me how we are using AI, I want the answer to start with their business.

What are they trying to achieve?
What must keep running?
What would cause serious harm if an attacker could reach it?

Those questions should shape the testing. An attacker pursuing their own objective does not have to stay within the boundaries of a web application, a network assessment or a social-engineering exercise. The route may cross all three using whatever tools they have at their disposal. Our approach to AI needs to reflect that.

At CovertSwarm, there are two complementary parts to how we use AI: the agents and tooling we develop ourselves, and our specialists using it where appropriate, throughout their work.

We have built agentic capability across network, web, research, social and attack surface mapping, at different stages of development and use. Both parts serve the same whole-brand approach, aligned to our clients’ strategy and business risks.

This ensures our delivery team are able to accurately recreate the techniques the adversaries are using, and provide even more capacity to investigate credible threats, connect evidence and establish what an attacker could actually achieve.

As COO, my job is to make sure that ambition translates into secure and scalable delivery, with clear responsibility for what we do.

We want each new finding to inform the next line of enquiry across the whole brand, helping our team adapt its testing as the client’s business changes.

The threats are already using AI

The threat actors our clients worry about have always been at the forefront of innovation, and are building and using AI extensively to achieve their objectives. We are doing so too, albeit with positive outcomes from those same objectives.

Anthropic’s September 2026 threat report described criminal and suspected state-linked operations using agentic workflows across reconnaissance, intrusion and data theft. It also made an important qualification: “humans have retained the decisions that matter most to them”. These are the provider’s findings from investigated cases, not evidence that every attacker now operates autonomously. ^[1]

OpenAI’s February 2026 reporting similarly described malicious actors combining AI with established tools and infrastructure, sometimes using different models at different stages. ^[2] People choose the malicious objectives; increasingly capable systems can then execute substantial parts of the work. Both parts of that picture matter.

We need to understand how these capabilities change the paths an attacker can pursue, and how to test the controls standing in their way. That does not mean reproducing every claimed AI attack. It means bringing credible threat intelligence into a strategy grounded in the client’s actual exposure.

Whole brand means starting with business risk

Whole-brand testing is more than a longer list of technical targets. It connects the organization’s strategy, critical operations, people, technology, internal tooling and external presence to the outcomes an adversary might pursue.

A client introducing a new digital service will have different concerns from one integrating an acquisition or protecting a critical operational process. Those priorities should influence the hypotheses we investigate, the routes we explore and the evidence we seek.

Consider an illustrative path: a public-facing asset reveals a relationship with a supplier; further research identifies a plausible social-engineering opportunity; access obtained through an authorized exercise exposes an application or a network trust relationship and security gap. In this scenario, the connections help establish business consequences and determine what deserves attention first.

Our five areas support that broader approach:

Network capability supports investigation of exposure, relationships and potential attack paths under practitioner direction.

Web capability supports application investigation and testing, with evidence reviewed for validity and business significance.

Research capability helps practitioners investigate technologies, disclosures and potential weaknesses, then test the hypotheses that follow.

Social capability supports contextual research and the preparation of credible scenarios for human selection and authorized delivery.

Attack surface mapping connects assets, technologies and external relationships so the team can prioritize where to look next.

The value is how these capabilities inform each other. Our delivery approach also considers physical routes where they are relevant and authorized; that should not be confused with a claim that physical testing is automated.

Our Red Team AI Division (RAID) is continually building and innovating our own agents, harnesses and tooling across these five areas. This includes multi-agent systems for end-to-end web applications and external-perimeter attack plans, from target identification through to exploitation. All to help our team of experts recreate the real-world threats our clients face.

Our people remain responsible for the strategy, with engineering designed to connect evidence and support repeatable, controlled investigation.

Our specialists using AI natively

Alongside our own engineering, every practitioner in the Swarm is enabled to use AI directly in their day-to-day work. AI-assisted testing, including frontier models through Amazon Bedrock, is already part of delivery. Our own agents help us build reusable capabilities; direct use gives specialists the flexibility to investigate an unfamiliar problem and adapt quickly. We need both.

That includes models from OpenAI and Anthropic, alongside open-weight models such as Qwen.

We use Amazon Bedrock where appropriate and choose the vendor, model and workflow best suited to the scenario, the data and the permissions involved. Access to a model through a cyber program is not blanket permission to use it against a client, and we always follow the clients’ rules of engagement to ensure we work within their permissible framework

In selected difficult lab scenarios, newer frontier models have solved tasks that earlier configurations struggled with. In other scenarios, older models have outperformed newer frontier models.

Older models have also proven useful, and sometimes better, when paired with well-designed tooling and methodology. Latest does not always mean best for the task. We benchmark the complete system, not just the model name, because context, tools and the specialist’s judgement all affect the outcome.

In any profession, you choose the skills and tools that suit the work. We apply the same discipline here, considering reliability, data handling, cost, and operational control. Practitioners use AI to analyze large datasets, assist with reverse engineering of vendor patches and vulnerability disclosures, generate and mutate test payloads, and adapt bespoke tooling and proof-of-concept code for authorized testing.

Specialists review the outputs and keep the activity within the agreed scope.

What an agentic demonstration proves

There is a lot of activity around agentic penetration testing. The useful question is what sits behind the demonstration.

What was the system allowed to see? What did a human configure or correct? Was the finding independently reproduced? How often did the result repeat? Did the system stay inside the permitted scope? A successful run can be valuable evidence without proving that the same system will deliver a reliable assessment in a different environment.

CTFs and other challenging environments are useful for developing and comparing specific skills. They are not, by themselves, a sufficient benchmark for professional delivery. Capturing a flag does not tell us whether the assessment covered the important areas, missed a different route, produced an actionable explanation, or created unacceptable operational risk. The UK government’s work on testing frontier models in cyber defense makes a similar distinction between synthetic benchmark performance and practical work on real vulnerabilities. ^[3]

Our own experiments have made that very tangible. In one lab exercise, an apparently impressive result depended on the agent reaching the lab’s source of material from its environment. That changed what the score could tell us. Source-assisted testing is perfectly legitimate when that is the task; it cannot simply be treated as equivalent evidence of discovering a route without that access.

The lesson is to inspect how the result was obtained. A score without that context can answer the wrong question very convincingly.

Our recent PHP2Shell work is a practical example of AI supporting patch analysis and vulnerability research. That does not turn generated code or a plausible explanation into a verified exploit. The specialist still must investigate, test, and validate what the evidence supports. The same discipline applies to laboratory results: repeatability, evidence of quality and test conditions matter more than an impressive demonstration.

Building baselines that reflect delivery

We have built internal evaluation environments and instrumentation, and we are extending them towards more realistic, repeated assessments.

The baseline we want has to account for more than whether an agent reaches a final objective. It should tell us:

What the system found, what it missed, and what was independently validated.

Which information, tools and permissions were available to it.

How much operator intervention was needed, and why.

Whether the result repeats under comparable conditions.

Whether it respected scope and operational constraints.

What time and resources were consumed in producing useful evidence.

We are also examining coverage separately from successful exploitation. An agent can reach one objective while leaving important parts of an application unexamined. Conversely, an investigation can produce valuable evidence about a control without ending a dramatic compromise.

This discipline applies to our own work as much as to anyone else’s marketing. If we cannot explain the conditions and the route to a result, we should be careful about the conclusion we attach to it.

Control must happen before execution

Human expertise remains central, but “a human is watching” is not an adequate control on its own. Agents can act faster than a person can follow every tool call. The architecture has to restrict what can happen before an action is executed.

The model vendors themselves recognize this.

OpenAI’s published operating guidance combines human oversight with restricted access, independent monitoring, and pre-execution review of sensitive actions. Anthropic’s published requirements for its higher cyber-access tiers include externally enforced network allowlisting and logging. ^[4] ^[5]

For us, the engineering questions are concrete.

Which targets can an agent reach?
Which credentials can it use?
What can a tool actually change?
When must an operator approve an action?
What stops the run if a control fails?

A brokered tool can enforce limits that a model’s own instructions cannot guarantee. Read-only and mutating operations need different treatment, but that distinction is only a starting point: a read can still expose sensitive information or cross an agreed boundary. Target, data, privilege and intended effect all matter. ^[6]

Our lab work already includes recorded activity, proxy-based scope controls, and human validation of findings. The wider control architecture must be matched to the model, workflow, and engagement, rather than assuming one configuration works everywhere. Dependable delivery requires testing those controls, not merely listing them in an architecture diagram.

There are separate permission questions too: access to a model, approval for its intended service use, and the client’s authorization for the engagement. One does not substitute for the others. Claims about frontier access should never imply that client data or systems can be used without the appropriate agreements and controls.

What clients should expect from us

Clients should expect a clear explanation of where AI supports their engagement, which activities remain practitioner-led, how actions are constrained, and what evidence supports the findings. Where a specific model or technique matters to the assurance question, the answer needs to be specific to that engagement rather than borrowed from a laboratory demonstration.

Our direction is continuous, whole-brand offensive security that can adapt as the business and its exposure change. AI can help our people pursue more useful lines of inquiry and carry context between them. Expertise is what turns those possibilities into a relevant attack strategy, a sound judgement and a finding the client can act on.

As the NCSC puts it, “Defenders simply cannot put AI to work in the same way attackers can.” ^[7] We have to protect the organization while testing it and remain accountable for the choices we make.

That is the standard I want CovertSwarm to be judged against: whether we are helping clients understand and reduce the risks that could stop them achieving their objectives, with evidence they can trust.