What breaks when organisations test AI features with a standard web application pentest only?

What a normal web pentest sees, and what it misses

A standard web application pentest is built to find flaws in request handling, session logic, input validation, authorization, and common server-side weaknesses. That is useful, but it is not enough for AI features. Once a product includes a model, the question is no longer only “can a web request be abused?” It becomes “can content reshape the model’s behavior, context, or downstream actions?”

That difference matters because many AI failures are interaction failures, not classic web vulnerabilities. A tester focused on HTTP endpoints may validate the portal, but still miss how the model interprets instructions embedded in user content, retrieved content, or external inputs. For a baseline appsec view, OWASP Top 10 remains the right starting point, but it does not by itself cover prompt-driven attack paths.

AI features also behave differently once they are connected to search, email, ticketing, code execution, or internal tools. A web pentest can prove a button works or an endpoint rejects malformed input, yet still fail to evaluate whether the model can be manipulated into disclosing context, taking an unsafe action, or amplifying untrusted content into a trusted workflow. That is why “passes pentest” is not the same as “safe to deploy.”

Why prompt injection and agent misuse fall outside the usual test model

Prompt injection and indirect prompt injection are not just alternate forms of XSS or command injection. They exploit the model’s treatment of instructions and context, which means the attack surface depends on prompts, retrieval, tool use, and policy boundaries. If the test plan does not include those behaviors, it will under-sample the real risk. A web security testing guide helps structure web and API checks, but AI-specific abuse paths need their own scenarios.

Agent misuse is even more likely to be missed when the AI is allowed to take actions on the user’s behalf. In that case, the security question is not only whether the model answers correctly, but whether it can be steered into sending data, changing records, invoking tools, or chaining actions that the human did not intend. That is a different trust boundary from ordinary page testing.

When AI features are exposed through APIs, the underlying web surface can still be part of the problem. Broken authentication, overbroad access, or poor object-level authorization can make the AI feature easier to abuse, but the model layer adds another decision point. For API-facing AI systems, OWASP ASVS is useful for the web and API controls, while the AI interaction layer still needs dedicated abuse-case testing.

If the AI feature depends on retrieved content or third-party data, the tester should treat untrusted text as a potential control input, not just a payload. That is where indirect prompt injection often hides: the dangerous instruction is carried in a page, document, email, or ticket that the model later reads as context.

What becomes false confidence when the AI can trigger actions

The biggest failure is assuming that a clean pentest result means the AI is safe to trust. If model output can trigger downstream actions, the blast radius is determined by tool permissions, workflow design, and business logic, not just by the frontend. A well-behaved chat experience can still become a harmful control plane if the model can reach sensitive systems without strong guardrails.

That is why control frameworks for AI and agentic systems matter. Where the product includes autonomous or semi-autonomous behavior, OWASP Agentic AI Top 10 is directly relevant because it treats identity, privilege, tool misuse, and agent-specific abuse as first-class security concerns rather than side effects.

The same issue applies to secrets and credentials. If the AI can see tokens, keys, or internal context, then compromise may not look like a classic web exploit at all. It may look like a model being induced to reveal data, call a tool, or act with more authority than intended. Teams that want deeper coverage should also assess the AI feature’s non-human access patterns, especially where service credentials or delegated tool access are involved.

From an operational standpoint, this means the test plan must include adversarial prompts, context poisoning, tool-abuse scenarios, and post-output impact checks. A pentest that stops at response codes and page rendering will miss the most important question: what can the AI be made to do after it has already accepted the input?

Practitioner Guidance

What to verify: Test the model’s instruction hierarchy, retrieval boundaries, and tool permissions separately from the web app’s ordinary security controls. A finding only counts as “covered” when the team has shown how the AI behaves under malicious or untrusted context, not just when the page accepts or rejects input.

What to prioritize: Start with the paths that can create real business impact, especially data disclosure and unsafe actions. If an AI feature can write, send, approve, delete, or retrieve on behalf of a user, validate those paths before spending time on lower-impact content issues.

Common mistake: Treating a pentest report as proof that the AI feature is production-ready. The web layer may be hardening correctly while the model layer remains vulnerable to prompt injection, indirect prompt injection, or unsafe tool use.

Practitioner takeaway: Security testing for AI must evaluate behavior, context, and delegated action, not just endpoints. If the model can influence data, tools, or decisions, a standard pentest is necessary but insufficient.

Related resources from NHI Mgmt Group

• What breaks when organisations do not test inference risk in AI systems?
• What breaks when organisations rely on standard DLP controls instead of MCP-layer inspection for AI agent tool calls?
• What breaks when organisations do not inspect non-visible content in emails, PDFs, and web pages before AI systems process them?
• What breaks when organisations rely on static web-era assumptions in modern AI and blockchain environments?