Service Line B · AI Security Assurance
Red teaming, penetration testing and security assurance of AI systems, performed as a neutral third party. We only ever test systems we did not build.
What we test
Testing scope grows with what the system can reach and do. Agents that use tools, and systems of agents, carry the most risk.
Injection, jailbreaks, leakage of hidden instructions and sensitive data.
AI that answers from company data: over-shared retrieval, cross-tenant access, poisoning.
Excessive agency, insecure tool wiring, and actions taken on the wrong instructions.
Trust between agents, chained failures, and paths from one agent’s compromise to real impact.
Every test also covers the classic surface around the model: application, API, identity and infrastructure. See the full method.
Depth of testing
We test at the level of access you give us. Every report states that level, and what stayed out of reach.
Least access
We are givenNothing beyond what an outside attacker sees.
Finds bestExternal exposure, prompt injection from outside, jailbreaks.
Typical useA realistic attacker’s view; pre-launch checks.
The report statesCoverage was limited to external behaviour.
Partial access
We are givenA normal user account and limited documentation.
Finds bestPrivilege abuse, leakage across roles, over-shared retrieval.
Typical useMost assistants and agents in production.
The report statesThe access given, and what stayed out of reach.
Full access
We are givenSource, configuration, system prompts, data pipeline and architecture.
Finds bestDesign flaws, insecure tool wiring, poisoning paths, guardrail gaps.
Typical useHigh-risk or regulated systems.
The report statesThe full method; the highest confidence we offer.
How an engagement runs
Authorisation comes before access, always. It is our ethic and the legal footing for the work.
Gate requires a signature to proceed.
If testing reveals a critical issue, live data or an active breach, we stop that test, preserve the evidence and tell your named contact at once. Testing resumes only when you approve it in writing.
Who it is for
Built in-house, bought, or delivered by another vendor. You need to know how it fails before an attacker finds out.
You want your work independently tested before delivery, so your client receives evidence, not assurances.
Our findings are point-in-time and reasonable, not absolute. We never call a system “secure”. Fixing findings is a separate engagement, and never one where we would then certify our own fix.
Signed authorisation and rules of engagement; a defined scope; and, for grey or white box testing, architecture documents, credentials or a test tenant. Where a cloud or platform provider’s terms require it, their written permission too.
Ways to start
Every engagement starts with a conversation about your needs and a scope agreed in writing. Each of these is a natural first step: narrow, concrete, and easy to approve.
A good first step
One AI system, tested independently at the depth you choose, against the OWASP LLM Top 10 and the surface around it.
After the first engagement
Periodic re-testing as your system or its model changes, and maintenance for systems we built.
For a single assistant, typically one to two weeks of testing, plus time to write the report. Agents with tools and multi-agent systems take longer. We agree the window in the rules of engagement before we start.
No honest tester can. We report what we tested, in what scope, on what date, what we found, and the risk that remains. Our wording is point-in-time and reasonable, not absolute.
No. That is the one rule we never break. We can re-test our own builds as internal QA under a support agreement, but independent assurance on them goes to another firm.
It depends on the depth you choose. Black box needs nothing beyond what an outside attacker sees; grey box needs a normal user account; white box needs source, configuration, system prompts and architecture. The report always states the level.
Techniques, test windows and exclusions are fixed in the rules of engagement before any access. Denial of service against production is excluded unless you explicitly agree otherwise in writing.
Only with your written consent. The rules of engagement name the tools, what they are used for, where data is processed, and confirm that your data is not used to train them.
Fixing is a separate engagement. If we build a fix, we will not then give an independent verdict on it; a retest by us would be labelled internal QA.
Next step
Tell us what it does, what it can reach, and when you need answers. We will propose a scope and a testing depth that fit.
A scoping conversation first. Nothing starts until scope and limits are agreed in writing.
