AI Security Assessment & Red Teaming Test the AI system you built or bought, before attackers do

The AI system as your users and connected systems reach it, within the scope you sign. That normally covers the model's behaviour through your application, the retrieval layer and its document permissions, the tools and actions available to an agent, how other systems handle its output, and your guardrails and cost limits. The surrounding application, APIs and infrastructure are tested with our Penetration Testing team. We reach the model only through your application and do not test the model provider's own infrastructure. The rules of engagement list each component in scope and each one left out.

It tests what a standard penetration test leaves out: how the model behaves, what it reads and what it can do. A penetration test checks authentication, APIs, configuration and infrastructure; it does not check whether a sentence hidden in a document can make an assistant reveal another user's files or call a tool. Here, ordinary language is the attack input and results vary between runs, so the method and the reporting differ. The two are often run together, with our Penetration Testing team covering the conventional part. Red teaming in this service means attacking the AI system itself; finding out whether your security operations centre (SOC) would detect an attack on it is the scope of our Red Team service.

Yes, but only within what the provider allows. Before we start, we read its terms and any testing policy it publishes: some providers allow testing of your own configuration and tenant but forbid attacks on shared infrastructure, and some require notice first. Where the terms do not allow a test, we do not run it. We test what is yours instead, such as your configuration, the data you connect, user permissions and how your systems use the output, and the report states what could not be tested and why.

We prefer a test environment that matches production, and test production only if you authorise it in writing, within agreed limits. Testing can change data, send messages, consume model budget and leave traces in logs and indexes, so a separate environment is safer. Where production has to be tested, for example because the test environment lacks the real tools or data connections, we agree test accounts, seeded documents, rate limits, set testing windows and a stop procedure, and point agent actions at test targets or put them behind prior approval. The report records any difference between the environment tested and production.

Each finding gets a severity based on its impact and likelihood in your context, and is mapped to the matching entry in the OWASP Top 10 for LLM Applications and MITRE ATLAS. Severity weighs what data or action is exposed, who can trigger it (an outside user, a signed-in user or an insider) and how reliably it reproduced. Findings in the surrounding application or infrastructure also carry a Common Vulnerability Scoring System (CVSS) score. For organisations in the scope of NCA ECC, we can also show which ECC subdomains each finding relates to; this is a reference mapping, not a compliance assessment.

Yes. Once your team or the system's builder has made the fixes, we retest the findings in scope and issue a retest letter. The retest repeats the original inputs the same number of times and adds variations of them, so a fix that blocks only one wording shows up. The letter records each finding as closed, partly closed or still open, and the conditions it was retested under; closed means it did not reproduce in the agreed number of attempts. The number of retests and the period for them are set in the contract.

Yes, with testers who took no part in the design or delivery of that system, and the report states this separation and any information or tooling the testers share with the delivery team. If your policy, your board or a regulator requires a tester independent of the company that built the system, choose another tester; the system documentation they need can be provided as set in the contract.

We repeat each test and report how often it succeeded, rather than the result of a single run. Model output varies with sampling settings, conversation context and model version, so one success shows a weakness exists while one failure does not show it is absent. Each finding states the number of attempts and successes, the exact inputs, and the model version and settings where we can see them. A weakness that succeeds rarely can still be rated high if its impact is serious.