Notifications
Clear all
Topic starter
06/06/2026 11:24 am
TL;DR: Enterprises can see who uses ChatGPT or Copilot, but often cannot see what is sent, what returns, or how shadow AI and agent actions expose proprietary data, according to WitnessAI. Legacy DLP and CASB controls struggle because AI risk lives in conversational payloads and intent, not file transfers or keywords.
NHIMG editorial — based on content published by WitnessAI: generative AI security and runtime guardrails for enterprise AI
By the numbers:
- WitnessAI’s Observe module provides network-level coverage across 4,000+ AI applications, with bidirectional capture of prompts and responses and continuous discovery, all without endpoint agents or browser extensions.
Questions worth separating out
Q: How should security teams govern shadow AI without blocking all adoption?
A: Start by discovering where shadow AI is already in use, then classify interactions by data sensitivity and business purpose.
Q: Why do DLP and CASB tools struggle with generative AI security?
A: They were built for files, SaaS events, and known transfer patterns, not conversational payloads or agent actions.
Q: What should organisations do when AI tools can take actions on behalf of users?
A: Treat agent actions as governed identity events and require logging of tool calls, delegation chains, and execution context.
Practitioner guidance
- Inventory sanctioned and shadow AI usage Build a continuously updated catalog of approved and unapproved AI tools, including desktop apps and IDE integrations that browser controls miss.
- Shift policy from keywords to intent Classify AI interactions by purpose such as summarisation, coding help, research, or potential exfiltration, then apply allow, warn, block, or route responses based on sensitivity and business context.
- Extend governance to prompts, responses, and tool calls Treat prompts and model outputs as governed data flows, not passive chat text.
What's in the full article
WitnessAI's full guide covers the operational detail this post intentionally leaves for the source:
- Network-level inspection patterns for capturing prompts and responses across browser, desktop, and IDE use cases
- Practical examples of intent-based classification and the four-action enforcement model in day-to-day workflows
- Runtime protection details for prompt injection, jailbreak prevention, tokenization, and response filtering
- How the platform standardises policy across 100+ LLM types without relying on endpoint agents or browser extensions
👉 Read WitnessAI's analysis of generative AI security controls and runtime guardrails →
Generative AI security: are your controls keeping up with AI chatflows?
Explore further
06/06/2026 12:10 pm
Conversation-level visibility is now the baseline control for generative AI. Security teams that can only see logins are governing the wrong layer. The meaningful risk sits in prompts, responses, and copy-paste workflows that bypass file-centric inspection entirely. For IAM and security programmes, that means the control objective is no longer application access alone but the content and intent moving through AI interactions.
A few things that frame the scale:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to Ultimate Guide to NHIs.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
A question worth separating out:
Q: How can teams tell whether AI policy is actually working?
A: Measure whether prompts, responses, and tool calls are visible across sanctioned and unsanctioned workflows, then test whether intent-based rules distinguish legitimate use from risky disclosure. If the programme only catches obvious keywords or browser traffic, it is not controlling the real AI risk surface.
👉 Read our full editorial: Generative AI security needs bidirectional visibility and runtime controls
