Governing Agents and RAG Systems

Why do RAG and agents need their own treatment?

A conventional model is governed through its training data, evaluation and release. A RAG system also draws on a knowledge base at run time, so quality, access and freshness of that content directly shape every answer. An agent goes further: it can plan steps, call tools and change things. Risk moves from "what might it say?" to "what might it read, and what might it do?"

What should you control in a RAG system?

• Source approval: which repositories feed the index, who owns them, and what classification they hold.
• Access mirroring: retrieval respects the permissions of the person asking, so the system cannot surface documents they could not otherwise open.
• Freshness and removal: updates and deletions in the source reach the index. This also supports erasure requests.
• Grounding checks: answers are evaluated for support from retrieved sources, and citations are shown where users rely on them.
• Retrieval logging: which sources were used for which answer, kept under a retention policy.
• Injection resistance: retrieved text is treated as untrusted input, since documents can contain instructions aimed at the model.

What should you control in an agent?

Area	Control
Identity	Each agent has its own identity, owner and credential, not a shared account
Permissions	Least privilege: only the tools and data the task needs
Limits	Caps on spend, volume, scope and number of steps
Approval	Human sign-off for irreversible, sensitive or high-value actions
Testing	Scenario tests including adversarial inputs, rerun when tools or models change
Observability	A trace of requests, tool calls, results and decisions
Stop control	A way to pause an agent or revoke its access quickly

A hypothetical walk-through

A procurement team deploys an agent that answers policy questions and drafts purchase requests. This example is hypothetical.

1. The knowledge base is limited to approved policy documents, each with an owner and review date.
2. The agent can read the catalog and create a draft request, but cannot submit one; a person approves.
3. Test cases include a policy document seeded with a hidden instruction, to see whether the agent obeys it.
4. Every run writes a trace linking question, sources retrieved, draft created and approver.
5. When a policy is withdrawn, the source removal reaches the index, and the next test confirms the old text no longer appears.

How do you avoid a pile of one-off controls?

Agent and RAG controls overlap with data, security and model risk controls. Keep a single control register in which each control is written once, tested once and mapped to every standard or regulation it supports, such as ISO/IEC 42001 or the NIST AI RMF. Tier each system through the inventory, then apply the controls its tier requires, along with the wider model risk process.

How do you test these systems?

Static test sets are not enough for systems that retrieve and act. Combine several methods. Build scenario suites from realistic tasks, including edge cases and requests the agent should refuse. Add adversarial tests, such as documents or messages carrying hidden instructions, and attempts to talk the agent into using a tool outside its remit. Sample live traces on a schedule and score them against a rubric. Rerun the suite whenever the model, prompt, tools or knowledge sources change, because any of them can change behavior.

What should be recorded for each run?

Enough to reconstruct what happened: who or what made the request, which sources were retrieved, which tools were called with what parameters, what the agent returned, and who approved any gated step. Store traces under a retention policy that considers privacy, since prompts and retrieved text may contain personal data. Records should be tamper-evident, so a later review can trust them.

What is a sensible way to start?

Begin with read-only assistants over a small, approved set of sources. Add drafting capability next, with a person approving outputs. Grant action rights last, one tool at a time, each with limits and a trace. Expand only when monitoring shows the previous stage behaving as intended.

Review the sequence regularly. Each step up in autonomy should be a deliberate decision recorded by the system owner and the risk reviewer, not a gradual drift.

Plan for failure as well. Define what happens when an agent behaves unexpectedly: who is alerted, how its access is revoked, how affected actions are reversed, and how the incident feeds back into tests. Rehearse it once before you need it.

Where aerais fits

aerais builds agent and RAG governance into the systems themselves: source registers, permission models, approval points and traces, with a unified control register behind them, and then operates it. The work spans our AI governance and data governance practices, and the chain of custody links agent actions back to the data behind them.

This article is for general information only and is not legal advice.