Shipping a feature built on an LLM opens a class of risk that a traditional web pentest doesn’t cover. A model can be talked into ignoring its instructions, coaxed into leaking data it was given, or handed tools it uses to act on your systems. We test the AI features you’re building the way an attacker actually would, and map what we find to the OWASP LLM Top 10 so your team has a shared language for the fixes.
What we test
- Prompt injection. Direct and indirect, including payloads hidden in documents, web pages, or tool responses that the model later reads.
- Sensitive data disclosure. Whether the model can be led to reveal system prompts, other users’ data, or content from your retrieval store.
- Insecure tool and agent use. Excessive agency: what an agent can be tricked into doing when it can call tools, run code, or touch your APIs.
- RAG and data-poisoning risks. Whether poisoned or attacker-controlled content in your knowledge base changes the model’s behavior.
- Insecure output handling. Model output that flows unescaped into a browser, a shell, or a database and causes classic injection downstream.
- Cost and denial of wallet. Prompts that drive runaway token usage or expensive tool loops.
How it runs
We scope against your actual application, not a generic model. You give us access to the feature and a description of what it’s allowed to do, and we test it end to end, including the guardrails you’ve put in place. Everything is scoped and authorized in advance, and we don’t train on or retain your data.
What you get
- A findings report mapped to the OWASP LLM Top 10, ranked by real impact
- Concrete, developer-ready fixes: input handling, system-prompt hardening, tool-permission scoping, and output validation
- A retest of the fixes, and a plain-language briefing for the non-AI people who still have to sign off on the risk
This pairs naturally with a standard penetration test: the LLM feature is one surface, and the app around it still needs the usual coverage.