Use device management to restrict which endpoints can access approved AI services, require patching and inventory visibility, and block unmanaged browsers or devices from handling sensitive workflows. The goal is to stop data from leaving through an endpoint that cannot be inspected or governed. That makes containment possible before the prompt is sent.
Why This Matters for Security Teams
Managed endpoints are often the last policy-enforced layer before sensitive data reaches an AI service, which makes them the most practical control point for preventing leakage. If the device is unmanaged, outdated, or invisible to security tooling, policy cannot reliably tell whether the prompt contains regulated data, source code, or credentials. NIST Cybersecurity Framework 2.0 emphasises asset visibility and protective controls, which map directly to this problem when AI usage is happening from the endpoint.
The risk is not limited to accidental copy and paste. Attackers increasingly target compromised identities and exposed secrets to reach AI systems, and NHIMG research on the LLMjacking threat shows how quickly exposed AWS credentials are abused in the wild. NHIMG also notes in its 2024 State of Secrets Management Survey that secrets sprawl remains a persistent operational gap. In practice, many security teams discover endpoint-driven AI leakage only after a prompt has already left an uncontrolled device.
How It Works in Practice
Reducing ai data leakage from managed endpoints starts with defining which devices may reach approved AI services, then enforcing that decision at the endpoint, browser, and network layers. Current guidance suggests treating the managed endpoint as the trust boundary for AI use: if the device cannot be inventoried, patched, or monitored, it should not handle prompts containing sensitive data. That means tying access to device compliance, posture, and identity rather than relying on user discretion alone.
Security teams typically combine several controls:
- Device compliance checks before access, including patch status, disk encryption, and EDR health.
- Browser controls that block unmanaged browsers or profile separation that keeps corporate AI sessions distinct from personal browsing.
- Conditional access to approved AI services only, with logging of device identity, user identity, and service destination.
- Data loss prevention rules that detect regulated content before submission, especially where prompts may contain customer data or secrets.
- Allowlisting for sanctioned AI tools and explicit blocking of shadow AI endpoints that bypass review.
This is most effective when paired with lifecycle discipline from the NHI Lifecycle Management Guide and the broader recommendations in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, because endpoint controls fail fast when credentials, tokens, or browser sessions persist longer than intended. Anthropic’s report on AI-orchestrated cyber activity also reinforces that adversaries exploit normal workflow paths, not just technical vulnerabilities, so endpoint policy has to assume prompt content may be intentionally manipulated.
These controls tend to break down in hybrid and BYOD-heavy environments because device posture cannot be enforced consistently across personal browsers, remote sessions, and unmanaged operating systems.
Common Variations and Edge Cases
Tighter endpoint controls often increase friction for developers, analysts, and business users, so organisations have to balance leakage prevention against workflow speed. That tradeoff becomes more visible when teams need fast access to public AI services for low-risk tasks while still preventing regulated content from leaving the endpoint.
There is no universal standard for this yet, but best practice is evolving toward tiered access. High-risk data classes can be blocked outright from AI prompts, while lower-risk content may be allowed only from compliant managed devices. Some organisations also use isolated browser containers or dedicated AI workspaces, which reduce the chance that personal extensions, cached sessions, or unmanaged plugins can capture prompt data.
Edge cases matter. Remote contractors may have valid business need but insufficient endpoint control, and developers may route prompts through local tooling that bypasses browser policies altogether. In those cases, endpoint governance should be complemented by service-side controls, audit logging, and approved workflow design. NHIMG’s Top 10 NHI Issues and Guide to the Secret Sprawl Challenge both reflect the same operational reality: if the control plane does not know where data and identities are moving, leakage is usually discovered after exposure, not before.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Endpoint-leaked prompts often expose secrets and NHI misuse. |
| NIST CSF 2.0 | PR.AC-3 | Managed endpoint access depends on authenticated, policy-based access. |
| NIST AI RMF | AI data leakage is a governance and operational risk under AI RMF. |
Inventory and constrain NHI credentials so endpoint-driven AI workflows cannot reuse exposed secrets.
Related resources from NHI Mgmt Group
- How should security teams handle data leakage risks in AI models?
- How should security teams use DSPM to reduce oversharing risk in AI-enabled environments?
- How should security teams reduce open access risk in data governance programmes?
- How should security teams use data classification to reduce access risk?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org