SentinelOne acquires Prompt Security for AI visibility and control

At a glance

What this is: SentinelOne says acquiring Prompt Security will extend runtime visibility and control over employee AI use across browsers, desktop apps, APIs, and MCP-connected workflows.

Why it matters: For IAM, NHI, and AI governance teams, the issue is that AI access control is moving into runtime enforcement, where unmanaged usage, data leakage, and prompt abuse create governance gaps that policy documents alone cannot close.

Context

AI governance problems often start where sanctioned use ends. Once employees move between browsers, desktop tools, custom workflows, and agent-connected services, policy visibility breaks down and security teams lose a reliable view of what data is being prompted, stored, or forwarded. In that environment, the identity question is no longer only who signed in, but what the AI system is allowed to do with enterprise data once access is granted.

This acquisition sits at the intersection of AI security and identity governance because AI tools behave like non-human access paths into enterprise data and systems. The challenge is not simply whether AI is present, but whether its prompts, outputs, and delegated actions are observable, constrained, and auditable across unmanaged usage as well as approved deployments.

Key questions

Q: What breaks when AI governance only documents policy and does not inspect runtime activity?

A: Policy-only governance leaves a blind spot at the point where AI systems actually process prompts, route data, and trigger actions. That means shadow AI, unsafe outputs, and delegated tool use can all proceed without intervention. The failure is not lack of documentation, but lack of enforcement where the risk occurs.

Q: Why do MCP and AI tool workflows increase API security risk?

A: They increase risk because the model or agent becomes an active caller that can move across tools and data sources within one flow. If permissions are broad, poorly inventoried or inherited from shared service accounts, the resulting access path can exceed what any single human reviewer expected.

Q: How should security teams govern shadow AI without blocking productivity?

A: Use visibility-based controls instead of blanket bans. Identify which tools are in use, who is using them, and what data they can access, then apply targeted policies by role and data sensitivity. That approach preserves legitimate AI adoption while reducing exposure from unsanctioned tools and unreviewed data paths.

Q: What is the difference between role-based access control and AI-assisted access governance?

A: Role-based access control assigns permissions through predefined roles. AI-assisted access governance evaluates whether a specific entitlement still makes sense using usage patterns, peer behavior, and risk context. RBAC standardizes access, while AI helps decide whether that access is still justified in a changing environment.

Technical breakdown

Why AI visibility fails once usage moves beyond managed apps

Employee AI use is increasingly distributed across browsers, desktop applications, API calls, IDE assistants, terminal tools, and custom workflows. That makes point-in-time policy checks inadequate because the security boundary is no longer a single application or tenant. Runtime inspection is the control layer that can observe prompts, responses, and data handling as the interaction occurs. In identity terms, each AI session behaves like a transient non-human access path with its own context, permissions, and data exposure risk. If the organisation cannot see the session at the moment of use, it cannot govern what data entered the model or what output was returned.

Practical implication: govern AI usage at runtime, not only through acceptable-use policy or app allow lists.

How MCP-connected AI workflows expand the identity surface

Model Context Protocol connections extend AI systems to tools and data sources, which means the AI session can trigger actions beyond chat. That creates an identity and privilege problem, because an agent or assistant may inherit tool access that was never designed for a human workflow. Security controls therefore need to inspect not only prompts, but also prompt templates, tool calls, and responses flowing through the protocol layer. The key risk is delegated authority without sufficient guardrails, especially when multiple servers, assistants, or connectors are chained together. In practice, the control objective is to prevent the AI layer from becoming an ungoverned access broker.

Practical implication: treat MCP connectors as governed access paths and review their permissions and telemetry like other privileged integrations.

Why prompt injection and data leakage require inline controls

Prompt injection works by steering the model or agent toward unsafe behaviour, while leakage occurs when sensitive information is copied into prompts, outputs, or downstream stores. These are runtime threats, so detection after the fact is too late for meaningful containment. Inline controls can redact, tokenise, block, or coach users before the data leaves the protected boundary. For AI governance teams, this is the operational difference between logging a violation and preventing one. The architecture matters because the same control plane must handle sanctioned and shadow AI without assuming that every use case can be routed through a single managed application.

Practical implication: combine sensitive-data controls with prompt-level inspection so leakage and injection are intercepted before response generation.

Threat narrative

Attacker objective: The objective is to extract sensitive data or abuse AI-connected workflows in ways that evade normal governance and monitoring.

