AI System Security Assessment & Penetration Testing

Testing AI agents, LLM services and AI infrastructure as targets of attack

We test AI agents, LLM services and AI infrastructure from the attacker's side, and confirm whether they really stay inside the lines you have set.

We treat AI agents, LLM services and the infrastructure that trains and serves models as the target, and look for weaknesses in permissions, input, data exposure and isolation. When you bring in an AI agent or an LLM service, or launch a new architecture, we check that it really stays inside the lines you have set, such as ‘the AI agent sends nothing outside without a person's approval’. Our experts confirm every finding by hand.

Under attack, does our AI system stay inside the lines we have set?

We find the paths that cross the line through permissions, input, data exposure or isolation, and set out the real impact, the evidence and how to improve.

Reviewed

We confirm whether an agent that follows a hidden instruction can cross the line you set through one of its tools, and check that the line holds on the other paths.

When it fits

You are bringing in an AI agent or launching an LLM service
Before or after bringing an AI agent into your work or opening an LLM service to customers, you want to know that it keeps to the lines you have set when someone attacks it.
Agents are being given more tools and access
As an agent gains email, calendars, internal systems and outside tools, you want evidence of how far its permissions reach and where a person's approval is still needed.
You are connecting internal documents and data to AI
When retrieval-augmented answers or similar services draw on your documents and data, you want to be sure their contents and sensitive information are not shown to people without permission.
Several teams share training and inference infrastructure
When users and teams share GPU clusters, HPC environments and storage, you want to know that each one's data and model files are kept apart.

What we examine

We look at AI systems as three kinds of target, and at the places where they connect to one another and to your other systems.

AGENT

AI agents

The target: AI agents that work through email, calendars, internal systems and outside tools, together with the environment they run in.
What we can test: The reach of tool and API permissions
Where actions need a person's approval
How outside input (documents, web pages, email) affects behaviour
Data leaving through the agent
The execution environment and its isolation
Action records and traceability
Authentication to connected systems
An example line: ‘The AI agent sends nothing outside without a person's approval.’

LLM

LLM services

The target: Services built on language models, such as chatbots, retrieval-augmented answers and summaries, with their models, data and integrations.
What we can test: Prompt injection, direct and indirect
Exposure of sensitive data and system instructions
Permissions on the documents it retrieves
Output handling and its effect on connected systems
Whether safety policies work as intended
Misuse of usage and cost
The model and data supply chain
An example line: ‘Staff get answers only from documents they are allowed to see.’

GPU

AI infrastructure (GPU and HPC)

The target: GPU clusters and HPC environments used for training and inference, with their schedulers and shared storage.
What we can test: Job schedulers and management interfaces
Isolation between users and teams
Permissions on shared storage and training data
Access to model files
The software stack, such as drivers and runtimes
Networking between nodes
Inference service APIs
An example line: ‘One team's training data and model files cannot be read or changed by another.’

The areas and lines are examples. Targets, scope, deliverables, timelines and operational responsibilities are agreed for each engagement.

ScopeHere the AI system is what is being attacked. Evaluating and improving how well AI agents carry out security work belongs to Security Capability Development for People & AI.

How it runs

Agree targets and lines
We agree in writing the AI systems and integrations to test, the lines they must keep, how much you share with us, what is allowed and what is not, and when to stop.
Map the system
We set out with you the tools and permissions the agent uses, how models and data flow, and the connected systems and execution environment.
Test and validate
Tools and AI agents cover the ground; experts analyse by hand and safely confirm whether a path across the line really exists.
Explain and re-check
We explain the findings, real impact, evidence and fixes to decision-makers and the technical team and, if agreed, check the fixes again the same way.

Keeping it safeOn a live service we agree test accounts, scope and stop conditions first, so that real users and data are not affected. How conversation records and data handled during testing are kept and destroyed is settled before we start.

What you receive

Lines held and lines crossed

For each agreed line, whether it held and, where it did not, through which input, permission and path it was crossed.

Findings and real impact

What each finding would mean for the business, such as data exposure, actions beyond permission or runaway cost, with confirmed facts kept apart from signs that need a closer look.

Reproducible evidence

The inputs, conditions and records needed to confirm each result again.

What to fix and check again

What to fix first in permissions and approvals, input handling and isolation, and what to check again after a model or integration changes.

Results describe the agreed scope at the time of testing. When the model, its instructions or its integrations change, the same lines are worth checking again.