Testing Agentic AI and LLMs: Red Teaming, RAG and MCP Risks

Testing an agentic AI system means testing two things that fail in different ways: the model, and the actor that has been built around it. As of August 2026 each layer has its own risk list. The OWASP Top 10 for LLM Applications 2026 (v1.0, published in early August 2026) covers the model layer, and the OWASP Top 10 for Agentic Applications for 2026 (entries ASI01 to ASI10, published 9 December 2025) covers the actor layer. ISTQB CT-AI v2.0, released 17 April 2026, gives you red teaming as a K3 objective, mentions agentic AI in exactly one sentence, and does not mention the Model Context Protocol at all. This article maps that gap and turns it into test conditions.

Two lists now, and the boundary between them is the point

The 2026 refresh of the LLM list is not cosmetic. Excessive Agency climbed from tenth-place obscurity to LLM03, Improper Output Handling fell from fifth to tenth, and System Prompt Leakage was renamed Hidden Context Exposure. The ordering was decided with a first-edition weighting of 75 percent practitioner vote and 25 percent incident data drawn from 6,639 classifiable real incidents, which is worth knowing before you treat the ranking as a coverage target.

The boundary rule is simple enough to apply in a design review. While the model only produces text that a human reads, you are on the LLM list. The moment it gains tools it can call, memory it carries between sessions and consequences it sets in motion downstream, the risk moves to the agentic list. Most features that ship as a chat box cross that line in their second sprint, and the test approach almost never crosses with them.

For test planning this means two risk analyses rather than one, and two sets of test conditions that do not substitute for each other. A perfectly hardened prompt does nothing about ASI03 Identity and Privilege Abuse, and a well-scoped service account does nothing about LLM09 Vector and Embedding Weaknesses. If you are catching up on what changed in the syllabus itself, the CT-AI v2.0 changes are covered separately.

The lethal trifecta is the fastest triage question you can ask

The single most useful frame in the 2026 material, credited to Simon Willison and repeated in the OWASP release, is a three-part check. Ask whether the system has all three of these at once:

• Access to private data — the agent can read something the attacker cannot read directly.

• Ingestion of untrusted content — the agent reads a page, ticket, email, document or tool result that an attacker can influence.

• An external communication channel — the agent can send, post, commit, request or otherwise move data outward.

When all three are present, a path exists from attacker-controlled text to attacker-chosen exfiltration, and it requires no defect in the model at all. The model behaving exactly as designed is sufficient. Remove any one leg and the high-impact path closes. Because this is an architecture question rather than a prompt question, it belongs in test analysis, before anyone writes the first adversarial prompt.

What CT-AI v2.0 actually gives you, and what it does not

The v2.0 syllabus is stronger on this than its predecessor. Section 4.2 is dedicated to testing generative AI and large language models, and it splits into 4.2.1 testing generative AI, 4.2.2 red teaming, and a hands-on 4.2.3 on exploratory testing of an LLM. Red teaming is a K3 objective, meaning you are expected to implement it rather than describe it. RAG appears at K2 in 3.1.4 alongside pretrained models and fine-tuning, poisoned training data appears as an input-data risk in 5.1.1 with red teaming named as its mitigation, and 6.1.4 is a dedicated section on adversarial testing of machine learning systems.

The right-hand column is the honest part. Agentic AI gets one sentence in 1.1.3 describing autonomous agents that plan, reason and act, and then nothing: no section, no learning objective, no guidance. Prompt injection is named once, in 4.2.2, and only the indirect variant. Jailbreaking, evasion attacks, model extraction and membership inference do not appear. This is a work gap rather than an exam gap, and the distinction matters when you are deciding what to study versus what to build into your test approach. The CT-AI certification guide covers what the qualification is worth in practice.

RAG is where the injection actually arrives

Teams tend to guard the chat box and leave the retrieval pipeline open, which is backwards. Section 4.2.2 puts it plainly by naming the hiding of malicious content in documents used by RAG, and LLM09 covers the storage side as vector and embedding weaknesses. Four test conditions cover most of the practical ground:

• Can a document that any user is allowed to upload change what the agent tells a different user?

• Does retrieval respect the requesting user's permissions, or does the shared index quietly flatten them?

• When a source document is deleted, is its embedding deleted too, or does the poisoned chunk survive in the vector store?

• Are retrieved passages rendered to the model as data, or can they be interpreted as instructions?

MCP: the layer the syllabus does not mention

The Model Context Protocol standardises how a model reaches tools, which is why it is now under most agent deployments and why it belongs in your risk analysis even though it is absent from CT-AI. The protocol's own security best practices page names the concerns worth turning into questions for your developers:

• The confused deputy problem — a proxy with a static client ID plus dynamic registration can let a third party inherit a consent the user gave to someone else. The spec requires per-client consent and exact string matching on redirect_uri, not wildcards.

• Token passthrough — an anti-pattern in which a server accepts a token that was never issued to it. It breaks the audit trail and the trust boundary at once.

• Session hijacking — the spec is explicit that sessions must not be used for authentication.

• Server-side request forgery — reachable through OAuth metadata discovery URLs, including cloud metadata endpoints.

• Scope creep — publishing every possible scope, or using omnibus scopes such as * or full-access, is called out as an anti-pattern.

• Local server compromise — a locally launched server runs at the client's privilege, so a malicious startup command is arbitrary code execution.

Two further risks sit outside the specification and come from security research rather than from a standard: tool poisoning, where instructions are hidden in a tool's description that the model reads and the user usually never sees, and the rug pull, where a tool's description changes after the user approved it. Both map cleanly onto ASI02 Tool Misuse and ASI04 Agentic Supply Chain Vulnerabilities. OWASP also has an MCP-specific top ten in progress, but it is still in beta, so treat it as direction of travel rather than as a settled reference.

Turning all of this into a test approach

None of the above is a new discipline. It is the ordinary test process applied to a system whose failures are probabilistic. A workable sequence:

1. Run the trifecta check at test analysis. Write one test condition per leg you cannot remove, and record the legs you could remove as findings for the architects.

2. Prioritise by blast radius, not by likelihood of misbehaviour. A tool that deletes production data deserves more attention than a tool that reads a public page, regardless of how well the model behaved yesterday.

3. Define the oracle as a system property. The pass condition is that the action did not execute or the secret did not cross the boundary. A polite refusal is not a result, because the next sampling run may not refuse.

4. Treat one run as one data point. Fix seeds and temperature where the platform allows it; where it does not, repeat and report a rate rather than a verdict.

5. Set exit criteria against both lists. Coverage over LLM01 to LLM10 and ASI01 to ASI10, plus every trifecta leg present in the design, is a defensible definition of done.

6. Regress every prompt that worked. A successful attack string is a regression test. Model version bumps and tool-catalogue changes both re-run it.

If you are preparing for the exam alongside this, the practical part of 4.2 rewards practice rather than reading. Our free CT-AI mock exams carry a written rationale on every answer option, including the wrong ones, so you can see why a distractor is wrong rather than only that it is. Start with mock 1, and check the full OWASP LLM Top 10 material for the risk side, which the syllabus deliberately leaves to specialists.