TL;DR: Shadow AI is running in 78% of enterprises, and AccuKnox argues that conventional cloud tooling misses the AI attack surface because agents, models, and data now move outside standard visibility and control paths. The practical implication is that AI governance must combine discovery, prompt filtering, data controls, runtime containment, and compliance evidence, not rely on application-layer security alone.
NHIMG editorial — based on content published by AccuKnox: AI Security Roadmap for Securing AI Models, Agents and Data
By the numbers:
- Shadow AI runs in 78% of enterprises, leaving most organisations with unmanaged AI assets outside normal security controls.
- The average AI breach costs about $670K more than traditional breaches because AI systems often have broader data access and higher privileges.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope.
Questions worth separating out
Q: How should security teams govern AI agents that can access enterprise systems?
A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring.
Q: Why do APIs create identity risk for IAM and PAM programmes?
A: Because APIs rarely operate without credentials, and those credentials often outlive the service they support.
Q: What breaks when shadow AI is not part of the asset inventory?
A: When shadow AI is absent from inventory, security teams cannot apply policy, logging, access review, or remediation to the workload.
Practitioner guidance
- Inventory all AI assets by runtime evidence Discover local and cloud AI assets using process scanning, SDK fingerprints, MCP protocol traces, and control-plane logs so unmanaged agents and models do not stay invisible.
- Bound agent permissions to task-specific access Limit shell, filesystem, network, and data privileges for AI agents to the minimum required for each workflow, and revoke those rights when the task ends.
- Separate prompt defence from data governance Deploy prompt filtering and indirect injection controls alongside AI-DSPM for training data, embeddings, and inference logs so one control does not carry both responsibilities.
What's in the full article
AccuKnox's full blog covers the operational detail this post intentionally leaves for the source:
- GPU-based prompt firewall design choices, including flamegraph profiling and tenant-specific GPU isolation
- Detection logic for local unmanaged AI assets such as Ollama, LangChain, LangGraph, MCP servers, and vector databases
- AI-DSPM coverage across training data, embeddings, inference logs, and data residency controls
- AI-BOM examples showing how framework and model vulnerabilities are tracked across the AI stack
👉 Read AccuKnox's roadmap for AI security across models, agents, and data →
AI security roadmaps and the governance gap teams are missing?
Explore further
AI security is now an identity governance problem, not just a model protection problem. Once an AI system can read data, call tools, and trigger actions, it behaves like a non-human identity with runtime authority. That means identity lifecycle, privilege scope, and auditability become core controls, not adjacent concerns. Programmes that keep AI in a separate security silo will miss the governance decisions that determine actual risk.
A question worth separating out:
Q: Who is accountable when an AI agent exceeds its intended scope?
A: Accountability should follow the delegation chain, not stop at the agent label. The human requester, the policy owner, and the team that granted underlying access all matter, because the agent acts within a permission model someone designed. If the chain is unclear, the governance model is already too weak.
👉 Read our full editorial: AI security roadmaps now need identity-powered runtime controls