Loading…
Paid Audit
LLM-based systems have a security model that standard application security testing doesn't cover. Prompt injection, retrieval attacks, jailbreaks, and indirect data extraction are AI-specific vulnerabilities that exist in most production AI systems and are rarely tested before launch.
This is a structured security assessment for AI systems. We attempt to exploit your system using documented attack techniques, confirm which vulnerabilities are present, and give you a report with severity ratings, proof-of-concept exploits, and specific remediation instructions.
Tell us about your AI system.
Six attack surface categories, each tested methodically against your specific system, not a generic checklist.
We attempt to hijack your AI system's behaviour by injecting instructions through user input, document content, retrieved context, and tool call responses. Direct injection via the chat interface, indirect injection through poisoned knowledge base documents, and injection via external data sources your agent retrieves from. Every confirmed injection vector is documented with a proof-of-concept and a specific remediation.
We run your system against a structured set of jailbreak techniques: role-playing attacks, hypothetical framing, instruction override attempts, and multi-turn social engineering. We document which techniques succeed, what outputs they produce, and the specific system prompt or filtering changes required to close each vector.
If your system uses RAG, we test whether retrieval can be exploited to surface documents the user shouldn't have access to. Cross-user retrieval attacks, access control bypass in the retrieval layer, and metadata leakage are the most common findings. We also test whether system prompt contents are extractable via retrieval manipulation.
We review how API keys, model provider credentials, and integration secrets are handled, in code, in environment configuration, in prompts, and in logs. Keys hardcoded in system prompts, logged in request/response logging, or exposed through error messages are common findings that we see regularly in production AI systems.
We test whether your output filtering or guardrail layer can be bypassed, encoding tricks, indirect elicitation, format manipulation, and multi-step reasoning attacks that produce disallowed outputs through an intermediary step. We also assess whether the filtering is over-broad in ways that create false positives.
For fine-tuned or instruction-tuned models, we test for training data memorisation, whether the model can be prompted to reproduce verbatim training examples that include sensitive information. For RAG systems, we test whether the knowledge base contents can be systematically extracted through repeated targeted queries.
Three deliverables. Every finding is confirmed and reproducible.
Every confirmed vulnerability documented with CVSSv3 severity rating, attack description, conditions required for exploitation, and potential business impact. Structured so your engineering team can prioritise remediation by risk.
For every confirmed vulnerability, a reproducible proof-of-concept, the exact input, the exact output, and the steps to reproduce. Not a theoretical risk description. A demonstration that it works against your actual system.
Specific, actionable remediation for each finding, not 'implement input validation' but the specific validation logic required, the specific prompt changes needed, or the specific architectural change that closes the vulnerability.
The audit has a specific scope and a specific point in the development cycle where it's most valuable.
AI systems still in early development with no production traffic
Security testing is most valuable on systems that are close to production or already in production. Early-development systems change too quickly for an audit to have lasting value. Come back when the architecture is stable and you're within 4–6 weeks of launch.
Teams who want the report but won't remediate
A vulnerability report without remediation is a liability. If your organisation doesn't have the engineering capacity or appetite to address the findings, the audit surfaces risk without reducing it. We can scope remediation work as a follow-on engagement, but the audit is only valuable if findings will be acted on.
General application security audits
This audit covers AI-specific attack surfaces: prompt injection, retrieval attacks, model behaviour exploitation. It does not replace a general application penetration test covering your web application, infrastructure, and non-AI APIs. If you need both, we can scope both.