Security teams often use familiar words for unfamiliar systems. A buyer may ask whether your AI product has a “penetration test,” while your team may be thinking about LLM red teaming, RAG leakage, agent tool abuse, or evals. Those are related, but they are not the same engagement.
The practical answer is not to argue over labels. It is to define the surface, the attacker position, the evidence standard, and the retest path. A credible AI security review should be clear enough that a buyer can see exactly what was tested and what was not.
The short version
| Engagement | Primary question | Typical evidence |
|---|---|---|
| Penetration test | Can an attacker exploit the application, API, cloud, auth, network, or infrastructure? | Vulnerability findings, reproduction steps, affected endpoints, screenshots or requests, severity, remediation. |
| LLM red team | Can adversarial input make the AI system ignore instructions, leak data, misuse tools, or produce unsafe output? | Prompts, model turns, request traces, retrieved context, tool calls, framework mapping, fix and retest status. |
| AI security assessment | Does the full AI product hold up across appsec, model behavior, RAG, agents, evals, tenant isolation, and production controls? | System map, threat model, AI red-team findings, eval baseline, production-readiness gaps, fix plan, and retest evidence. |
If your product is a normal SaaS app with one small AI feature, a standard penetration test plus a focused LLM red-teaming service may be enough. If AI is core to what you sell, use a broader AI Product Readiness Assessment.
What a penetration test covers
A penetration test is strongest at the traditional software boundary. It asks whether a user or attacker can break authentication, authorization, session handling, APIs, infrastructure, file upload, secrets handling, cloud configuration, or common injection surfaces.
For an AI product, that still matters. A prompt-injection finding is less interesting if the API itself lets one tenant read another tenant’s data. A model cannot compensate for broken auth. A buyer may still expect appsec evidence before they trust the rest of the report.
But a standard penetration test often treats the AI feature as an endpoint, not as a decision system. It may test whether /api/chat is authenticated, but miss whether retrieved content can override policy, whether a tool call is over-broad, or whether an eval gate can be bypassed.
What AI red teaming covers
AI red teaming tests the parts that normal appsec scopes often miss:
- Prompt injection. Direct user instructions and indirect instructions inside retrieved content, documents, tickets, emails, pages, or tool output.
- Sensitive information disclosure. System prompt leakage, cross-tenant data exposure, hidden context disclosure, or model/provider internals leaking through errors.
- RAG abuse. Retrieval poisoning, missing metadata filters, citation manipulation, and context assembly that crosses a user or tenant boundary.
- Agent and tool abuse. The model calling tools the user should not be able to trigger, skipping confirmation, or acting with a service identity instead of the caller’s authority.
- Output integrity. Structured output, citations, markdown, links, generated code, and downstream workflows trusting text that should be treated as untrusted.
- Evals and regression. Whether a fix can be proven and kept fixed after a model, prompt, retrieval, or tool change.
The evidence is different too. A useful AI finding is not just a screenshot of a strange model answer. It should include the input, relevant request and response trace, retrieved context or tool call when applicable, impact, fix, and retest result.
What an AI security assessment adds
An AI security assessment combines the AI-specific work with the production context around it. The useful scope usually includes:
- Auth and tenant boundaries around AI endpoints.
- The model provider, prompt chain, and context assembly.
- Retrieval sources, vector indexes, permissions, and citations.
- Agent tools, MCP servers, approval gates, memory, and audit traces.
- Rate limits, cost controls, logging, monitoring, and incident reconstruction.
- Evals, release gates, and regression tests for confirmed failures.
That is why the report should read differently from a classic penetration-test report. It should show a system map, AI threat model, tested surfaces, findings with traces, eval evidence, fix plan, retest status, and residual risk. See what enterprise buyers expect in an AI security assessment report and the sample AI assessment report for the shape.
How to choose the right scope
Use this decision path:
- If the buyer explicitly requires an annual web or infrastructure pentest, run that scope and keep the report precise.
- If the buyer asks about AI behavior, prompt injection, model safety, RAG, agents, tools, evals, or tenant isolation, add AI red teaming or a broader AI security assessment.
- If AI is the core product, do not rely on a standard pentest alone. The model, retrieval layer, tool surface, and release process are part of the product boundary.
- If the deadline is a customer security review, package the result around buyer evidence: scope, findings, fixes, retest status, and what remains out of scope.
For most AI-native startups, the right first artifact is the AI Product Readiness Assessment. If the risk is narrower, choose the focused LLM red-teaming service, RAG security assessment, AI agent security assessment, or MCP security assessment.
What to tell a buyer
Clear language works better than a label fight. A useful buyer response looks like this:
We have scoped an AI security assessment covering the AI product surface: application auth around AI endpoints, prompt injection, RAG retrieval controls, agent/tool permissions, eval readiness, findings, fixes, and retest status. Where traditional appsec coverage is needed, we name that scope separately.
The key is not whether the document says “pentest” or “red-team” on the cover. The key is whether the scope matches the risk the buyer is trying to evaluate.
Common mistakes
- Calling a model benchmark a red team. A benchmark score does not prove your product’s retrieval, tools, auth, tenant boundaries, or release gates hold.
- Using a standard pentest as AI assurance. It may prove the API boundary but still miss model-mediated data leakage or tool abuse.
- Publishing a pass/fail stamp without scope. Buyers need the boundary and residual risk, not a magic status.
- Fixing prompt wording without retest. Prompt changes can help, but the report should prove that the original reproduction path no longer works.
- Ignoring production controls. Cost limits, logging, rollback, and incident reconstruction are part of AI readiness, not operations trivia.
The evidence standard
Whatever you call the engagement, the standard should be the same: reproducible evidence and honest scope. The report should let an engineer rerun the issue, let a buyer understand the risk, and let both sides see what was fixed.
That is the standard Phixe applies in the AI Product Readiness Assessment. For a buyer-facing deadline, use the enterprise procurement review. For a narrower model-behavior question, start with LLM red teaming.