AI systems
Enterprise IT & cloud

AI Security

AI agents and assistants, the applications, APIs and identity systems they connect to, and the environments you run them in: evaluation harnesses, training infrastructure, CI and developer machines.

Request a scoping call

Why we test it this way

Prompt injection needs three things to cause damage: access to private data, untrusted content reaching the model, and a way to send data out. That makes it an architecture problem, not something a guardrail fixes. In the AI deployments we have tested, the easiest way in has been ordinary: a debug endpoint left on, an over-privileged service account, an identity token the assistant should not have held. We test configuration and identity first, then the model.

An AI feature is an application with a model in it, so we test it in the order an attacker meets it. The model is last, and that is not a comment on the model.

The order we test in, and where one published case ended

1 Exposure and configuration What is reachable that should not be. Debug endpoints, admin surfaces, anything left on.
2 Identity and privilege What the assistant is allowed to be, and what it could reach if someone else were driving.
3 The application around the model Backend, service accounts, the API it calls, where it writes logs.
4 The model and the agent loop Injection, tool use, memory, and whether any of it produces an action that matters.

Where the published case ended

Django debug mode in production, then administrative credentials, then the identity tokens the assistant held. It was over at step two. Nothing in steps three or four was needed.

One case, not a population.

An AI feature is still an application. It has a backend, a service account, an identity integration, an admin interface and somewhere it writes logs, built quickly and often by a team building their first one. We test all of that, not just the model. If the real risk turns out to be in the training data or the model files themselves, we test that as well.

You also run agents you did not ship. Evaluation harnesses, training infrastructure, CI runners and the coding assistants on your developers’ machines are agent deployments with credentials, network reach and somewhere to write. An evaluation sandbox with no internet access can still reach an internal package registry that has it. A channel two agents use to coordinate can survive having its credentials revoked and its host rebuilt. Both are properties of how agents are run rather than of any one incident, and both are in scope on this page: the environment an agent runs in, and the channels agents open to each other.

What we found

A publicly reachable enterprise AI assistant had Django debug mode enabled in production. From there the path ran through administrative credentials to the identity tokens the assistant held, without touching the model at any point. Disclosed and remediated.

How

Unsolicited review of a publicly reachable deployment, disclosed to the operator and remediated before publication.

What it does not support

One case, not a population. It shows that this path exists and was reachable, not how often it is. The base-rate study is outstanding.

We don’t need to hack your AI Agent to hack your AI Agent

Where engagements usually start

Three shapes these engagements take. Scope is set with you, most clients combine them, and none of these is a fixed package.

AI Agent Assessment

We attack the AI feature you shipped, as deployed.

Configuration and credentials first: debug surfaces, exposed internal endpoints, service-account scope, secrets, admin interfaces
Tool and retrieval boundaries: authorisation on every callable action, tenant and document isolation, cross-user leakage, and the tool descriptions themselves, MCP servers included
What the tools run inside: whether the runtime reaches a cloud metadata service, an internal registry or a package mirror, what egress it has, which secrets are readable from the agent process, and whether one agent can read what another wrote
Identity, memory and transcripts: SSO and directory integration, token handling, chat logs, and whether one session can write something that steers the next
Prompt-injection chains and jailbreaks, pursued until they reach a real action or a real disclosure
Availability and cost: token exhaustion, reasoning loops that do not terminate, and deliberate amplification of your inference bill

Agent Estate Review

We test the agents you run internally: evaluation harnesses, training infrastructure, CI runners and the coding assistants on your developers’ machines.

What a sandbox can reach with no internet access: the package repository, the artefact store, the model registry, and which of those can reach the internet on its behalf
What one agent can leave where another agent reads it, including any path that survives a credential revocation and a rebuild
CI and build agents: which credentials the runner holds, what an agent-authored change can merge without a human, and what one job writes that a later job trusts
Coding assistants on developer machines, with their extensions, skills and MCP servers inventoried and the reach of each one established
Whether the harness records its own tool calls, arguments and identities, how long that record is kept, and whether it outlives the agent. We test the instrumentation you have rather than building it.
Whether an agent can be stopped: who holds that authority, and whether the path has been used

Model Evaluation

Before a model goes into a workflow that matters, we measure whether it does the job and what it discloses doing it.

The task measured against your own material rather than a public benchmark, because a leaderboard score does not tell you how a model performs on your codebase, your tickets or your logs
Several models compared on the same task, including small local ones, so the choice is made on evidence rather than on the assumption that the largest model wins
What leaves the machine at each step, itemised: not only whether source or documents are sent, but the metadata around them, which is usually the part nobody has looked at
Where a human still has to sit in the loop, and what it costs to keep them there
Run again when you change model or version, since neither of those is a no-op

Also available: AI Act readiness, which starts with whether your system is in scope at all, under which article and in which role (provider, deployer or GPAI provider), covers the Art. 50 transparency duties that have applied since 2 August 2026 and the GPAI obligations that have applied since 2 August 2025, and ends in a scoping determination you can put in front of a regulator. Art. 15 robustness and cybersecurity testing follows where the system is high-risk. AI red teaming, where the AI system is the target or the vector in a TIBER- or DORA-grade adversary emulation against your enterprise. ML pipeline and model supply-chain review when the risk is upstream. Incident response when an AI system is the cause, the vector, or the victim. Using AI to review your own code is a different service and sits under Software Assurance.

What the assistant is allowed to be

An assistant acts with an identity, and that identity is usually inherited from a service account somebody set up in a hurry. The gap between what the feature needs and what the token actually opens is the blast radius, and it is what a prompt injection spends.

Capability Needed Granted
Read the ticket the user opened yes yes
Search the public help articles yes yes
Read every ticket in the tenant no yes
Read the internal wiki no yes
Call the user-administration API no yes
A directory token that works outside the app no yes

Illustrative, and drawn from the shape of what we find rather than from one engagement. Four rows of blast radius, none of which the feature uses.

How we work

Two tests only become possible once an assistant has tools and a memory, and they are the ones we start from. The first compares what the model is told a tool does with what the tool actually does: a poisoned description keeps a working interface and returns correct results while it reads files or forwards data elsewhere. The second checks whether anything written during one session can steer retrieval or an action in a later one, including entries planted to sit dormant until something triggers them. Around those, the ordinary work: mapping what the agent can call and what each identity could reach if someone else were driving, then configuration, credentials, admin interfaces and secrets. Model-level attacks come last and we follow them until they cause a real action, because odd output on its own is not a vulnerability. We work from three positions in turn, each finding what the others cannot: as a plain user, then with the prompt structure and tool wiring shared with us, then with the architecture and code open. A sandbox and a network monitor watch an agent from outside, so what they hold is what crossed a boundary rather than which tool was called with which arguments. The harness that calls the model can hold both, which is why we test the record it keeps: whether it covers tool calls and identities, whether it outlives the agent, and how far back it goes. Building that instrumentation is not our work. Nothing reaches the report until we have confirmed it is reachable and shown what it lets an attacker do. We also tell you what we ruled out.

Related research

Work we do not take

If your problem is mainly alignment, content safety or bias evaluation, foundation-model pre-training security at frontier-lab scale, formal verification of ML properties, or a certification exercise such as ISO/IEC 42001 without technical testing underneath. Building the agent instrumentation, writing the detection content that consumes it, and running the monitoring afterwards are jobs for your platform team or a managed provider, and we test the result rather than supplying it. Tell us early and we will say so rather than take the engagement.

Send us the problem

Tell us what you are building and what you need looked at. You will get an answer from the people who would run the engagement, and if another firm is the better fit for what you are asking, we will name one.

Get in touch