Microsoft Purview helps you apply Microsoft 365 security and compliance controls (for example DLP, sensitivity labels, and auditing) to AI interactions and content. For enterprise AI agents, Purview is necessary but not sufficient because Purview does not control your agent’s execution path, tool selection, or privilege escalation.
Claw EA runs agents on OpenClaw as the baseline agent runtime, then adds permissioned execution using policy-as-code: WPC = Work Policy Contract (signed, hash-addressed policy artifact; served by clawcontrols), CST = scoped token (issued by clawscope), gateway receipts (from clawproxy), and proof bundles. This is the layer that makes “who did what, under which policy, with which authority” enforceable and auditable, instead of depending on prompt wording.
Step-by-step runbook
Below is an operational way to connect Microsoft Purview via official API with enterprise buildout controls, while keeping the agent permissioned and reviewable. The goal is to let the agent read what it must, gate write and admin operations, and leave behind verifiable artifacts.
-
Define the Purview blast radius per job. Decide which Purview areas the agent can touch (for example: read-only discovery versus configuration changes). List the specific data types and workloads in scope, and explicitly mark anything that is out of scope for agents.
-
Model your identity and privileges in Entra ID. Use a dedicated app registration or workload identity for the agent integration, and restrict Microsoft Graph permissions/scopes to least privilege. If write or admin operations are needed, require Privileged Identity Management (PIM) activation and align Conditional Access policies to the service principal and the operator path.
-
Write a WPC that encodes allowed operations. Put the Purview actions that are allowed into a WPC, including constraints like tenant, environment, and required approvals. Store the signed WPC in the WPC registry, and configure the runtime so policy hash pinning is used where you want the job to be immutable.
-
Issue CST for the job and bind it to the policy. For each run, issue a CST with a scope hash that matches the WPC and (optionally) a pinned policy hash. Use job-scoped CST binding to reduce replay risk across jobs and environments.
-
Route model calls through clawproxy. Run the agent so that LLM traffic is proxied by clawproxy, which emits gateway receipts for model calls. If you use OpenRouter via fal, keep it behind clawproxy so the receipts are generated consistently.
-
Connect Purview via official API under an approval gate. Implement the Purview tool as an enterprise buildout that only executes write and admin actions after WPC approval gates pass, and only with explicit least-privilege auth scopes. For higher risk operations, require a second party approval in your control plane before the tool is allowed to run.
-
Export a proof bundle and store the run artifact. At the end of the job, export a proof bundle that includes gateway receipts and run metadata, then store it for audit. For cross-team review, publish the run’s proof artifact into Trust Pulse for viewing.
Threat model
Purview touches governance and compliance controls, so small mistakes can have broad impact. The table below lists concrete failure modes for agent-based access to Purview, and the controls that should be enforced at the execution layer.
| Threat | What happens | Control |
|---|---|---|
| Prompt injection causes unintended Purview changes | The agent follows instructions embedded in email or documents and attempts to change DLP policies, labels, or investigation settings. | Permissioned execution: write and admin actions require WPC approval gates, and the Purview tool refuses calls that are not in-policy. CST scope hash is checked so off-policy calls fail closed. |
| Over-scoped Graph permissions | A misconfigured Entra ID app has broad Microsoft Graph permissions, so any compromise becomes tenant-wide. | Least privilege scopes, Conditional Access, and PIM for privileged operations. WPC lists required scopes and the runtime verifies the intended action matches the policy before execution. |
| Malicious or misconfigured plugin/tool | A tool claims to “query Purview” but also exfiltrates content, or quietly writes configuration changes. | OpenClaw tool policy allowlists and sandboxing reduce local blast radius, and WPC restricts which tool functions can execute. Proof bundles make later investigation concrete by showing what the agent actually called. |
| Replay of a previously valid job | A captured token or request is replayed to perform actions outside the original approval context. | Marketplace anti-replay binding using job-scoped CST binding. Jobs that do not match the intended binding are rejected. |
| Unverifiable “we think the agent did X” incidents | After an incident, you cannot prove which model calls occurred, or which policy version was in effect. | Gateway receipts from clawproxy plus proof bundles bind the run to model calls and policy identifiers. Verification can be done independently from the agent process logs. |
Policy-as-code example
Prompt-only controls fail because the agent can be convinced to ignore them, and because reviewers cannot reliably determine what was enforced at runtime. A WPC makes the rules machine-checkable and hash-addressed, so the job can be pinned to an exact policy artifact.
Example WPC-style constraints for a Purview tool (JSON-like):
{
"policy_name": "purview-agent-readmostly",
"policy_hash": "b64u:... (pinned by job where required)",
"actor": {
"entra_tenant_id": "00000000-0000-0000-0000-000000000000",
"service_principal_id": "11111111-1111-1111-1111-111111111111",
"conditional_access_required": true,
"pim_required_for": ["purview.write", "purview.admin"]
},
"tools": {
"allow": [
{ "tool": "purview.api", "actions": ["read:*"] },
{ "tool": "purview.api", "actions": ["write:dlpPolicy"], "requires_approval": true },
{ "tool": "purview.api", "actions": ["admin:*"], "deny": true }
],
"deny": [
{ "tool": "http", "reason": "no generic egress for this job" }
]
},
"data": {
"allow_sensitivity_labels": ["Public", "Internal"],
"deny_sensitivity_labels": ["Confidential", "Highly Confidential"]
},
"attestation": {
"require_gateway_receipts": true,
"emit_proof_bundle": true
}
}
What proof do you get?
For model calls, clawproxy emits gateway receipts that can be checked later to confirm which model was called, when, and under which job context. These receipts are designed to survive log shipping issues because they are separate signed artifacts.
At the job level, Claw EA produces a proof bundle that packages the receipts plus metadata such as the job identity and policy identifiers (including WPC hash). For audit and sharing, you can store the relevant artifact in Trust Pulse for viewing, without requiring investigators to access the live runtime.
Rollback posture
Purview-related failures should be treated like configuration incidents: contain first, then restore from known-good policy and identity posture. The table below focuses on actions your team can take quickly, and what evidence you should preserve.
| Action | Safe rollback | Evidence to keep |
|---|---|---|
| Suspected off-policy Purview write | Disable the agent job, revoke the CST, and revert Purview configuration via your standard change process. Re-run with a read-only WPC until the cause is confirmed. | Proof bundle, the WPC hash used, and gateway receipts for the time window. |
| Service principal permissions found too broad | Reduce Microsoft Graph permissions/scopes to least privilege, rotate credentials, and require Conditional Access checks. If PIM is used, tighten eligible roles and activation conditions. | Identity change records, affected job IDs, and the CST scope hashes issued during the exposure window. |
| Plugin/tool behavior is suspicious | Remove the tool from the OpenClaw allowlist and redeploy with a minimal tool profile. Only re-enable after code review and a new WPC that restricts the action surface. | Tool version identifiers, proof bundles from before and after, and any OpenClaw security audit output you captured. |
| Need to prove what happened to compliance | Freeze the run artifacts, verify the proof bundle, and share a Trust Pulse artifact for review. Do not rely on reconstructed chat transcripts as your primary evidence. | Verified receipts, the proof bundle, and the job-scoped CST binding context. |
FAQ
Is this a native Microsoft Purview connector in Claw EA?
No. Microsoft Purview can be connected via official API with enterprise buildout controls, and you should assume integration work is required for your tenant and your chosen Purview features.
Why do I need policy-as-code if Purview already has compliance controls?
Purview helps govern data and AI interactions, but it does not control which tools your agent executes or whether it attempts an out-of-scope write. WPC-enforced permissioning makes the execution layer fail closed, even when the prompt is manipulated.
How do you keep write and admin actions from happening accidentally?
Write and admin actions require WPC approval gates, CST, and explicit least-privilege auth scopes. If the job is not authorized for a specific action, the tool should refuse to execute it regardless of what the model requests.
What do auditors get that is better than logs?
Gateway receipts for model calls and a proof bundle for the job provide tamper-resistant artifacts tied to policy identifiers and job context. This makes it practical to verify what was executed without trusting a single log pipeline.
Does OpenClaw matter if we run agents somewhere else?
It matters because OpenClaw is the baseline runtime that enforces tool policy and optional sandboxing close to execution. Even if you later swap runtimes, the Claw Bureau primitives (WPC, CST, gateway receipts, proof bundles) give you a portable control plane for permissioned runs.