TL;DR: AI adoption is moving faster than security governance, and SentinelOne says unsanctioned AI usage is already tied to breaches, higher incident costs, and weak controls across the AI lifecycle. The real issue is not visibility alone, but that access review, endpoint, and interaction-layer controls were not built for agents that execute code and touch secrets.
NHIMG editorial — based on content published by SentinelOne: AI agent coverage, shadow AI discovery, and layered AI security controls
By the numbers:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed and 26% suspected.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems.
Questions worth separating out
Q: How should security teams govern AI assistants that can execute code and access secrets?
A: Treat them as governed non-human identities, not as ordinary chat interfaces.
Q: Why do AI assistants create more risk than standard chatbots?
A: Because they can move from text generation to action.
Q: What do security teams get wrong about shadow AI?
A: They often look only at browser traffic and miss local processes, wrapper apps, and non-standard ports.
Practitioner guidance
- Inventory every AI tool running outside approved channels Search endpoints, browser extensions, wrapper apps, and local processes for agentic AI tooling.
- Bind AI usage policy to identity and egress controls Update acceptable use rules so they explicitly cover autonomous assistants, MCP-connected tools, secret access, and non-standard network paths.
- Create one inventory for AI, secrets, and delegated access Track where assistants run, which secrets they can reach, what tools they can invoke, and who owns the workflow.
What's in the full article
SentinelOne's full article covers the operational detail this post intentionally leaves for the source:
- Endpoint hunting queries and process-level indicators for Clawdbot, OpenClaw, and Moltbot activity
- Layer-by-layer coverage mapping for EDR/XDR, Prompt Security, and ClawSec across the AI stack
- The seven security pillars and how each maps to a distinct AI risk surface
- Recommended next steps broken into week, 90-day, and six-month action horizons
👉 Read SentinelOne's analysis of agentic AI assistant coverage and AI governance →
AI agent governance gaps: what security teams need to fix now?
Explore further
AI agent governance is now an identity problem, not a tooling preference. Once an assistant can execute code and interact with systems at runtime, the question stops being whether users like the interface and becomes what identity, privilege, and audit model governs the actor. That shifts the centre of gravity from application security to IAM, PAM, and NHI oversight. Practitioners should treat agentic AI as a governed identity surface, not a productivity feature.
A few things that frame the scale:
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to The 2026 Infrastructure Identity Survey.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: Who should own AI agent governance in an enterprise?
A: Ownership should sit jointly across IAM, security operations, and the teams running the AI workload. If no one owns the assistant’s identity, access scope, logging, and containment, the organisation ends up with policy on paper but no enforced boundary in runtime. Governance needs an accountable owner for every AI actor.
👉 Read our full editorial: AI agent governance gaps are widening as adoption outpaces controls