Our services
Business-risk-led testing for APIs, AI security, and AI evaluations. We check whether your system does what was really intended, and find where it doesn't.
Everything we do runs through the same four-stage discipline: Discover, Specify, Interrogate, Report. It is how we read an unfamiliar system quickly, and why every finding arrives with evidence an engineer can follow.
One framework, applied four ways
Discover
Learn the system. What it does, where it reaches, what it trusts.
Specify
Map it. Write down what good looks like, precisely enough to test.
Interrogate
Attack the gaps between what was specified and what was built.
Report
Findings with evidence and the method that produced them.
Everything we do is business logic verification, based in exploration and discovery. It depends on the context of your team, your application, and its emerging properties. That context lives in the specification gap, and closing it takes someone who understands your business, not just your system.
Our approach
Every engagement follows the same path. You always know what we are testing, why, and what you will receive at the end. Every engagement runs on the same four-stage method you will see across our services: Discover, Specify, Interrogate, Report. Two commitments surround this process. A clear scope before we start, and a retest after you fix.
Before we begin: Scope
We work with you to understand and define your requirements, agree on the project scope, timeline and costs, and document any restrictions. You receive a statement of work before testing begins. Nothing begins until you have signed and approved the statement of work.
01 · Discover
We learn your system before we touch it. Documentation, OpenAPI specs, Postman collections, or a conversation with your engineers. Then we enumerate what is actually there: endpoints across versions, undocumented routes, every input your AI system ingests. The gap between what is documented and what is deployed is often the first finding.
02 · Specify
We map what the system is supposed to do. For APIs, that means which user should reach which data, which flows move money or entitlements, and where the boundaries are meant to sit. For AI systems, it means defining what a correct output looks like and how much variance is acceptable. This step is what makes our testing contextual rather than checklist-driven. It cannot be automated, and it is where twenty-five years of specification work earns its keep.
03 · Interrogate
Then we test.
For APIs: the OWASP API Security Top 10 as the starting frame, then deeper into your specific logic. Authorisation flaws and BOLA, broken authentication, mass assignment, SSRF, race conditions in payment and state-change flows, JWT implementation flaws, GraphQL abuse. Manual attack scenarios, tested against your specific logic rather than known signatures.
For AI systems: defined inputs run at scale, pass and fail recorded, failure modes characterised. Hallucination, silent omission, misclassification, and compounding errors in agentic chains.
04 · Report and debrief
Every finding arrives with reproduction steps, business impact, and a prioritised fix: what to change, in what order, and why. The technical detail is written for your engineers; the risk context is written for your CISO or Head of Risk. We walk the findings through with your team. We do not just send a static report.
After we report: Retest and stay
Once critical and high findings are fixed, we retest and confirm it. Many clients then move to a retainer: quarterly re-tests, reviews of new endpoints, and AI regression runs as models and prompts change. Systems keep changing. Assurance should keep up.
What we need from you
API documentation or specs (their absence is itself a finding). A staging environment that mirrors production. Test accounts for each role in scope. For AI systems, access to the system and agreement on what constitutes a correct output. A named contact for questions while we test.
Safe testing
Staging by default. Production only with written authorisation and agreed rules of engagement. Your data never leaves environments you control.
Where we fit
Testclub's work is logic-focused security testing. It complements an accredited penetration test, it does not replace one. If compliance requires CREST-accredited scanning, keep it. We find what accredited scanning structurally cannot.
The practices
01 · Web / API Security
Business logic, the OWASP Web and API Top 10s, authentication, authorisation. Testing built for what a scanner was never told to look for.
Read more →02 · LLM Security and Evals
Empirical failure rates, mapped against the OWASP Top 10 for LLM Applications, in your environment, against your data, on your tasks. Not the vendor's benchmark. Yours.
Read more →03 · Specification as Foundation
Twenty-five years of asking the same question, before it was APIs or AI. The discipline behind everything above.
Read the philosophy →The framework applied
The same four stages, shown as a pattern rather than described in the abstract. These are illustrative, not a specific engagement.
FunctionalAccess without ownership
A document or record is retrieved using a reference number, once a user is logged in.
Nobody had defined whether being logged in was enough, or whether each record needed its own ownership check.
Sequential reference numbers meant one valid link could reach records belonging to any user.
A broken object-level authorisation flaw, allowing any authenticated user to view records they should never have reached.
Web securityTrusting the upload
A file upload path accepts content into a directory the application later reads from.
What should happen to a file that doesn't match the expected type or structure? The behaviour was never pinned down.
A crafted upload, combined with how the session handled it, caused the server to execute content rather than store it.
A file handling flaw giving remote code execution, from a feature that looked like ordinary upload validation.
API securityThe sibling account
An endpoint accepts a user or record ID and returns data tied to it.
Should the ID alone be sufficient, or does it need to be checked against who's asking and what role they hold?
A user could substitute another user's ID and act on their behalf, with no check that the roles matched.
A broken function-level authorisation flaw, allowing sibling-level users with different roles to assume each other's tasks.
LLM security and evalsInstructions hidden in content
An AI system reads and acts on content it did not generate: emails, documents, retrieved pages.
What should happen when that content contains something that looks like an instruction?
A crafted piece of ingested content changed what the system did next, without any direct input from the user.
An indirect prompt injection, letting an attacker control the system's actions through content it was only supposed to read.