Phase 7 · Agentic AI, RAG Security + Red Teaming · Lesson 2 of 4
Article
·
15 min
·
+10 pts
Two topics close out the phase: securing retrieval (RAG), and testing the whole system the way an attacker would (red teaming). Both pull directly on what you already have — RAG is the "data question" from the access module and the "poisoned corpus" from the injection module, and red teaming is how you turn all of this from a design on paper into findings with evidence.
Retrieval-augmented generation lets a model answer using data fetched at query time — a knowledge base, documents, tickets. It is enormously useful and it quietly breaks access control if you're not careful, because the retrieval step can pull in data the user was never allowed to see.
Get those three right and RAG stops being a permission-laundering machine and becomes what it should be: the right data, for the right user, from a trusted source.
Red teaming is deliberately attacking your own AI system to find failures before an adversary does. It is the AI counterpart to a penetration test, and it differs from classic pentesting in an important way: the attack surface is natural language and behavior, not just code and configuration. You're probing whether the model can be talked out of its guardrails, tricked by planted content, or coaxed into leaking or acting.
THREAT PRIMARY CONTROL EVIDENCE ---------------------------------- ------------------------------------- ------------------------------ Excessive agency (too much power) least-privilege tools, deny by default tool inventory + scope audit Tool misuse via injection sandboxing + human gate on high-risk approval workflow + audit log Runaway loops / cost blowup loop + cost/rate limits limit config + halt/alert logs RAG cross-user data exposure retrieval filtered by caller's perms query-time authz + access tests Corpus / document poisoning provenance + untrusted-content handling source allow-list + validation Prompt extraction / data leakage output filtering + guardrail model red-team results + block logs Unknown / emerging attacks continuous red teaming red-team reports + remediations
Agentic + RAG threats mapped to their primary control and the evidence a review collects
Red team output is evidence
For a GRC engineer, a red-teaming exercise is not just a security activity — it is an evidence-generating one. The report (attacks attempted, what got through, what was blocked, what was fixed) is exactly the artifact that proves a control operates and that the organization actively tests its AI. Under the governance frameworks from module 7.1, that continuous testing is increasingly expected, not optional.
RAG and red teaming complete the picture: retrieval scoped to the caller's permissions with trusted provenance, and a continuous adversarial testing practice whose reports become evidence. That is the whole phase in one motion — translate "secure the AI" into specific controls (governance tier, injection defenses, access scoping, agentic containment, RAG authorization) each with an artifact that proves it operates. In the exercise, you'll design the control posture and guardrails for an agentic assistant, capability by capability — the synthesis of everything in Phase 7.