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

At a glance

What this is: This is SentinelOne’s OneCon 2025 AI security position paper, arguing that AI creates both a new attack surface and a new defensive operating model centered on visibility, automation, and governance.

Why it matters: It matters to IAM, NHI, and security teams because AI tools and agents increasingly behave like governed identities, but most enterprises still lack consistent controls over access, context, and data use.

👉 Read SentinelOne's OneCon 2025 AI security strategy and product details

Context

AI security becomes a governance problem when employees, developers, and applications start using third-party models, embedded assistants, and agent-connected protocols across normal business workflows. The main failure is not a lack of tools, but a lack of visibility into what data is being sent, which systems are connected, and who is accountable for the resulting actions. That creates an identity and access boundary problem as much as a model security problem.

The article’s most important implication for NHIs is that AI agents, MCP servers, and automated workflows extend the identity surface beyond human users into machine-driven decision paths. That makes authentication, authorization, data handling, and auditability part of the same control story, not separate disciplines. In other words, AI security now overlaps directly with NHI governance, even when the source article is framed as a broader AI platform strategy.

Key questions

Q: How should security teams govern AI agents that can access tools and data?

A: Security teams should govern AI agents as NHIs with scoped permissions, explicit owners, logging, and revocation paths. The key is to control what the agent can reach, what data it can process, and which actions it can trigger. Without lifecycle and audit controls, agentic workflows behave like hidden privileged access rather than managed automation.

Q: Why do AI tools create new identity and access risks?

A: AI tools often sit between users and sensitive systems, which means they can inherit broad access without the accountability that normal IAM processes expect. If prompts, connectors, and outputs are not governed, the tool becomes a high-speed pathway for data exposure or unauthorized action. The risk rises when teams cannot prove who approved the access or when it should be removed.

Q: What breaks when organisations cannot see shadow AI usage?

A: When shadow AI is invisible, security teams lose control over where data is sent, which assistants are connected, and whether those systems can retain or expose sensitive information. That undermines policy enforcement, auditability, and incident response. It also means the organisation may be granting machine-driven access without a defined identity lifecycle.

Q: How can teams measure whether AI security controls are actually working?

A: Teams should look for measurable proof that AI activity is logged, prompts are filtered, connectors are approved, and response actions are attributable to a named owner. If investigations still require manual reconstruction across multiple tools, the control plane is not mature enough for autonomous defence. The right signal is reduced time to understand and contain AI-driven activity.

Technical breakdown

Why AI security now spans models, agents, and data pipelines

AI security is no longer limited to protecting a model from misuse. In practice, the attack surface now includes prompts, outputs, embedded assistants, third-party tools, MCP-connected services, and the telemetry pipelines that feed detection and response. That means a security team must govern both the AI system itself and the data and identity paths it uses to operate. When AI becomes part of business workflows, the real control question becomes whether actions are traceable, bounded, and attributable across the whole chain.

Practical implication: map each AI workflow to its data sources, access paths, and accountable owner before expanding usage.

How MCP changes the control problem for AI agent identities

Model Context Protocol is a connectivity layer that lets AI agents call tools and data sources through a standard interface. That is useful for orchestration, but it also creates a governance challenge because tool access can be delegated dynamically and the resulting activity may look like normal system traffic. From an identity perspective, MCP-connected agents need explicit authorization boundaries, audit trails, and lifecycle controls, because they can function like NHI workloads with decision-making capability. Without those controls, the protocol becomes a bridge for overreach rather than a wrapper for safe integration.

Practical implication: treat MCP-connected agents as governed NHIs and assign them scoped access, logging, and revocation paths.

Why telemetry quality determines whether AI-driven defense actually works

The article’s emphasis on data quality, inclusivity, cardinality, and latency points to a practical truth: AI defense is only as useful as the telemetry it consumes. High-cardinality environments create too much signal for traditional rule sets, while delayed ingestion breaks response timing and weakens correlation across endpoint, identity, and cloud layers. AI-assisted investigation can compress analyst time, but only if the underlying data is normalized, fresh, and sufficiently complete to support decision-making. This is a control-plane problem as much as an analytics problem.

Practical implication: prioritize low-latency, normalized telemetry before relying on AI-driven investigation or autonomous response.

NHI Mgmt Group analysis

AI security is becoming an identity governance problem, not just a model security problem. The article correctly frames AI as both a business accelerant and an attack surface, but its deeper implication is that governance must now extend to AI systems that can call tools, move data, and trigger actions. That pushes AI agent identities, service credentials, and delegated access into the same control conversation as human IAM. Practitioners should treat AI usage as part of identity architecture, not a separate innovation track.

Model Context Protocol expands capability faster than many organisations can expand control. A protocol that connects agents to tools and data sources is operationally attractive, but it also compresses the distance between intent and action. If authorization, logging, and ownership are weak, MCP can become a high-speed path for misuse or accidental overreach. The governance gap is not the protocol itself, but the absence of explicit lifecycle and access controls around the agents using it. Practitioners should govern MCP as a privileged integration layer.

