AI red teaming and adversarial testing

What it is for

Testing the model alone tells you little about the system you run. S1 tests the application around it: the prompts, the retrieval, the tools, the output handling and the people and systems that consume the output. The question is not whether the model can be made to say something odd, but what an attacker can make your system do.

What we test

Every engagement covers the ten risks in the OWASP Top 10 for LLM Applications, from LLM01 Prompt Injection to LLM10 Unbounded Consumption,^⁠[1] and, where the system uses agents, the ten risks in the OWASP Top 10 for Agentic Applications, from ASI01 Agent Goal Hijack to ASI10 Rogue Agents.^⁠[2] In practice that means:

• direct and indirect prompt injection, including instructions hidden in documents, web pages, emails and tool results;
• data exfiltration through answers, links, images, tool calls and logs;
• excessive agency: actions the system can take that it should not;
• system prompt and configuration leakage;
• unsafe handling of model output by the code that receives it;
• cost and capacity abuse.

Each test case is tagged with its MITRE ATLAS technique, for example AML.T0051 LLM Prompt Injection and its indirect form, AML.T0051.001.^⁠[3][4]

What you receive

A report your board can read and your engineers can act on, a proof of concept for every finding, a retest letter once fixes are in, and the test cases as a regression suite that runs in your CI, so a fixed finding stays fixed.

How it runs

S1 runs under the TriOngle Method and draws on the OWASP GenAI Red Teaming Manual, version 1.0 (20 October 2026), which sets out an eight-phase approach to testing generative AI models, applications and agents.^⁠[5] Rules of engagement are agreed in writing first. Test evidence is kept on EU servers only.