How can organisations decide between traditional and agent-aware testing?

Use traditional red teaming for perimeter, infrastructure, APIs, and classic application paths. Use agent-aware testing when the system plans, calls tools, retrieves data, or writes to memory. Most programmes need both, but the agentic layer requires its own governance, evidence, and remediation workflow.

Why This Matters for Security Teams

Choosing the wrong testing approach creates blind spots. Traditional red teaming is still essential for perimeter controls, identity boundaries, APIs, and application flaws, but it does not fully exercise systems that can plan, retrieve, call tools, or persist state. For those workflows, agent-aware testing helps expose prompt injection, tool abuse, overbroad permissions, unsafe memory writes, and goal hijacking. That distinction is central to current guidance such as the NIST AI Risk Management Framework, which treats AI risk as a lifecycle issue rather than a single security review.

The practical mistake is assuming a model that passes classic application testing is therefore safe to deploy as an autonomous or semi-autonomous agent. In reality, agent behaviour emerges from the combination of model output, orchestration logic, tools, data sources, and human approval gates. If testing only covers the model prompt and response path, the organisation may miss the real attack surface: delegated actions. In practice, many security teams encounter agent abuse only after a tool invocation or data exfiltration path has already been exercised in production, rather than through intentional pre-release validation.

How It Works in Practice

Most programmes should start by classifying the system. If it is a conventional web app with a chatbot front end, traditional testing may cover most of the risk. If it can browse, execute actions, write tickets, send messages, trigger workflows, or update memory, agent-aware testing becomes mandatory. That approach aligns with the threat patterns described in the OWASP Top 10 for Agentic Applications 2026 and the attack techniques catalogued in the MITRE ATLAS adversarial AI threat matrix.

Operationally, the split usually looks like this:

• Use traditional testing for network exposure, authentication, session handling, input validation, API abuse, and privilege escalation.
• Use agent-aware testing for prompt injection, unsafe tool execution, hidden instructions in retrieved content, memory poisoning, and multi-step abuse chains.
• Test governance paths as well as technical paths, including approval gates, audit logs, escalation rules, and rollback procedures.
• Validate the behaviour of connected data sources and tools, not just the LLM, because an agent often becomes dangerous through a trusted integration.

Good programmes also define evidence requirements up front. That means capturing prompts, tool calls, retrieval results, policy decisions, and remediation owners so that findings can be repeated and closed out. The CSA MAESTRO agentic AI threat modeling framework is useful here because it encourages threat modelling across the full agent stack, not just the model endpoint. These controls tend to break down when organisations bolt agents onto legacy workflows with no clear ownership for tool permissions, because the testing scope becomes fragmented across app, cloud, and AI teams.

Common Variations and Edge Cases

Tighter testing coverage often increases delivery time and review overhead, requiring organisations to balance assurance against release velocity. That tradeoff is especially visible when a product team wants to ship a limited assistant first and “add security later.” Current guidance suggests the safer path is to treat even narrow agent capabilities as high-risk if they can influence decisions, move data, or act on behalf of a user.

There is no universal standard for when traditional testing alone is sufficient. For example, a static summarisation feature may remain within classic application testing if it has no tools, no memory, and no external retrieval. By contrast, a customer support agent that can search knowledge bases, update CRM records, or trigger refunds needs a different test plan and a different incident response model. The most mature programmes map both approaches to a shared control framework, then use agent-aware testing only where autonomy, delegation, or persistent state introduces new attack paths.

Teams should also watch for mixed architectures. A model may look like a chatbot, but behind the scenes it may invoke scripts, SaaS APIs, or RPA workflows. In those cases, the question is not whether the interface is “AI enough” to justify new testing. The question is whether the system can take a security-relevant action that traditional red teaming would not simulate. That is the point at which agent-aware testing becomes necessary, even if the user experience still resembles a normal application.

Related resources from NHI Mgmt Group

• How do organisations decide when to approve offensive agent testing?
• What is the difference between AI agent governance and traditional IAM?
• What is the difference between AI agent access control and traditional IAM?
• How should organisations decide whether to keep using traditional MFA?