1. Entry occurs when employees use sanctioned or shadow AI tools through browsers, desktop apps, APIs, or MCP-connected workflows that are not centrally governed.
2. Credentialed access or delegated context then allows prompts, data, and tool calls to move into AI sessions with broader reach than intended.
3. Attackers or unsafe usage can exploit prompt injection, jailbreaks, or leakage paths to expose sensitive information, manipulate outputs, or misuse connected tools.
4. The impact is unauthorized data exposure and weakened governance over AI-assisted work, including unmanaged use that escapes normal audit and compliance boundaries.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.

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

Runtime AI governance is becoming the new access control layer. Policy documents and app allow lists cannot govern what employees do once prompts, files, and connectors are in motion. The relevant control point is the interaction itself, where sensitive data can be entered, transformed, or forwarded. Practitioners should treat AI sessions as governed access events, not as informal productivity tools.

AI visibility gaps are now identity gaps. When employees use browsers, desktop apps, APIs, and agent-connected workflows, the organisation loses a stable inventory of where data is going and which systems are acting on it. That is a classic governance failure, only now the access path is non-human and often transient. Security teams need inventory, auditability, and enforcement at the point of use, not after the fact.

MCP makes the governance problem more explicit, not more theoretical. Once AI systems can call tools and servers through standardised connectors, the security question becomes whether delegated actions are properly bounded. This is where AI security and NHI governance converge: the connector layer behaves like an access broker and must be managed as such. Practitioners should reclassify MCP-linked pathways as governed integrations, not convenience features.

Shadow AI will keep expanding until enforcement is independent of approved app paths. Many organisations still assume that governance starts when IT approves a tool. That assumption fails when employees can reach capable AI systems through unmanaged browsers, local clients, or embedded assistants. The practical answer is to apply consistent inspection and control regardless of where the AI interaction originates.

From our research library:

• 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
• Half of companies using generative AI will deploy agentic AI by 2027, according to Deloitte's 2025 Technology Predictions.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

AI governance is shifting from approval lists to interaction control. For practitioners, the key change is that sanctioned use and shadow use now sit on the same technical plane: browsers, desktop tools, APIs, and assistants. That means AI policy must be enforced where prompts and data move, not where tools are purchased.

MCP-linked workflows deserve the same governance attention as other delegated access paths. Once AI systems can reach external tools and servers, the organisation is no longer just managing a model. It is managing a non-human access path with the potential to move data and initiate actions, which is why connector oversight belongs in the identity programme.

Shadow AI discovery has become a control objective, not a monitoring extra. If teams cannot see where employees are using AI, they cannot assess leakage, prompt abuse, or compliance exposure. The practical programme response is to build discovery, logging, and enforcement together so visibility leads directly to control.

For practitioners

• Map AI interaction paths to governed access points Inventory browsers, desktop tools, APIs, IDE assistants, terminal copilots, and MCP-linked workflows as distinct control paths rather than a single AI channel.
• Enforce runtime inspection for sensitive prompts Inspect prompts, responses, and attached context in real time so redaction, blocking, or tokenisation happens before data leaves the protected boundary.
• Review MCP connector permissions as privileged integrations Treat each connected server or tool as a delegated access relationship and validate what actions the AI layer can initiate on the organisation's behalf.
• Separate shadow AI discovery from app approval Build a discovery process that finds unsanctioned AI usage independently of procurement or allow-list workflows, so hidden usage is not missed.

Key takeaways

• AI governance now depends on runtime inspection of prompts, responses, and tool calls, not on policy documents alone.
• The control problem expands when AI reaches browsers, APIs, desktop apps, and MCP-connected workflows, because delegated access becomes harder to bound.
• Security teams should treat shadow AI discovery, connector review, and inline data protection as part of the identity and access programme.

Key terms

• 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.
• MCP Gateway: The control layer that relays assistant intent to tools and data sources through the Model Context Protocol. In practice, it becomes a policy boundary, not just a transport layer. If it trusts model output too early, it can turn unverified reasoning into real-world execution or disclosure.
• Runtime AI usage control: Runtime AI usage control is the practice of governing what an AI system can do while it is actively running. It enforces policy at the moment of action, limiting prompts, tool calls, data access, outputs, and side effects. This control helps contain misuse, reduce exposure, and keep agent behavior aligned with approved intent.
• Delegated AI Authority: Delegated AI authority is the permission a person gives an assistant to act inside business systems on their behalf. It turns a conversational tool into an execution layer, which means security teams must govern scope, auditability, and revocation with the same seriousness they apply to privileged access.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It helps security, IAM, and AI governance teams build the control model needed for non-human access paths.