Should organisations treat AI-specific testing separately from standard AppSec testing?

Why AI Testing Should Not Be Folded into Standard AppSec by Default

Standard application security testing is necessary, but it is only one layer of assurance. It is good at finding traditional code defects, unsafe dependencies, exposed endpoints, and common web risks. It is not designed to tell you whether a model has been poisoned, whether an agent is overstepping its authority, or whether the system behaves safely when prompts, tools, and memory are manipulated.

The practical split is between testing the software artefacts around the AI and testing the AI behaviour itself. The first looks like conventional AppSec and secure SDLC work. The second checks whether the model, orchestration layer, and tool chain still behave acceptably when the system is stressed, redirected, or tricked into producing harmful actions.

That distinction matters because many AI failures are not syntax or dependency failures. They are control failures at runtime, where the application is technically secure enough to pass ordinary checks but the AI layer still makes unsafe decisions. A team can have strong scanner coverage and still miss prompt injection, harmful tool invocation, or a model that leaks sensitive context under adversarial input.

What AI-Specific Testing Needs to Cover

AI-specific testing should focus on the behaviours that standard scanners usually do not exercise. That includes model poisoning resistance, prompt injection resilience, tool-use boundaries, output safety, memory contamination, and whether the system can be induced to exceed its intended authority. OWASP Agentic Applications Top 10 is a useful reference point when the application behaves like an agent or uses tools in ways that create new attack surface.

Testing also needs to reflect the full control path, not just the model prompt. A seemingly safe model can become risky once it is connected to retrieval, plugins, APIs, or workflow automation. That is why red teaming for privilege abuse and delegation abuse is often more revealing than static inspection alone. Red Teaming AI Agents for Identity Abuse is relevant when you need to test whether the system can be pushed into using credentials, approvals, or delegated access in unintended ways.

For organisations still building their baseline, it helps to keep the AI test plan tied to the exact deployment pattern. A chat feature, a retrieval-augmented assistant, and a tool-using agent have different failure modes, even if they sit in the same product. Agent Identity Standards Tracker is useful where the AI system participates in cross-system identity, token, or trust relationships that must be validated as part of testing.

How to Integrate AI Testing Without Diluting AppSec

The best model is not either-or. Treat AI testing as a parallel stream that shares inputs with AppSec, then diverges where runtime behaviour becomes the question. Use AppSec to verify the application shell, interfaces, sessions, secrets, and dependencies. Use AI-specific testing to verify whether the model and its orchestration layer stay within policy when facing adversarial prompts, malformed context, or unsafe tool requests.

That separation prevents a common mistake: assuming that a clean scan means the system is safe to deploy. A model can pass conventional security checks and still be exploitable through behaviour. The right gate is whether the AI component has been exercised against realistic misuse cases, including attempts to bypass instructions, induce data leakage, or trigger actions beyond intended scope. Standard verification still matters, but it should be complemented by scenario-based testing that targets AI failure modes directly. OWASP ASVS remains a strong baseline for the non-AI parts of the application.

Teams should also decide which findings belong in release gates and which belong in ongoing monitoring. Some AI weaknesses are product-defining and must block launch, especially unsafe tool execution and uncontrolled access to sensitive data. Others may be accepted temporarily if the system is isolated, monitored, and narrowly scoped. The key is to make that distinction explicit, rather than letting AI risk disappear inside a generic AppSec checklist. OWASP SAMM is helpful for embedding that discipline into the software delivery process.

Practitioner Guidance

What to prioritise: Put AI-specific tests on the same release path as AppSec tests, but require separate pass criteria for model behaviour, tool use, and unsafe delegation. If the system can take action, not just generate text, its behaviour must be tested as an operational control, not only as code.

What to verify: Verify the exact attack surface created by retrieval, tools, memory, and external integrations. The question is not whether the model is “secure” in general, but whether it can be induced to cross a boundary that the business assumes is protected.

Common mistake: Teams often over-trust scanner coverage and under-test the live interaction between prompt, policy, tool, and output. The most important failure is usually not a missing library check, it is an unsafe action path that looks legitimate to the application.

Practitioner takeaway: Use AppSec to prove the software is built safely, and AI-specific testing to prove the AI behaves safely under pressure. When the system can influence decisions or trigger actions, both layers are required before you can call the release ready.

Related resources from NHI Mgmt Group

• When should organisations prioritise AI-specific controls over generic appsec checks?
• Should organisations treat agentic AI testing tools as governed software components?
• Should organisations treat agentic AI separately from insider-risk programs?
• Should organisations treat AI pen testing as a point-in-time or continuous control?