DSPM for AI: Where Data Posture Ends and Request Enforcement Starts

A DSPM scanner finds a payroll file in SharePoint and marks it sensitive. It also shows that a broad employee group can read it. An AI assistant can now reach the same repository. The finding begins with the data and follows its access path. It then gives an owner a remediation job. That is the posture mechanism.

The next control point appears when an authenticated user or agent sends content to an LLM. Repository posture can inform the choice to allow or block after any required redaction. A request-path control makes that decision. DSPM for AI and request enforcement operate on different objects at different times.

TL;DR

• DSPM for AI starts with sensitive-data discovery and classification. It maps access paths and exposure across repositories, SaaS, cloud, AI apps, and agents.
• AI activity and DLP matches depend on the sensors and policies in scope. The same applies to audit events and captured prompts or responses, with integrations, auditing, and licensing also affecting coverage.
• DSPM drives remediation through labels, permissions, DLP, ownership, and investigation. It remains a posture and data-control layer.
• Inline enforcement separately decides if a routed HTTP model request is allowed for this authenticated caller and content under the applicable model and policy.

DSPM starts with the data

Microsoft's current Purview DSPM documentation describes continuous scanning for sensitive data and risk assessment. It also describes recommendations to reduce exposure across Microsoft 365, Azure, Fabric, third-party SaaS, and IaaS. The center of gravity is the data itself: its location and access, along with its use and protection.

That object choice separates DSPM from AI security posture management. AI-SPM inventories an AI estate that can include models, endpoints, agents, notebooks, credentials, configurations, and reachable data. DSPM begins with sensitive data and its exposure. AI connections become another way that data can be reached or used.

The practical output is a data graph with findings attached. A security team should be able to select a repository and see the sensitive classes present. It should also identify who can reach them, connect relevant AI activity, and assign the exposure to an owner. The graph earns its value when someone can close a permission or apply a label. It should also support changing a DLP rule or investigating an interaction.

Discovery and classification

The first mechanism scans repositories and services for data. Classification gives those objects policy meaning, such as personal and financial information, health and source-code information, or confidential business information. Access analysis then shows identities and groups with a path to the classified object, including applications or agents.

Coverage is conditional. A scanner sees the services and tenants it can connect to, under the permissions and product scope configured for it. That qualification belongs in every architecture diagram. A glossy "all enterprise data" bubble hides the connectors and identities that determine the real boundary, along with the repositories.

I would reject any DSPM rollout that celebrates a sensitivity heat map before assigning owners to its findings. A dashboard full of red squares is a backlog rendered in color. The working artifact needs a repository and classification, plus an access path and evidence. It also needs an accountable owner, corrective action, and retest state. Without those fields, discovery produces awareness while the exposure stays open.

Access-path graphing

Classification answers what the data is. Access-path graphing answers who or what can reach it. For AI use, that second answer has several forms. A human can open a file and paste content into a prompt. An agent can retrieve the file through an approved connector. An application can read the repository before building an LLM request.

The graph helps a reviewer find excessive access and inherited permissions. It can also show that an AI identity reaches sensitive material through a group or application grant, including a repository connector. Remediation belongs at the source when the access itself is excessive. Remove the group membership or narrow the permission. Correct the label or change the connector scope.

Request enforcement begins later. Once an application has assembled an HTTP request, the gateway can evaluate the supplied identity and data classification against the destination and policy. The SharePoint permission that allowed the application to read the file remains a DSPM exposure finding and repository fix.

AI activity correlation

The current Microsoft Purview surface includes AI-app and agent dashboards plus activity monitoring. It also includes DLP signals, audit logs, and investigation tooling. Its documented activity events include AI interactions and AI-site visits, along with DLP matches and sensitive-information detections. Prompt and response capture can depend on auditing and collection-policy configuration.

Those signals connect data posture to observed use. An investigator can start with a sensitive item or DLP match and examine the related AI activity available to the product. This is stronger than a static repository scan because it adds evidence that an interaction occurred.

