Penetration testing for AI companies
When your product is AI, your product is the attack surface. Penetration testing for AI companies covers the model endpoints, the agents and tools they reach, and the retrieval pipelines behind them, alongside the conventional application surface, so an attacker cannot make your own system work against you.
What breaks when the product is a model
AI products carry a class of exposure conventional testing misses, because the system reads untrusted content and acts on it.
Content becomes command
Direct and indirect injection through every channel the model reads, turning documents, pages, and tool output into instructions your system follows.
Actions, not just answers
Agents that call tools, browse, or reach internal APIs, and the excessive agency that turns an injection into a real action against your systems.
Retrieval and exfiltration
Poisoning the corpus, cross tenant reads in the vector store, and data leaving through model output, alongside the model endpoints themselves.
- Prompt injection through every ingestion channel.
- Tool and function abuse across every capability the agent holds.
- RAG poisoning and cross tenant reads in the vector store.
- The surrounding app and API tested in the same run.
Adversarial testing for a system that acts
Model backed features ship in weeks, and the security discipline around them is still being written. Operator tests them the way an adversarial user would, mapped to the OWASP Top 10 for LLM Applications and extended to the tools, retrieval, and APIs your agents reach.
It covers the conventional application and API surface in the same engagement, because some of the highest impact findings are classic flaws the model can be made to reach.
When a customer-facing agent can call an admin-only tool
AI companies wire agents to internal tools fast, and the check that a caller is allowed to invoke a specific tool is often the one nobody wrote.
- Authenticated as a standard user account with no administrative role assigned.
- Sent
POST /api/v1/agents/{agentId}/tools/invokenaming the toolexport_customer_list, an action the UI restricts to admins. - Received a
200 OKcarrying a generated export of the full customer list. - Repeated the call from a second standard user account and reached the same export, confirming a missing check rather than a one-off fluke.
POST /api/v1/agents/agt_4471/tools/invoke HTTP/1.1
Host: api.example.com
Authorization: Bearer <STANDARD_USER_TOKEN>
Content-Type: application/json
{"tool": "export_customer_list", "arguments": {}}
HTTP/1.1 200 OK
Content-Type: application/json
{"export_id": "exp_50713", "row_count": 8214, "download_url": "https://api.example.com/exports/exp_50713.csv"}
curl -s -X POST https://api.example.com/api/v1/agents/agt_4471/tools/invoke \
-H "Authorization: Bearer <STANDARD_USER_TOKEN>" \
-H "Content-Type: application/json" \
-d '{"tool":"export_customer_list","arguments":{}}'
The gap echoes what OWASP guidance on agentic and MCP-style tool use flags as a leading cause of unintended agent actions: an endpoint that checks who is calling, but not which tools that caller is allowed to reach.
This is the class of gap Operator checks on every agentic surface it is pointed at, not only the API layer beneath an agent but the tool-invocation layer the agent itself exposes. Operator authenticates as each role your system defines, enumerates the tools an agent can reach, and then tries invoking every tool from every role, watching for the response a standard account was never supposed to receive. When a call like this succeeds, the finding above is what reaches you: the exact request, the response that proves it, and a CVSS vector you can recompute rather than take on faith. It is the same discipline Operator applies to function-level authorization across a conventional REST API, extended to cover the tools an agent can invoke on a caller's behalf, the pattern MCP and tool-calling security testing is built around. Every result carries the same evidence bar described on the Proof page: reproduced twice against your live target, with the request and response attached, or it is never shown to you at all.
Illustrative example, not a specific customer result.
Common questions
Why do AI companies need specialized penetration testing?
Because your product is the attack surface. An AI company ships models, agents, and RAG pipelines that read untrusted content and take actions, a class of risk conventional test plans were not written for. Testing has to cover prompt injection, tool abuse, and data exfiltration alongside the usual application surface.
What does penetration testing for AI companies cover?
The model endpoints, the agents and tools they can reach, the retrieval pipelines and vector stores, and the application around them. It covers the OWASP Top 10 for LLM Applications plus the agentic risks of a system that acts.
Is this different from testing a normal application?
Yes. A normal test asks what an attacker can read or change. For an AI product, it also asks what an attacker can make your model or agent do: invoke tools, leak other users' context, or act on injected instructions. That requires adversarial, AI native testing.
Not an AI company, or need coverage for another sector too? See API penetration testing by industry.
Test what your model can be talked into
Describe your AI product and the tools it can reach, and we will show you what an attacker can make it do.