AI Agent Data Access Control: DSPM, DLP, Authorization, or Sandbox? Microsoft Purview, BigID, Cyera, Permit.io, OpenShell

When a security team is asked "how do we let AI agents use our data safely," the answer usually arrives as a product category: DSPM, DLP, an authorization service, or a sandbox. Each is the right answer to a different question. The risk is buying one and assuming it covers the others.

This post sorts the layers by the question each one answers, and then names the question that tends to fall between them.

Four layers, four questions

Layer	Question it answers	Typical output
DSPM (data security posture management)	Where is sensitive data, how is it classified, and who can reach it?	Inventory, classifications, over-permissioned access findings
DLP (data loss prevention)	Is this data about to leave through a channel we control?	Block, warn, or redact on a monitored path
Authorization	Is this subject allowed to perform this action on this resource?	Allow or deny, often with an audit record
Sandbox / runtime isolation	What can this running process touch?	Filesystem, network, and process limits

None of these is redundant with another. A sandbox does not know which file is Confidential. A DSPM tool does not decide whether a particular Kubernetes job may receive it. Authorization can say yes to a tool call without knowing what the returned object contains.

What each layer contributes to agent access

DSPM: the source of classification and exposure context

Vendors in this space describe sensitive-data context as a core output. BigID describes data access governance for employees and AI agents, including inherited access and remediation, and Cyera combines data security posture with AI security. For an agent program, the valuable output is a trustworthy label and a picture of who and what can reach each object.

DLP and endpoint controls: watching data in motion

Microsoft extends Purview sensitivity labels, DLP, auditing and Entra identity controls into supported agent experiences, per its Agent 365 security documentation. That is a strong fit when content, identities and agents all live in the Microsoft ecosystem. Endpoint-oriented products, such as Cyberhaven, publicly position around observing the data agents touch and enforcing block, warn or redact controls.

Authorization: the decision point

Policy-as-code and fine-grained authorization services evaluate requests against rules and keep an audit trail. Permit.io, for example, provides authorization for applications and agents, including an MCP gateway that evaluates tool calls. This layer is closest to "make a decision," which is why teams reach for it first.

Sandbox: where the decision is enforced

NVIDIA OpenShell and similar runtimes confine a process with filesystem, network and process policy. A sandbox enforces what it is configured to enforce, no more.

Product details change quickly. Treat the links above as starting points and verify current capabilities against each vendor's documentation.

The question between the layers

Put the four together and a specific question remains:

For this object, with this classification, requested by this user for this task, what representation may this agent receive in this runtime, and can that runtime actually enforce the controls required?

Answering it takes a chain no single layer owns:

1. Read the object's effective classification (DSPM, DLP labels, or the source system).
2. Confirm the requesting user's current entitlement (the source system).
3. Apply the organization's agent data-handling rule (a policy decision).
4. Check the target runtime's capabilities (the sandbox or platform).
5. Emit the runtime's native configuration and a data-release decision.
6. Record the facts, rule version and outcome for later review.

Steps 3 to 6 are the gap. Teams fill it with scripts, a spreadsheet of rules, and reviewer judgment. It works for the first workload and does not scale to the tenth.

A practical way to choose

You probably do not need to replace anything. Ask these questions of what you already own:

1. Does it evaluate the requesting user, the agent identity, or both?
2. Does it read object-level classification, not only folder or application-level?
3. Is policy checked before raw data enters the runtime?
4. Can it choose among raw, derived, metadata-only, and denied?
5. What happens when the runtime lacks a required control?
6. Can credentials stay outside the agent environment?
7. Are decisions versioned and reproducible?
8. Can you test that the generated policy blocks a forbidden action?

Where the answers are "no" or "unknown," that is the work to fund, regardless of which vendor name is on the existing contract.

Where ContextIQ fits

ContextIQ Agent Data Policy is an Enterprise Preview that targets steps 3 to 6: consume classifications and entitlements from the systems you already trust, apply your agent rule, check runtime capability, produce runtime-native controls, and return evidence. It is designed to sit alongside DSPM, DLP, an identity provider and a sandbox, not replace them. Google Drive to NVIDIA OpenShell is the initial validation path; additional sources and runtimes are planned.

If you have a classified repository and a real agent task that still needs manual review, request an Enterprise Preview demo. We can also help you reason about which agent-facing surfaces a workload exposes: the Agent Protocol Inspector shows which MCP, A2A and ARD endpoints a service advertises, which is a useful input when you decide where the decision point should go.