Autonomy without auditability is the wrong operating model for enterprise AI. The article repeatedly stresses human-defined guardrails and explainability, which is the right direction, but the real test is whether those guardrails persist at runtime. If AI can decide and act faster than teams can inspect, the programme has moved beyond policy into control failure. That is why AI governance must be measurable, revocable, and traceable across endpoints, identities, clouds, and data paths. Practitioners should require evidence of runtime accountability before scaling autonomous features.

Detection-response latency: this is the practical concept emerging from the article’s emphasis on machine-speed defence and high-performance telemetry. The field is shifting from static alerting to systems that must ingest, correlate, and respond before attacker dwell time compounds. That is a security operations issue, but it is also an identity issue when agentic systems and machine identities generate the activity. Practitioners should use this concept to align AI security, SOC, and NHI governance around one runtime objective.

AI security architecture is now a board-level resilience issue because data, identity, and response are converging. The article’s focus on unified data, context, and action reflects where the market is heading: platforms will increasingly promise end-to-end visibility across endpoint, identity, cloud, and AI. That does not remove the need for governance, because consolidation can hide control gaps if teams assume the platform itself supplies accountability. Practitioners should evaluate whether their architecture can prove who or what acted, on what data, and under which policy.

What this signals

AI security programmes will increasingly be judged on whether they can prove control over data movement, not just model performance. The practical test is whether teams can answer who used the tool, what data it touched, and which policy allowed it. That is why identity, telemetry, and governance need to converge around runtime accountability, especially as AI systems become embedded in everyday business processes.

Shadow AI should now be treated as shadow access. When unsanctioned assistants or agentic workflows can connect to systems, they create the same governance blind spots that unmanaged NHIs do. Practitioners should extend discovery, policy enforcement, and offboarding discipline to AI tools before they multiply faster than review cycles can catch them.

AI defenders need operating data with lower latency and higher fidelity if they want machine-speed response to be credible. That makes telemetry architecture a security control, not just an engineering choice. Teams that cannot normalise endpoint, identity, cloud, and AI signals quickly will find autonomy hard to govern in practice.

For practitioners

• Inventory AI tools, assistants, and agents by data access path Create a living register of all approved and unsanctioned AI systems, including prompts, connectors, and the data domains they can touch. Tie each entry to an owner, a business purpose, and a revocation path so the list can support access review and incident response, not just discovery. Use the same process discipline you would apply to sensitive NHI inventory.
• Treat MCP-connected agents as governed NHIs Assign scoped permissions, logging, and lifecycle ownership to any agent or service that uses Model Context Protocol to reach tools or data sources. Separate read, write, and execution rights where possible, and require explicit approval for any connector that can trigger downstream actions. Review these integrations on the same cadence as privileged service accounts.
• Enforce prompt and output controls for sensitive data Block or redact secrets, regulated data, and internal identifiers before prompts reach third-party models, and inspect outputs for unsafe code, exposed credentials, or policy violations. Pair this with policy enforcement in approved AI applications so employees cannot bypass controls by using informal tools.
• Build low-latency telemetry pipelines before scaling AI response Normalise endpoint, identity, cloud, and AI activity into a pipeline that can support high-cardinality queries and near-real-time investigation. If data arrives too late or in inconsistent formats, autonomous response will create noise faster than it creates containment. Start with the telemetry sources that already feed your SOC and identity stack.

Key takeaways

• AI security now depends on governing prompts, connectors, agents, and data paths together rather than treating them as separate problems.
• The most consequential control gap is visibility into how AI systems interact with sensitive data and downstream tools.
• Practitioners should extend NHI-style ownership, logging, and revocation discipline to AI workflows that can act at machine speed.

Key terms

• Shadow AI: Shadow AI is the use of AI tools, assistants, or agents that security and governance teams cannot fully see or manage. It becomes a control problem when unsanctioned or poorly inventoried systems can access data, trigger actions, or bypass established policy and review processes.
• Model Context Protocol: Model Context Protocol is an open standard that connects AI agents to tools and data sources through a common interface. It simplifies orchestration, but it also expands the governance surface because each connection can become a delegated access path that needs ownership, scope, and auditability.
• AI Security: AI Security is the set of controls used to protect AI systems and to use AI safely in security operations. It includes governance of models, prompts, agents, data, telemetry, and response actions, plus the accountability mechanisms needed when AI can influence or execute work.
• Detection-response latency: Detection-response latency is the delay between an event happening and a security team being able to understand and act on it. In AI-driven environments, this matters because machine-speed activity can outpace manual investigation, making telemetry freshness and automated correlation part of the control surface.

What's in the full article

SentinelOne's full post covers the operational detail this post intentionally leaves for the source:

• How SentinelOne's AI Security architecture maps endpoint, identity, cloud, and AI signals into a single operating model.
• Details of the Purple AI MCP Server and how it connects to OpenAI, Anthropic, Gemini, or internal models.
• Product-level information on Prompt Security capabilities such as shadow AI discovery, prompt DLP, and secret redaction.
• Operational specifics on the Observo AI pipeline, including sub-second telemetry handling and high-cardinality query support.

👉 SentinelOne's full post covers the AI Security architecture, MCP integration, and platform controls in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security programme that now has to govern AI-driven access and action.