Notifications
Clear all
Topic starter
14/09/2026 10:10 am
TL;DR: Enterprise AI use now spans chat tools, embedded copilots, models, and autonomous agents, and WitnessAI argues that traditional packet-centric and keyword-based controls miss much of the risk. Its seven-practice model points to unified visibility, intent-based classification, graduated policy enforcement, runtime guardrails, agent governance, audit trails, and continuous evaluation as the operational baseline.
NHIMG editorial — based on content published by WitnessAI: seven LLM security best practices for enterprise AI
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.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams govern AI agents that call APIs instead of using a UI?
A: Security teams should govern AI agents by treating each callable action as a scoped entitlement, not as a general application login.
Q: Why do keyword filters fail for enterprise AI security?
A: Keyword filters miss the way people and agents actually use AI, because risky prompts can look ordinary and sensitive output can emerge from benign input.
Q: What signals show that an AI governance programme is not working?
A: Warning signs include disconnected models built by different teams, repeated disputes over data ownership, inconsistent approvals and outputs that cannot be explained to stakeholders.
Practitioner guidance
- Build a live inventory of AI activity Discover sanctioned and unsanctioned AI applications, model providers, embedded copilots, MCP servers, and agent API calls, then reconcile them against procurement records at least quarterly.
- Classify interactions by intent and role Use context-aware controls to assess what the user or agent is trying to do, whether the action fits the role, and whether the destination model or tool crosses policy boundaries.
- Enforce graduated AI policy actions Allow, warn, block, or route interactions based on risk, data classification, and destination model.
What's in the full article
WitnessAI's full research covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanation of the seven-practice operating model for enterprise AI governance
- Concrete examples of allow, warn, block, and route policies across different departments and data classes
- Details on bidirectional runtime guardrails, including prompt inspection and response filtering
- How the audit trail design supports compliance evidence and board reporting
👉 Read WitnessAI's analysis of seven LLM security best practices for enterprise AI →
LLM security best practices: are your controls keeping up with AI use?
Explore further
14/09/2026 10:11 am
Intent-based governance is now the missing layer in enterprise AI security. Traditional controls were designed to catch known patterns, not infer whether a prompt, response, or agent action is appropriate for the user or workload. As enterprise AI becomes embedded in daily work, policy has to follow intent, role, and destination rather than stop at content inspection. The practical conclusion is that AI governance must be treated as a runtime decision system, not a static policy library.
A question worth separating out:
Q: Should organisations prioritise runtime guardrails or model review first?
A: Runtime guardrails usually deserve priority because they enforce policy during live use, when prompts, retrieval results, and agent actions are actually moving through the environment. Model review still matters, but it does not stop real-time data leakage, jailbreak attempts, or inappropriate actions at the point of execution.
👉 Read our full editorial: LLM security best practices need runtime governance, not static controls
