Notifications
Clear all
Topic starter
07/06/2026 8:46 pm
TL;DR: Enterprises are deploying LLMs across chatbots, copilots, and autonomous agents faster than they can enforce visibility, policy, and runtime controls, creating exposure in data handling, prompt injection, and agentic workflows, according to WitnessAI. The governance problem is no longer model quality; it is whether security teams can observe, constrain, and audit AI activity before business data and actions escape control.
NHIMG editorial — based on content published by WitnessAI: enterprise LLM security and runtime defense guidance
By the numbers:
- 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 implement LLM security across copilots and agents?
A: Security teams should treat LLM security as a layered control problem, not a model tuning problem.
Q: Why do LLMs create new identity and access risks for enterprises?
A: LLMs create identity and access risks because they sit between users and systems while handling data, instructions, and actions in the same workflow.
Q: What do organisations get wrong about AI policy enforcement?
A: The common mistake is assuming that a written policy meaningfully constrains AI behaviour without technical enforcement.
Practitioner guidance
- Inventory every AI touchpoint Build a continuously updated catalogue of chatbots, copilots, embedded AI, agents, and MCP server connections, including where they ingest data and which identities they can act through.
- Inspect prompts and responses at runtime Enforce bidirectional inspection before prompts reach the model and before outputs reach users or downstream systems.
- Tokenize sensitive data before model exposure Replace credentials, PII, customer records, and proprietary values with non-reversible stand-ins before they leave the enterprise boundary.
What's in the full article
WitnessAI's full blog post covers the operational detail this post intentionally leaves for the source:
- The specific network-level visibility approach used to observe AI activity beyond browser-only controls.
- The intent-based policy logic that distinguishes legitimate business use from unsafe conversational context.
- The bidirectional runtime defense flow for prompts, responses, and agent tool calls in production.
- The data tokenization and redaction behaviour for sensitive values before external model exposure.
👉 Read WitnessAI's full guide to enterprise LLM security and runtime controls →
LLM security gaps: are your controls keeping up?
Explore further
08/06/2026 8:27 am
LLM security is now an identity governance problem, not just a content safety problem. The article shows that LLMs sit between people, data, and systems, which means they inherit access, generate actions, and sometimes amplify existing privilege paths. That changes the control objective from blocking bad text to governing who or what can act through the model. Practitioners should treat AI interaction paths as identity-bearing workflows, not as isolated application features.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 44% have implemented any policies to govern AI agents, even though 92% say the issue is critical to enterprise security.
A question worth separating out:
Q: How can teams tell whether AI governance is actually working?
A: Look for evidence of enforced controls, not just policy documents. Useful signals include complete AI inventory coverage, bidirectional inspection logs, tokenization before external model calls, and audit trails that tie agent actions back to the human initiator. If those artefacts are missing, governance is incomplete.
👉 Read our full editorial: LLM security needs runtime governance, not policy alone