The signal still reflects collection scope. Microsoft's DSPM considerations and prerequisites describe Edge policy for some AI apps and onboarded devices or browser controls for third-party sites. They also describe Purview SDK integration for Entra-registered apps, auditing, licensing, and optional content-capture policies. A missing event may mean no interaction occurred, or it may mean the required sensor or policy was absent. Coverage evidence has to travel with the finding.

Remediation stays close to the exposure

DSPM remediation changes the condition that created data risk. Labels classify and protect content. Permission changes narrow access. DLP rules detect or restrict handling. Investigations connect events to a response. The right action depends on whether the finding concerns the data object or an identity path. It may instead concern an application integration or an observed interaction.

The runtime decision operates on a single model call. If an engineer sends classified source code to an unapproved LLM through a controlled HTTP route, inline policy can block that request before inference. Broad read access to the repository still needs an ACL change at the data source. DSPM can provide classifications, owners, exposure findings, and remediation priorities. A stable identifier avoids a brittle translation between "confidential-source" in the data catalog and "restricted-code" at the gateway.

The precise request-time boundary

Follow one model call. An authenticated employee asks an internal assistant to summarize a document. The application retrieves content and creates the prompt. It then attaches identity and classification context before sending an HTTPS request through an enforcement point. The policy decision can check the caller's role and the classified content against the approved model and active rule before forwarding the call.

This control covers traffic deliberately routed through it. It can leave a per-decision record with the supplied identity and classification, plus the destination and policy version. The record also contains the action and timestamp. AI policy enforcement at the HTTP layer explains that mechanism.

Snowflake and SharePoint scanning sit outside the proxy, as do Databricks and SaaS repository scanning. DSPM or repository controls handle oversharing and AI application discovery, including vendor-embedded interactions beyond a customer-controlled HTTP route. Browser interactions and direct provider calls also require their own controlled path. DSPM coverage and gateway coverage should be documented separately, then joined through common identities and classifications.

DSPM and AI-SPM remain distinct

DSPM and AI-SPM can appear in the same product or program, which makes the labels tempting to merge. Their primary objects keep the distinction clear. DSPM asks where sensitive data lives and who can access it. It also asks how the data is used and which exposure needs repair. AI-SPM asks which AI assets exist and how they are configured. It then identifies which data they can reach and which posture findings belong to those assets.

An agent connected to a customer-record repository appears in both views. DSPM starts at the records and traces exposure to the agent identity. AI-SPM starts at the agent and maps its model endpoint and configuration, including credentials and reachable sources. Runtime enforcement then evaluates a specific routed model request. AI agent observability covers the wider evidence required across agent actions and systems.

No single layer has the whole event. The data record and agent configuration may live in different systems, as may repository access, the HTTP model call, and the subsequent action. Stable identifiers connect those records without pretending one control owns every step.

A coverage review that exposes gaps

Run a DSPM-for-AI review with one sensitive object and one known AI interaction. Place the repository record and classification on the same sheet as the access path and activity event. Add the DLP signal and remediation ticket, plus any routed request record. A thin printout with six timestamps will reveal more than a feature matrix.

Check the prerequisites beside the evidence. Was the device onboarded? Did the browser policy apply? Was the application integrated through the required SDK? Was auditing active? Did a collection policy capture content? Which license enabled the signal? Microsoft's documentation makes those dependencies part of the coverage model rather than background implementation detail.

Then name the absence. A missing repository means discovery coverage is incomplete. When the activity event is absent, collection scope deserves review. The request record may be missing because traffic bypassed the controlled route or never used it. Each gap has a different owner and corrective action.

DeepInspect

DeepInspect covers the request-time enforcement slice that follows data posture. It sits between authenticated users or agents and HTTP-based LLM endpoints. For deliberately routed traffic, it can evaluate supplied identity and data classification against the approved provider and model under the applicable policy. It can then allow or block the request after any required redaction before the request reaches the LLM. The decision produces an independent audit record.

Repository scanning across Snowflake and SharePoint sits outside DeepInspect, as does scanning across Databricks or third-party SaaS. DSPM provides the data map and ownership. It also provides asset discovery, exposure findings, and remediation work. DeepInspect applies policy when a classified request crosses its customer-controlled HTTP enforcement boundary.

Book a technical deep dive at deepinspect.ai.