UprootSecurityUprootSecurity

Phase 7 · Agentic AI, RAG Security + Red Teaming · Lesson 2 of 4

RAG Access Controls and AI Red Teaming

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.

RAG access controls

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.

  • Filter retrieval by the caller's permissions. This is the whole game. The vector store or search index must return only documents this user is authorized for — enforced at query time with the user's identity, using the RBAC/ABAC/ReBAC rules from the last module. The failure mode: embedding all documents into one index and letting anyone's query match anything. The model then launders permissions — it can read everything, so it answers anyone. Scope the retrieval, not just the prompt.
  • Respect provenance and classification. Tag documents with their source and sensitivity, and carry that through retrieval so a "public" answer never quotes a "restricted" document. Don't index secrets into a corpus a broad audience can query.
  • Treat retrieved content as untrusted. The corpus is an injection surface (module 7.2): a single poisoned document can carry instructions the model then follows. Validate provenance, prefer sources you control, and never let retrieved text silently become a command.

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.

AI red teaming

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.

  • What it targets. Jailbreaks and prompt injection (direct and indirect), data leakage and prompt extraction, harmful or policy-violating output, tool misuse and excessive agency, and bias/safety failures.
  • How it's done. Manual adversarial prompting by skilled testers, plus automated red-teaming tools that generate and mutate thousands of adversarial inputs at scale. In agentic systems, red teaming includes multi-step attacks — can a planted document three tool-calls back change what the agent does now?
  • Why it's different from a one-time test. Models, prompts, tools, and the corpus change constantly, and the attack space is effectively infinite. Red teaming is continuous, and its results feed back into the controls from this phase.
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.

The GRC throughline

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.

RAG Access Controls and AI Red Teaming — UprootSecurity Bootcamp