AI Security

Your AI feature is a new door into the business. Check who can walk through it.

An assistant that reads your documents and answers questions from them has, in one deployment, joined your network, taken your permissions and started a conversation with the open internet. Most of the incidents we are called about are not exotic. They are a demo endpoint that never came down, a key in a repository, or a system that was helpful about the wrong thing.

Book a scoping call All services and prices

Four questions

Every review answers the same four. The technique comes second.

We can usually say which of these you cannot answer confidently on the first call, and that answer sets where the two weeks go.

What can reach it?

An assistant bolted to a public endpoint is a new front door, and it is rarely in the diagram anybody drew. We map every way in from the internet before we look at anything else.

Who may ask it what?

Authentication proves who is calling. It does not prove they are allowed to see the payroll policy. We test the gaps between the two, because that is where assistants leak.

What leaves the building?

Every prompt, attachment and embedding that crosses to a model vendor is a disclosure. Some are fine and contractual. Some quietly keep your data for two years and train on it.

What can it be talked into?

A helpful system will follow instructions it was not given. We try to make yours reveal something it should not, on your system, with the transcripts kept as evidence.

What we check

Four groups, because findings are more useful grouped by what they expose.

This is the working list, not a brochure version of one. Depth moves between groups depending on what the system actually is. A public assistant and an internal one rarely need the same two weeks.

Exposure

What an attacker can see before they have a single credential.

Public endpoints, ports and admin panels tied to the AI feature, including the ones left over from a pilot
Pre-production and demo instances, which usually hold real data and no authentication
Rate limits and cost ceilings, because an unbounded endpoint is a billing incident waiting for a script
What the infrastructure says about itself: error messages, debug routes, model names and versions

Access control

Whether permission survives contact with the assistant.

Authentication on every route, including webhooks, batch jobs and anything a service account can call
Authorisation per request: does the backend re-check the caller's rights, or trust what the model was told
API keys and secrets: where they live, who can read them, whether one leak rewrites your whole estate
Least privilege for the tools the assistant can call, and what happens when it calls the wrong one

Data exposure

Where your information goes, and how long it stays there.

What is actually in a prompt: context, retrieved chunks, attachments, history, and the metadata nobody counted
Model and vendor terms: retention window, human review, sub-processors, and whether it trains on you
Logs, traces and evaluation datasets, which outlive every deletion policy you have written
Vector stores and caches: who can query them, and whether one leaked embedding is recoverable text

Model abuse

What happens when the instructions arrive from the data instead of the developer.

Prompt injection through documents, emails and web pages the assistant is asked to summarise
Data exfiltration: getting the system to repeat what it can read, one polite question at a time
Tool and function abuse, where the model is nudged into actions its integrations permit
Output handling: XSS and injection through anything the model renders back into your application

How it runs

Two weeks, and you are in the room for all of it.

Day 1
Scoping call
One deployed system, one architecture diagram, one honest list of what you have already worried about. Fixed price after it.
Day 2–3
Threat model
The system as it actually runs, not as the design document says: assets, trust boundaries, and what a person with no credentials could attempt.
Day 4–8
Testing
Exposure mapping, permission testing with real accounts, and live injection and exfiltration attempts against your own system in an agreed window.
Day 9–10
Report
Findings with evidence, ranked by what they expose rather than by how clever the exploit was, plus the five-minute summary for your board or DPO.
Day 11–14
Retest
Your team fixes the top items, we re-run the same tests and record what changed. The engagement ends with a closed list, not an open invoice.

From £2,500 for one deployed system, fixed after scoping. Multi-tenant platforms and anything with payment or health data take longer and cost more, and you will hear that on the call rather than in the invoice.

Get a price for your system

Our conduct

We become a temporary risk to you. Here is how we hold that.

We sign your NDA and our own data processing terms before any credential is issued.
Test accounts and traffic are tagged, so your team can tell our work from an incident in your own logs.
Findings live in an encrypted store, are shared with named people only, and are deleted on an agreed date.
We never exfiltrate data we were not asked to prove reachable. A screenshot of the path is the deliverable.

Straight answers

The questions that decide whether this is the right engagement.

Is this the same as a penetration test?: No, and you probably still want one. A pen test asks whether an attacker can get in. This asks what happens once they are talking to your AI feature: what it will reveal, what it is allowed to do, and what it can be persuaded into. A pen test on the network and a review of the AI feature are complementary, and we will say plainly if what you need is the former.
What access do you need?: As little as works. Read-only on the repository and configuration, one ordinary user account and one privileged account for permission testing, and an agreed window for testing against a non-production system where one exists. Where production must be involved, we test read paths only and tell your team before and after each pass.
We have not built it yet. Is it too early?: It is the cheapest moment you will get. A design review before the build, covering where the model runs, what the assistant may call, how permissions are enforced and what the vendor retains, typically runs two or three days and prevents the version of this report that has red items in it.
What if you find something serious on day three?: You hear about it the same day, by phone, before it appears in any document. There is no value in holding a working exfiltration path until the report is polished. We also do not publish or demonstrate findings publicly without written agreement.

Say so honestly

When this is not the thing you need.

A compliance certificate to satisfy procurement, which is a different exercise with different evidence.
A general network penetration test of your estate, which needs credentials, scopes and rules of engagement this does not cover.
A review of a model you have never deployed. Read the vendor terms and the retention policy first; half the risk is in the contract.

If you tell us what went wrong and it turns out to be one of these, we will say which kind of help to buy, including from somebody who is not us.

Next step

Start with the endpoint you are least sure about.

Name the system, and we will tell you on the call whether it needs a two-week review, a three-day design read, or nothing at all.

Book a free call [email protected]