AI security’s governance gap is visibility, context, and control

At a glance

What this is: This is SentinelOne’s analysis of AI security governance, which says enterprises are adopting AI faster than security teams can see, govern, and control its use across tools, data, and agentic workflows.

Why it matters: It matters because IAM, NHI, and broader security teams now need to govern AI usage, agent permissions, and data flows as an operational control problem, not just a monitoring problem.

Context

AI security is the governance layer that sits between rapid AI adoption and the controls needed to manage how models, agents, tools, and data are used. The core problem is that AI systems now operate across multiple control planes, while many security teams still rely on controls designed for endpoints, cloud workloads, or traditional software flows.

This becomes an identity issue when AI tools, agents, and MCP-connected services can act on behalf of users, developers, or applications without a clear lifecycle, ownership model, or enforceable policy boundary. In that setting, visibility and authorisation matter as much as detection, because the risk is not only what AI outputs but what it is permitted to access, infer, and do.

Key questions

Q: How should security teams govern AI use in developer tooling?

A: Security teams should govern AI use as a data and access problem, not only a productivity feature. Define what information can be sent to models, require human review of generated code, and apply least privilege to connected repositories and tools. Approved use cases should be explicit, monitored, and revisited as model capabilities expand.

Q: Why do AI models create governance risk even without retraining?

A: Because behaviour can change at inference time when the model sees new context, examples, or instructions. That means access decisions made before a session starts are not enough on their own. Practitioners need controls that address what the model can consume and do during execution, not only what it was permitted to access originally.

Q: What are the signs that AI security controls are lagging behind AI deployment?

A: Common warning signs include broad AI use with limited governance, unclear ownership for risk decisions, weak visibility into model usage, and inconsistent security testing before deployment. Another indicator is when organisations can describe AI innovation goals but cannot explain how they monitor data exposure, trust boundaries, or misuse in production. That gap usually means controls are trailing adoption, not shaping it.

Q: How do AI security programmes differ from traditional endpoint or cloud security programmes?

A: Traditional programmes focus on devices, workloads, and network paths. AI security also has to govern context, intent, and delegated action across prompts, tools, models, and agent chains. The difference is that the control boundary moves from infrastructure alone to the full decision path that AI systems use to access and transform data.

Technical breakdown

Why AI security needs visibility across prompts, tools, and agents

AI security fails when defenders can only see the endpoint, browser, or network layer but not the actual AI interaction path. Prompts, outputs, plugins, assistants, and connected agents create a chain of data movement that is often invisible to traditional controls. Once users copy sensitive content into third-party models or a browser-integrated assistant, security loses context on where the data went, how it was transformed, and whether it was retained. In agentic environments, that visibility gap widens because the system may call tools, retrieve context, or trigger actions without a human in the loop for every step.

Practical implication: build controls that inspect AI usage at the interaction layer, not only at the network or endpoint layer.

MCP and agent-to-agent connections create a new trust boundary

Model Context Protocol expands the AI control surface by connecting agents to tools and data sources in a standardised way. That makes integration easier, but it also turns each connection into a governance boundary that must be inventoried, authorised, and monitored. If an organisation cannot answer which agents can call which tools, with what context, and under whose authority, it does not actually control the AI estate. This is where agent identity and delegated privilege become relevant: the issue is not only the model’s output, but the authority attached to the path between model, tool, and data source.

Practical implication: treat every MCP connection as an access relationship that needs inventory, approval, and revocation handling.

AI governance depends on data quality, cardinality, and latency

The article correctly shifts the conversation from pure detection to the infrastructure needed to make AI security workable at scale. High-quality AI security depends on good data coverage, enough context to correlate events, and low latency so decisions can happen before harmful actions propagate. Cardinality matters because AI-driven environments generate huge volumes of signals across endpoints, identities, clouds, and AI tools, which can overwhelm conventional pipelines. If the telemetry stack cannot normalise and enrich that data quickly enough, AI security becomes a reporting exercise instead of a control system.

Practical implication: align telemetry architecture to AI governance goals, or policy decisions will always lag the risk.

Threat narrative

Attacker objective: The attacker objective is to exploit AI-assisted workflows and connected agents to obtain sensitive context, broaden access, or accelerate attack execution.

