AI penetration testing
We test the AI systems you've shipped — assistants, RAG applications, and model-backed features — for injection, retrieval data exposure, and output-handling flaws that turn your model into someone else's tool.
When you need this
You shipped an LLM feature to production and the only security review it got was a policy document, not a test.
A customer is asking for a penetration test report that covers your AI features specifically, and the last application test you ran scoped the model and its data out.
Your assistant retrieves from a knowledge base that spans multiple customers, and nobody has proved one tenant can't pull another tenant's documents.
Model output ends up somewhere nobody planned for it — rendered in a customer-facing page, written into a ticket, passed to a query builder or a shell — and nothing downstream treats it as untrusted.
What we do
01
Injection, direct and indirect
Direct testing covers instruction override, role and delimiter confusion, and obfuscated payloads — base64, homoglyphs, and invisible Unicode tag characters that survive a filter and reach the model intact. Indirect testing is the part most teams skip: we plant payloads in the content your system actually reads — support tickets, uploaded PDFs, crawled pages, HTML comments, image alt text, document metadata — and see what the model does when the instruction arrives from a source it treats as data. This is LLM01 Prompt Injection in the OWASP Top 10 for LLM Applications and AML.T0051 LLM Prompt Injection in MITRE ATLAS, which carries direct and indirect as separate sub-techniques — and the indirect one is where the real impact usually sits.
02
Retrieval is an access-control boundary
Most RAG applications enforce authorization on the request and then let the retriever run unscoped. We test whether entitlements are applied at retrieval time or bolted on as a post-hoc filter, whether metadata filters can be influenced by user input, and whether namespace or collection isolation actually separates tenants in pgvector, OpenSearch k-NN, Bedrock Knowledge Bases, or Vertex AI Vector Search. We also chase the quieter failures: chunks that outlive a revoked permission, documents re-indexed without their source ACLs, and leakage at the embedding layer — LLM08, Vector and Embedding Weaknesses.
03
Model output becomes code somewhere downstream
Improper output handling (LLM05) is where a language problem turns into a classic web vulnerability. We test model output rendered as HTML or Markdown for stored XSS and for image-tag exfiltration, where a crafted URL carries conversation contents to an attacker on render. Where the application fetches URLs the model chose, we test for SSRF into internal services and cloud metadata endpoints; where output reaches a query builder, shell, or template engine, we test for injection there. Alongside this we work on system-prompt leakage (LLM07) — extracting the prompt, then reporting what was in it that should never have been there, such as keys, endpoints, or pricing logic.
04
Limits, cost, and the tool schema
Unbounded consumption (LLM10) is tested as an availability and billing problem: token amplification through crafted inputs, recursive tool loops, long-context cost attacks, and missing per-tenant rate and spend ceilings. On the tool and function schemas — the former plugin category, now folded into LLM06 Excessive Agency — we look for free-form string parameters passed to interpreters, missing allowlists on destinations and actions, tool descriptions that are themselves injectable, and calls executed with the application's identity rather than the requesting user's.
What you receive
- Working payloads and full transcripts for every confirmed finding — the exact input, the model's response, and the downstream effect
- Retrieval evidence for tenant-isolation findings: which identity ran which query and which documents came back
- Each finding mapped to the OWASP Top 10 for LLM Applications (2025) and to MITRE ATLAS technique IDs, so it lands in the risk register you already run
- Remediation written at the layer that holds — retrieval-time authorization, output encoding, tool schema constraints, quotas — rather than a longer system prompt
- A regression suite of the payloads that worked, packaged to run in your CI so the next model or prompt change is re-tested against them
- A plain-language summary of what was in scope, what we got the system to do, and what we tried without success — written so you can reuse it in customer security reviews without overstating it
How it runs
Scope
days
Walkthrough of the AI feature, data sources, tools, and tenancy model. Test accounts and content-planting boundaries agreed, fixed price set.
Test
1–3 weeks
Payload corpora run at scale through our own harnesses and promptfoo, with an intercepting proxy on the API and rendering path; the engineer on the engagement then builds the chains that matter and verifies every hit by hand.
Report
days
Findings, transcripts, framework mapping, and remediation written by the engineer who found them.
Retest
included
We rerun the payload set against your fixes and update each finding's status.
Durations are indicative. Actual scope and price are fixed after the scoping call.
Questions we get asked
- Does "AI penetration testing" mean testing our AI, or using AI to test us?
- The term gets used both ways, and search results mix them freely. This page is the first meaning: we test AI systems you have built or deployed. The second is how we deliver — automation handles enumeration, payload generation, and first-pass triage on every engagement, which is what keeps the timeline in weeks. If you meant an AI-accelerated test of your cloud or application estate, that's our cloud penetration testing work.
- How do you report a finding when the model answers differently every time?
- A payload becomes a finding when it reproduces, so each one records the model and version, the parameters, how many attempts we made, and how many landed. An attack that works one time in twenty is still a finding and is reported as one in twenty, not as a yes. Anything we triggered once and could never repeat is written up as unconfirmed with the full transcript, and you can judge it yourself. If what you actually want is a measured bypass rate per control layer across a large corpus, that is a red team exercise rather than a penetration test, and we'll point you at it instead of stretching this engagement to fit.
- Do you test the model itself, or just the application around it?
- The application, its retrieval layer, its tools, and its cloud plumbing. We don't do weight extraction, training-data reconstruction, or fine-tuning attacks against a hosted foundation model — that is research work, it usually breaches the provider's terms, and paying us for it would not change your risk. If you train, fine-tune, or self-host your own models, data poisoning and model supply chain come into scope and we'll say so during scoping.
- Will testing pollute our knowledge base or run up our model bill?
- Indirect injection testing needs content planted where the system will retrieve it, so we agree the locations first, tag every injected document with a canary string, and remove them at the end. Consumption testing runs against an agreed request and spend ceiling that you set. If a finding can only be proven by exceeding it, we describe the path and let you decide.