Notifications
Clear all
Topic starter
19/08/2026 4:00 pm
TL;DR: Generative AI risk management has to cover prompts, retrieved data, outputs, tools, and memory because dynamic behaviour can turn a safe-looking chatbot or agent into a policy and data exposure path, according to ActiveFence. The real governance gap is treating GenAI like fixed application logic when runtime context keeps changing.
NHIMG editorial — based on content published by ActiveFence: Generative AI Risk Management: Prompts, RAG, Agents
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: How should security teams govern generative AI tools that connect to core systems?
A: Treat them as non-human identities with lifecycle, access, and telemetry requirements.
Q: Why do RAG systems create more governance risk than a simple chatbot?
A: RAG systems introduce an extra trust boundary because external content enters the prompt window at runtime.
Q: What breaks when AI agents are given broad standing access?
A: Broad standing access breaks governance because the agent can move from one task to another without a fresh authorization check.
Practitioner guidance
- Inventory every GenAI workflow and owner Record each chatbot, copilot, RAG system, agent, model provider, vector store, tool integration, and business owner so no production system sits outside governance.
- Enforce retrieval permissions before prompt assembly Apply document-level access checks before content enters the model context, and treat retrieved text as untrusted input until it is authorised and validated.
- Bind agent permissions to NHI lifecycle controls Assign each agent a named owner, explicit scope, logging requirements, and revocation path, then review changes when tools, memory, or data access expand.
What's in the full article
ActiveFence's full article covers the operational detail this post intentionally leaves for the source:
- The article expands the control model for prompts, retrieval, outputs, memory, and tools across the full GenAI workflow.
- It breaks down where NIST AI RMF and OWASP map to testing, runtime guardrails, monitoring, and evidence.
- It explains how teams should think about launch review, production drift, and post-launch monitoring across GenAI use cases.
- It outlines practical risk categories for copilots, RAG systems, and agents serving regulated or customer-facing workflows.
👉 Read ActiveFence's analysis of generative AI risk management for prompts, RAG, and agents →
Generative AI risk management: are your controls keeping up?
Explore further
19/08/2026 4:37 pm
GenAI governance fails when organisations treat runtime context as non-security data. The article correctly shows that prompts, retrieved documents, memory, and tool outputs are all part of the attack surface. That means policy written at the procurement stage is incomplete unless it becomes enforcement in production. Practitioners should frame GenAI governance as continuous control over dynamic context, not a one-time model review.
A question worth separating out:
Q: How do organisations know if AI governance is actually working?
A: They should be able to reconstruct a live interaction from identity context, policy outcome, accessed resources, and enforcement evidence. If the organisation can only show a policy document or a generic alert, governance is incomplete. Working AI governance leaves behind reviewable artefacts that compliance, legal, and security teams can use without guessing what happened.
👉 Read our full editorial: Generative AI risk management needs controls beyond the model
