Notifications
Clear all
Topic starter
14/08/2026 6:36 pm
TL;DR: Traditional DLP and DSPM break down once employees start moving sensitive data through AI assistants, personal AI accounts, connected repositories, and MCP servers, according to Orion. The practical shift is from predicting exfiltration paths to modelling data movement in context, because prevention now depends on identity, trust, and destination awareness rather than static policy alone.
NHIMG editorial — based on content published by Orion: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: How should security teams govern AI-assisted data movement across endpoints?
A: Security teams should govern AI-assisted data movement by starting at the endpoint, where content is opened, copied, transformed, and redistributed.
Q: Why do AI tools complicate traditional data loss prevention?
A: They complicate DLP because the sensitive event often happens inside the model, not at the boundary.
Q: What breaks when organisations rely on DSPM without prevention controls?
A: They can identify sensitive data, but they still cannot stop a risky transfer in the moment it happens.
Practitioner guidance
- Model AI-native exfiltration paths Map the specific ways data can leave through assistants, connectors, personal AI accounts, shared links, and unapproved MCP servers.
- Treat connected AI tools as governed identities Assign ownership, scope, and revocation criteria to every assistant, connector, and workflow that can read or relay enterprise data.
- Pair classification with contextual enforcement Use classification to identify sensitivity, then apply policy based on the user, destination, trust boundary, and current business context.
What's in the full article
Orion's full article covers the operational detail this post intentionally leaves for the source:
- The full exfiltration-path model with scenario-by-scenario traces for traditional and AI-native data loss routes.
- Representative incident examples and step-by-step movement traces that show how each path unfolds in practice.
- The enforcement-point view of where policy can block, detect, or redirect a risky transfer before data exits the environment.
- The framework’s mapping logic for source, destination, method, and trust relationship across enterprise workflows.
👉 Read Orion's data loss threat model for AI-native exfiltration paths →
AI-native data loss paths: what IAM and security teams are missing?
Explore further
14/08/2026 6:43 pm
Data loss governance now depends on identity-aware movement control, not just data visibility. DSPM can tell teams where sensitive data exists, but it cannot decide whether a transfer through an AI assistant, a connector, or a shared workflow is acceptable. The governance gap is no longer discovery alone. It is the absence of a control plane that understands who or what is moving the data, through which trust relationship, and to which destination. Practitioners should treat data movement as an identity problem as much as a content problem.
A question worth separating out:
Q: Who is accountable when an AI agent accesses sensitive data it was not meant to use?
A: Accountability sits with the team that approved the agent, its connectors, and its policy boundaries, not with the runtime behaviour alone. Organisations need ownership for intent, permissions, monitoring, and validation so they can prove whether the agent stayed inside its approved purpose. Without that, audit and regulatory response become retrospective guesswork.
👉 Read our full editorial: Data loss threat modelling is shifting for AI-native exfiltration