1. Entry occurs when employees or developers interact with third-party AI tools, AI browsers, or connected agents using sensitive business context.
2. Credential or context abuse follows when those systems are allowed to process prompts, retrieve data, or invoke tools without strong boundary controls.
3. Impact is the exposure of confidential data, unsafe automated action, or attacker advantage through AI-enabled reconnaissance and malware adaptation.

Breaches seen in the wild

• 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.
• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI security governance now depends on the control plane, not just the model. The article’s central point is that organisations are trying to govern AI with tools that cannot see prompts, connected assistants, agent actions, or downstream data movement. That creates a governance gap where policy exists in theory but cannot be enforced at the point of use. For identity teams, this means AI usage has to be tied to access control, ownership, and auditability if it is to remain governable.

Model Context Protocol turns AI integration into an identity problem. Once agents can call tools and data sources through standardised connections, each link becomes a delegated access path that must be inventoried and constrained. The real risk is not just model output quality but uncontrolled authority across agent-to-tool relationships. Practitioners should treat these connections as part of the identity estate, with lifecycle and revocation discipline applied to every agent path.

AI security debt accumulates when telemetry cannot keep up with AI behaviour. The article’s emphasis on latency, cardinality, and unified data is a reminder that governance collapses when the security stack cannot process enough context in time. That is not a tuning issue alone; it is an architectural one. The practical conclusion is that AI programmes need observable, policy-enforced control paths before agentic behaviour becomes too distributed to govern.

Autonomy without accountability is the wrong operating model for AI security. The article’s strongest principle is that machine-speed action only works when bounded by human-defined guardrails and explainable decisions. That maps directly to identity governance because the question is not whether AI can act, but who authorised it, under what policy, and with what traceability. Security teams should measure AI autonomy against governance controls, not against automation enthusiasm.

AI security is now a data integrity and digital trust issue as much as a protection issue. The article links AI security to preserving authenticity, identity fidelity, and trusted digital interactions. That widens the discipline beyond loss prevention into trust governance, where manipulated outputs, untrusted context, and opaque delegation can undermine decision-making. Practitioners should frame AI controls as part of digital trust architecture, not as a narrow AI tooling problem.

From our research library:

• Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.

What this signals

AI security governance is becoming an access-control problem disguised as an innovation problem. The article shows that once AI tools, assistants, and agents are embedded in day-to-day work, the real question is who or what is allowed to act, on which data, and with what traceability. That pushes AI into the same operational discipline as identity governance, where ownership and revocation matter more than novelty.

Shadow AI discovery should be treated as the first control, not the last. Most organisations will not govern what they cannot see, and the article makes clear that AI usage is spreading faster than security teams can catalog it. The practical signal for readers is that AI inventories, policy boundaries, and telemetry integration now need to be part of the base control set for any serious programme.

For practitioners

• Inventory AI tools, assistants, and agent connections Create a live register of sanctioned and shadow AI tools, including browser assistants, developer copilots, and agent-to-agent links.
• Enforce policy at the prompt and action layer Apply controls that inspect prompts, outputs, and tool calls before sensitive data is exposed or an agent executes a downstream action.
• Map agent authority to identity governance records Record which user, service, or workflow owns each AI agent and what data sources or tools it can reach on their behalf.
• Tighten telemetry pipelines for AI decision speed Normalise, enrich, and correlate AI-related telemetry so detections and response actions remain usable at the same pace as agent activity.
• Define rollout guardrails for AI use cases Set approval thresholds for internal AI apps, data-handling rules for prompts and outputs, and revocation paths for risky integrations.

Key takeaways

• AI has become a broad attack surface because employees, developers, and agents use it across ordinary workflows without consistent visibility or governance.
• The central failure mode is not just poor detection speed, but the lack of context on prompts, tools, data flows, and delegated actions.
• Security teams need controls that bind AI usage to identity, inventory, and policy enforcement before agentic behaviour outpaces review and response.

Key terms

• AI Security Platform: An AI security platform governs how people and agents use AI systems across prompts, responses, files, and tool calls. It goes beyond traditional content filtering by adding intent-aware policy, runtime enforcement, and audit linkage so the organisation can control both the conversation and the action that follows.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It helps practitioners turn identity-aware controls into something they can operationalise across modern security programmes.