Our services
Three practices, one method. We evaluate how your AI performs, test whether it can be made to misbehave, and check the APIs it acts through. Each one runs on Discover, Specify, Interrogate, Report.
The practices
How does your AI fail, and how often? We find the failures that matter using your data and your experts, then measure them with confidence intervals. Not the vendor's benchmark. Yours.
AI Evaluation → 02 · AI & LLM SECURITYCan your AI be made to misbehave? Adversarial testing for prompt injection, data leakage and agents that act beyond their brief.
AI & LLM Security → 03 · BUSINESS LOGIC & API SECURITYThe flaws scanners don't find. What someone can actually do with your API, not just which patterns it matches.
API Security →Why it's different
Pass or fail is not enough.
AI systems fail differently from conventional software. Errors are probabilistic, outputs can drift over time, and the consequences of poor model behaviour in production can be difficult to detect and harder to explain.
Conventional tests pass or fail. AI needs failure rates, goldens that define good for your product, and monitoring that catches drift. Agents bring precision back: they must do exactly what they are specified to do, which is where our specification heritage applies directly.
Our method
One method across our practices.
| Stage | AI Evaluation | AI & LLM Security | API Security |
|---|---|---|---|
| 01Discover | What the AI does, what it reaches and trusts. Expert review of real outputs to find failure modes. | Every input the model reads and every tool it can call, each treated as an attack surface. | Every endpoint across versions, mapped to features and roles. |
| 02Specify | Goldens per priority feature, pass rules, acceptable failure rates, hard limits, tool contracts for agents. | Which OWASP LLM and agentic risks apply to what this system actually does. | What each role should and should not be able to do. |
| 03Interrogate | Code checks and validated AI judges, guardrail tests, adversarial and repeated runs. | Prompt injection, data leakage, excessive agency, guardrail bypass. | Authorisation, business logic abuse, race conditions, token attacks. |
| 04Report | Failure rates with confidence intervals, evidence, release gates, drift monitoring. | Reproducible findings, business impact, prioritised fixes. | Reproduction steps, business impact, fixes walked through with your engineers. |
Run as a loop, not a waterfall. We take one feature or sprint at a time, and gaps found in testing go straight back into discovery.
Engagements
Ways to work with us.
| Engagement | What you get | Typical length |
|---|---|---|
| AI Failure AssessmentStart here | We learn the system, find how it fails with your expert, and measure first failure rates on one to three priority features. Includes whether your human review actually catches failures. | 3 to 4 weeks. 2 weeks for one feature when traces exist. |
| Agent & Tool Contract Design | What your agent may call, in what order, what must be checked first, and when it must hand off to a person. Before or after launch. | 1 to 3 weeks |
| Eval System Build | Goldens, code checks and validated AI judges for your top failure modes, wired into your release process and handed to your team. | 4 to 8 weeks per feature group |
| Ongoing Evaluation | Regular review as features, models and prompts change. Drift checks, judge re-validation and reporting for risk, audit and the board. | Monthly or quarterly |
| Eval Literacy Workshop | A half day for your team: how AI fails, how to judge output, how to read and run your own evals. | Half day |
| AI & LLM Security Assessment | Adversarial testing mapped to the OWASP Top 10 for LLM and agentic applications. | 1 to 3 weeks |
| API Security Assessment | Business logic and API security testing, findings walked through with your engineers. | 2 to 4 weeks |
Starting small
Built it yourselves and nearly there?
Many teams build an AI product in-house, get it ninety per cent of the way, and are not sure what it takes to go live with confidence. We start small: a two-hour session where you demo the product and we work through structured questions, then a focused look at the one or two features that matter most.
In practice
How we work in practice.
Scope
A short scoping note: what we will test, how long it will take and what we need from you. Fixed scope.
What we need
Product and technical documentation where it exists: spec, API spec, requirements. A test environment, not development and not production. Time from someone who knows what good looks like, around half a day to a day a week for AI evaluation. A named owner on your side. Missing documentation is a finding in itself.
Safe testing
Staging by default. Production only with written authorisation and agreed rules of engagement.
Your data
Data stays in environments you control, under NDA from the first call.
Where we fit
Our logic-focused security testing complements an accredited penetration test. It does not replace one.
EU AI Act
What the EU AI Act means for your AI.
The EU AI Act tells you what to show. It does not tell you how to test it.
The Act sorts AI by risk. Most systems face no specific rules. Some practices are banned outright. Systems that can seriously affect health, safety or fundamental rights are classed as high risk and must meet strict requirements before they reach the market. And anything people interact with, such as a chatbot, must tell them it is AI.
Timeline
| Date | What applies |
|---|---|
| 2 February 2025 | Prohibited practices and AI literacy duties apply. |
| 2 August 2025 | Governance rules and obligations for general-purpose AI models apply. |
| 2 August 2026 | The Act is generally applicable. Transparency rules apply: anyone with EU users must tell people they are dealing with AI. |
| 2 December 2027 | High-risk rules for Annex III uses, such as biometrics, critical infrastructure, education, employment and access to essential services. |
| 2 August 2028 | High-risk rules for AI built into regulated products (Annex I), such as lifts and toys. |
Requirements and the evidence behind them
| What high-risk systems must show | Article | Evidence we produce |
|---|---|---|
| Risk assessment and mitigation | Art. 9 | Failure taxonomy, prioritised failure register, agreed thresholds per failure mode. |
| High quality datasets | Art. 10 | Goldens across expected, edge, misuse and business rule cases, with results broken down by customer group. |
| Technical documentation | Art. 11 | A method section in every report: what was sampled, who judged, how judges were validated. |
| Logging for traceability | Art. 12 | Trace review in discovery, and a check that logs let you reconstruct a decision. |
| Human oversight | Art. 14 | Seeded failures in review queues show whether your reviewers actually catch them. |
| Robustness, cybersecurity and accuracy | Art. 15 | Failure rates with confidence intervals. Adversarial and prompt injection testing. |
| Quality management, including testing | Art. 17 | A repeatable eval suite your team owns, with release gates. |
| Post-market monitoring | Art. 72 | Ongoing evaluation on sampled live traffic and a drift log. |
Does it apply to UK organisations?
Yes, if you place an AI system on the EU market or its outputs are used in the EU. A UK insurer with EU customers is in scope. A purely UK deployment is not, but the Act is fast becoming the benchmark buyers, auditors and boards measure against. In the UK, the automated decision safeguards in UK GDPR (as updated by the Data (Use and Access) Act 2025) and FCA expectations ask for similar evidence.
Every requirement for high-risk systems comes down to the same thing: showing, with evidence, that your AI behaves as intended, that human oversight works, and that you keep checking after launch. That is what evaluation produces.
Our reports provide evidence aligned to the EU AI Act. We never certify or claim compliance, and this is not legal advice.
Our roots
Before AI, before APIs, our work was functional testing and behaviour-driven development (BDD): agreeing in plain language what a system should do, then testing that it does it. That is no longer a separate service. It is the discipline behind all three practices.