Microsoft Purview DSPM for AI vs Trussed AI: Visibility or Enforcement?

Two different questions about AI risk

AI data security posture management asks what exists and how exposed it is. Which AI applications are in use, what sensitive data do they reach, and where is the risk concentrated? The output is understanding: inventories, assessments and reports that let security teams prioritize work. Microsoft Purview DSPM for AI is a legitimate capability of this kind within the Microsoft ecosystem, and visibility of this sort is a necessary starting point for any AI security program.

Runtime policy enforcement asks a different question: what happens to this specific request, response or tool call, right now? A control in the execution path evaluates the interaction as it occurs and decides whether to allow it, redact part of it, block it, rate limit it or escalate it for human approval. The output is an action, plus a record of why that action was taken.

The distinction matters because a report that identifies exposure does not by itself change what an AI system does in the next second. Purview also includes DLP and information protection controls. A NIST zero trust practice guide describes Purview Information Protection as discovering, labeling, classifying and protecting data, and Purview DLP as reducing the risk of unauthorized disclosure. How those controls apply to each AI surface, such as Microsoft 365 Copilot, third-party AI apps, agents and custom applications, should be assessed surface by surface.

Posture visibility and runtime enforcement side by side

The table compares the two capability categories, not product feature lists. Any product, including those named here, should be placed on these axes using its own current documentation.

• Primary question: Visibility: what AI activity and data exposure exists? Enforcement: what should this interaction be permitted to do?
• Unit of analysis: Visibility: applications, data stores, users and aggregate risk. Enforcement: individual interactions and tool calls.
• Typical actions: Visibility: discover, assess, monitor, report. Enforcement: allow, redact, block, rate limit, escalate for human approval.
• Position in the architecture: Visibility: alongside AI activity, observing it. Enforcement: in the execution path, deciding on it.
• Evidence produced: Visibility: posture reports and risk assessments. Enforcement: a per-decision record of policy applied and action taken.
• Failure mode if used alone: Visibility: known risks remain unmitigated at runtime. Enforcement: coverage depends on knowing which surfaces to put in the path.

Where Trussed fits

Trussed is built for the enforcement side of this table. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Policy is enforced at runtime, not reviewed after the fact, and it applies to individual interactions and tool calls with these outcomes: allow, redact, block, rate limit, or escalate for human approval. Trussed also provides code provenance, covering the origin, licence and security context of code.

Evidence is generated by the enforcement itself. Each decision produces audit-ready evidence that is mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. Trussed is self-managed in the customer cloud, with configurable retention and data residency. Operationally, it has run 18+ months in continuous production in a regulated enterprise at 99.95% uptime on live traffic, with 100+ models under one policy plane.

Trussed is not a posture or discovery product, and it does not replace one. It does not currently provide business transaction identity, model or dataset provenance, or end-to-end tracing of agentic workflows.

What each approach gives an auditor

Governance frameworks distinguish between a policy that exists and a policy that is implemented effectively. NIST AI RMF Govern 1 states that policies, processes, procedures and practices for mapping, measuring and managing AI risks should be in place, transparent and implemented effectively. Govern 1.1 adds that legal and regulatory requirements involving AI are understood, managed and documented.

Posture reporting supports the understanding and documentation part of that outcome. It shows where AI is used, what data is involved and what risk was assessed. Runtime enforcement supports the implementation part. A decision record shows that a specific policy was applied to a specific interaction and what action followed. These are different artifacts, and a regulated enterprise often needs both.

Retrievability matters as much as generation. Under the EU AI Act, a provider that considers an AI system not high-risk should document that assessment and provide it to national competent authorities on request. Regulation (EU) 2024/1689 is dated 13 June 2024, and obligations differ by role, so as of October 2026 each organization should confirm which duties apply to it. Whatever the framework, evidence that cannot be exported, retained for the required period and tied to a documented requirement is of limited use in an examination.

Complementary, overlapping or sequential

In most architectures the two approaches are sequential first and complementary afterward. Discovery and assessment come first because enforcement can only be designed for surfaces and data flows you know about. Findings from posture work then inform policy design: which data classes must be redacted, which tool calls need human approval, which workloads need rate limits. Enforcement then applies those decisions to each interaction, and the evidence it produces can be checked against the posture picture.

Overlap exists where a data protection control can also block or restrict an action on a given surface. Where that is documented and sufficient for your requirements, you may not need a second enforcement point there. Gaps appear where AI activity crosses surfaces, such as agents calling tools or MCP servers, or where policy must differ by interaction rather than by data label.

The practical decision is therefore not which product to choose, but which control gaps your posture work reveals and whether policy must be applied to the action itself. If the answer is yes, and a regulator or auditor will ask what your AI was allowed to do, enforcement in the execution path belongs in the architecture alongside posture visibility.