AI & LLM Penetration Testing
AI penetration testing is manual, human-led security testing of AI systems: LLM applications, RAG pipelines, AI agents and model APIs. It is distinct from autonomous AI pentesting, where AI agents run the test. Here, human testers test your AI, looking for prompt injection, sensitive data disclosure, insecure tool calling and guardrail bypass, assessed against the OWASP LLM Top 10 and MITRE ATLAS.
You shipped an AI feature and someone asked whether it is secure. We test the AI you build: LLM applications, RAG pipelines and agents, by hand, against the OWASP LLM Top 10.
What is AI penetration testing?
AI penetration testing is manual, human-led security testing of AI systems: LLM applications, RAG pipelines, AI agents and model APIs. It is distinct from autonomous AI pentesting, where AI agents run the test. Here, human testers test your AI.
- Prompt injection, both direct and delivered through retrieved content
- Sensitive information and system prompt disclosure
- Insecure tool calling, excessive agency and agent abuse
- Guardrail and safety-filter bypass
- Assessed against the OWASP LLM Top 10 and MITRE ATLAS
AI agents performing testing against conventional networks and applications, at machine speed.
- The AI is the tester
- Tests your network and web apps
- Sold as a platform or tool
Human testers testing the AI system you built or deployed, for weaknesses unique to how models behave.
- The AI is the target
- Tests your LLM apps, RAG and agents
- Delivered as a consultant-led engagement
Scanners do not do multi-turn manipulation
Most of what is sold as AI security testing is a prompt library fired at an endpoint. That finds the obvious cases. It does not find the flaw that only appears on the fourth turn of a conversation, once the model has been led somewhere it should not go, or the one that needs a poisoned document planted in the retrieval index three steps earlier.
This service is delivered by the same testers who run our web application and infrastructure engagements, applying the same manual methodology to a newer target. That team holds CREST accreditation for our core penetration testing, vulnerability assessment and SOC services.
On accreditation, plainly
There is no CREST scheme for AI testing today. Our CREST accreditation covers our core penetration testing, vulnerability assessment and SOC services. We apply that accredited manual methodology to AI systems, and we would rather say so than imply a certification that does not exist.
The AI attack surface
An AI feature is rarely just a model. It is a model, the data you feed it, the tools you let it call, and the guardrails you hope will hold.
Chatbots, copilots and assistants
The application layer where most real risk sits. We probe the system prompt, the guardrails and the boundary between user input and instruction, including direct and indirect prompt injection testing.
Retrieval, vector stores and context
Retrieval-augmented generation widens the attack surface to everything the model can read. We test for poisoned documents, cross-tenant retrieval, and whether embedding search can be steered to leak records the user should never see.
Tool calling, MCP and autonomy
AI agent security starts where a model can act, not just answer. We test for tool poisoning, tool shadowing, confused-deputy abuse of the agent's own credentials, memory and context poisoning, and one tool's output influencing another.
Endpoints, keys and quotas
The plumbing behind the model. Authentication and authorisation on inference endpoints, key handling, tenant isolation, and unbounded consumption that turns a prompt into a bill or an outage.
Filters, system prompts and policy
LLM security depends on guardrails holding, so we test them like the controls they are. We attempt bypass through encoding, obfuscation, role-play framing and multi-turn manipulation, and we check what leaks when they fail.
Models, plugins and dependencies
Third-party models, adapters, plugins and datasets inherit their suppliers' risk. We review provenance, integrity and the trust you extend to components you did not build.
Tested against the OWASP LLM Top 10
The OWASP Top 10 for LLM Applications (2025) is the recognised list of critical risks in language model applications. It is a different list from the classic OWASP Top 10 for web applications, and we work through it deliberately.
Prompt Injection
Direct and indirect injection that overrides intended instructions, including payloads delivered through retrieved documents and tool output.
Sensitive Information Disclosure
Extraction of personal data, credentials, proprietary content or other users’ data through the model.
Supply Chain
Risk inherited from third-party models, adapters, plugins, datasets and the pipelines that deliver them.
Data and Model Poisoning
Testing for the symptoms of poisoned training or retrieval data, such as backdoor triggers and steered behaviour. Depth here depends on the access you can grant to the training and retrieval pipeline.
Improper Output Handling
Where model output reaches a browser, shell, database or downstream system without validation, producing XSS, SSRF or injection.
Excessive Agency
Permissions, tools and autonomy beyond what the task needs, so a manipulated model can take consequential action.
System Prompt Leakage
Recovery of system prompts, hidden instructions and the secrets teams mistakenly place in them.
Vector and Embedding Weaknesses
Attacks on the retrieval layer: embedding inversion, index poisoning and cross-tenant leakage in shared stores.
Misinformation
Fabricated or manipulated output that users and downstream systems treat as authoritative.
Unbounded Consumption
Resource and cost exhaustion, denial of wallet, and extraction of model behaviour through high-volume querying.
Agent-heavy systems are additionally assessed against emerging Model Context Protocol guidance, covering tool poisoning, tool shadowing, confused-deputy privilege abuse, and memory poisoning across turns.
AI governance: the technical assurance evidence
AI governance frameworks ask organisations to show that AI systems have been assessed for security risk. An AI security assessment produces that evidence. A penetration test report is one of the clearest ways to evidence it. We provide the assessment and the report. Certification is issued by your auditor, not by us.
Our approach is aligned with NCSC guidance on AI security principles. There is no formal NCSC testing standard for AI systems, so we do not claim one.
AI red teaming: what an adversary with a goal can make your model do
Penetration testing works through a taxonomy and tells you what is broken. AI red teaming starts from an objective and pursues it: recover the system prompt, get the agent to call a tool it should refuse, extract another tenant's data, drive the model outside its stated policy. LLM red teaming and AI penetration testing answer different questions, and larger AI deployments usually want both.
Goal-directed campaigns use multi-turn manipulation, role-play framing, encoding and obfuscation, and indirect injection planted in content the model will later retrieve.
How the engagement runs
Model output is non-deterministic
The same prompt does not always produce the same answer, so AI findings are not reported like a web application finding. We record the exact prompt, the conditions, and how reliably the behaviour reproduces, so your engineers can verify it rather than argue with it.
What we need from you
- A staging or sandbox environment, not production
- An architecture diagram of the retrieval and agent chain
- Scoped credentials or API keys
- A decision on black-box, or system prompt disclosed
An AI feature is still an application
Most AI systems sit on a web application, an API and a cloud account. Testing the model without testing what it runs on leaves the easier path open.
The best time to test your defences is now.
Join the high-growth companies relying on Precursor for continuous offensive and defensive security.
Frequently Asked Questions
Common questions about this service, methodologies, and deliverables.
AI penetration testing is manual, human-led security testing of AI systems such as LLM applications, RAG pipelines, AI agents and model APIs. It looks for AI-specific weaknesses including prompt injection, sensitive information disclosure, insecure tool calling and guardrail bypass, and is typically assessed against the OWASP LLM Top 10 and MITRE ATLAS.
No, and the two are routinely confused because both are marketed as "AI pentesting". Autonomous or AI-powered pentesting means AI agents performing testing against conventional networks and applications. AI penetration testing, as described on this page, means human testers testing an AI system that you built or deployed. We do the second.
The OWASP Top 10 for LLM Applications is the recognised industry list of the most critical security risks in large language model applications. The current 2025 release covers prompt injection, sensitive information disclosure, supply chain, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation, and unbounded consumption. It is a different list from the classic OWASP Top 10 for web applications.
They answer different questions rather than being a hierarchy. AI penetration testing works systematically through a taxonomy such as the OWASP LLM Top 10 to find and rate exploitable weaknesses. AI red teaming is goal-directed and adversarial: we are given an objective, such as making the system reveal its system prompt or act outside its policy, and we pursue it the way a motivated attacker would.
Both ISO/IEC 42001 and the EU AI Act expect organisations to evidence that AI systems have been assessed for security and safety risk, and customer security questionnaires increasingly ask the same. A penetration test report is one of the clearest forms of that evidence. We provide the technical assessment and the report. We do not issue certification, and your auditor or legal counsel determines what satisfies your specific obligations.
LLM applications and chatbots, RAG pipelines and vector stores, AI agents including tool calling and MCP integrations, model APIs and inference endpoints, and the guardrails and system prompts around them. We also review the supply chain of third-party models, plugins and datasets your system depends on.
Typically a staging or sandbox environment rather than production, because model behaviour is non-deterministic and testing can trigger cost and rate limits. Beyond that: an architecture diagram covering the retrieval and agent chain, scoped credentials or API keys, a decision on whether we test black-box or with the system prompt and guardrail configuration disclosed, and a contact for your model provider’s acceptable-use and rate-limit policies.
AI engagements vary more than standard penetration tests, because scope depends on the number of models, agents and integrations rather than a count of IP addresses or application roles. Scope and a fixed price are agreed after a free scoping call, so you are not quoted against assumptions. Scope is driven by the number of models, agents, integrations and retrieval sources in play, which we establish on the call before any number is quoted.