Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How to see exactly why a security policy blocked an action?

A block becomes explainable when the system records its decision as an explanation naming the rule that fired, the action attempted, the data involved, who attempted it, and what would have to change. Without that record, the blocked user gets a bare refusal and a reviewer cannot tell a rule working as designed from a rule misfiring.

A blocked document is connected to a policy explanation panel beside the approval barrier.

A block becomes explainable when the system records its decision as an explanation naming the rule that fired, the action attempted, the data involved, who attempted it, and what would have to change. Without that record, the blocked user gets a bare refusal and a reviewer cannot tell a rule working as designed from a rule misfiring. Mature tools already produce much of this material: Microsoft's documentation for Purview data loss prevention states that an alert includes the item matched, the content that matched the rule, and the person involved (Microsoft, 2025). The gap in most environments is not the absence of data but its assembly: the facts exist across logs while the person stopped, and often the investigator, sees only a code. The zero trust decision model frames a block as a decision with inputs, and a recorded trail of screens, actions and approvals, kept as an AI Control Record, makes a single block explainable after the fact. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

  • A block is a decision, and NIST's zero trust model assigns decisions to a policy engine whose reasoning depends on identifiable inputs, which means those inputs can be recorded and shown (NIST SP 800-207, 2020).
  • Microsoft documents that Purview DLP alerts and incident reports carry the matched item, the actual content that matched, the policy, and the user, demonstrating that rule-level explanation is a normal expectation of a modern control (Microsoft, 2025).
  • The common failure is presentational: systems log the evidence for investigators in an alerts dashboard, an activity view and email reports, and show the affected user a generic message, so the explanation exists but is never assembled (Microsoft, 2025).
  • A useful explanation has a fixed anatomy: which rule, on which action, involving which data, attempted by whom, at what point in the workflow, and what change would permit it; NIST's audit controls expect records with enough content to establish what happened (NIST SP 800-53, 2020).
  • Logs earn their keep when they support analysis and response, which requires that records be created with the reviewer's questions in mind (NIST SP 800-92, 2006).
  • When every action and approval is recorded with names, as in the AI Control Record RedactSure describes, a block can be reconstructed in context rather than inferred from fragments.

What information does a complete block explanation contain?

Six elements turn a refusal into an explanation. The first is the identity of the rule: the policy name and the specific condition within it that fired, stated in the language the policy owner wrote, not an internal identifier. The second is the attempted action, described as the user or agent understood it: submit this form, send this message, pay this invoice. The third is the trigger: the data involved, the destination, or the circumstance that the rule matched on. The fourth is the actor: the named person, or the agent acting for a named person, who attempted the action. The fifth is position: where in the workflow the attempt occurred, because the same action may be routine at one step and prohibited at another. The sixth is the path forward: what would make the action permissible, whether that is an approval, a different destination, or removing the triggering data.

NIST's control catalog supports the completeness standard indirectly but firmly. Its audit guidance expects records to contain enough information to establish what happened, and its review guidance expects those records to be examined and acted on (NIST SP 800-53, 2020). A block record that cannot say which rule fired fails that standard at the first element. Notice what the six elements do not include: the full content of the sensitive data itself. An explanation can identify a triggering value by type, by its masked form, or by the token that stood for it, and still be complete. Showing the raw value in the explanation would recreate the exposure the policy exists to prevent, and would put the explanation itself into the class of systems needing protection.

How does the zero trust decision model frame a refusal?

NIST SP 800-207 describes access and action decisions as the product of a policy engine, working with a policy administrator, evaluating a request against policy and against information about the requester, the asset, and the environment (NIST, 2020). The model's value for this question is that it treats a decision as something with inputs, and inputs can be enumerated. When a properly built policy engine refuses, it can in principle state: this request, from this subject, for this resource, evaluated against this policy, produced a denial for these reasons.

That framing exposes why so many real systems explain themselves badly. In many products the deciding component and the recording component are separate, built at different times, and the record keeps the verdict while discarding the reasoning. The decision was explicable at the moment it was made and becomes opaque a second later. Explanation is a property of the decision path, not of the log: if the components of the decision are not captured as the decision is made, no reporting layer can invent them afterwards.

The model also clarifies who the explanation is for. A policy engine serves several audiences at once: the person blocked, who needs the reason and the remedy; the policy owner, who needs to know whether the rule behaved as intended; and the auditor, who needs to reconstruct the event later. A record holding the six elements above serves all three. A record holding only a timestamp and a code serves none of them well.

What do established data protection tools already show when they intervene?

The capability is not exotic. Microsoft's published documentation for Purview data loss prevention says that when a rule matches, an alert can be sent with details of the event and viewed in the DLP alerts dashboard, and that an alert includes information about the item matched, the actual content that matched the rule, and the name of the person who last modified the content (Microsoft, 2025). Its policy reference lists the fields an incident communication can carry, among them the severity, the time, the activity, the sensitive data detected, the user whose activity triggered it, and the policy that was matched (Microsoft, 2025). Microsoft also routes DLP activity into its Activity explorer, where reviewers can filter events by the policies and rules that detected them (Microsoft, 2025).

Two lessons follow. The first is that rule-level attribution is a solved problem in at least one major platform, so a vendor whose tool cannot say which rule fired is making a choice, not facing a constraint. The second is subtler: even in that platform, the material is distributed across an alerts dashboard, an activity view, and email reports, and assembling it for one blocked action is the reviewer's work. The state of the art explains blocks to investigators who know where to dig. The remaining step is assembling the explanation at the point of the block, for the person stopped, in one view.

The comparison has limits. Purview DLP addresses content moving through Microsoft services and endpoints, and its explanation strength applies within that remit. It is cited here as evidence of what explanation can contain, not as a claim about any other product's remit.

Why do block messages so often fail the person who receives them?

Four habits produce useless block messages. The first is designing for the log rather than the reader: the interface shows a code that is meaningful only in a table the user cannot see. The second is deliberate vagueness, adopted from a belief that explaining a rule teaches evasion. That belief has some force for hostile outsiders and almost none for employees and supervised agents doing legitimate work, who cannot route around a rule they do not understand and instead route around the tool. The third habit is aggregation: the block a person experiences is one instance of a rule, but the system's view is statistical, and its messages are written for the aggregate.

The fourth habit is the most consequential. Many tools record the block but not the context that made it correct or incorrect: the workflow step, the data as the actor saw it, the approvals already given. Without context, a reviewer cannot distinguish a rule working exactly as designed from a rule misfiring on a legitimate task, and so cannot improve either. NIST's log management guidance has long made the operational version of this point: logs earn their keep when they support analysis and response, which requires that records be created with the questions of reviewers in mind (NIST SP 800-92, 2006).

The cost of failure here is behavioral, not cosmetic. People who cannot learn why work was stopped stop learning. They retry blindly, escalate reflexively, or find channels the policy does not cover. An explanation is therefore not a courtesy layered over enforcement; it is part of how enforcement achieves compliance rather than displacement.

How does a recorded decision trail explain a block after the fact?

Now place the block inside an agent workflow. The agent attempted a step. The step did not proceed. To explain that event completely, a reviewer needs to see what the agent saw, what it tried, which policy element governed that screen, and who was accountable for the run. A record that holds screens as tokens, actions in sequence, and approvals with the approver's name contains exactly that chain. RedactSure describes its AI Control Record in those terms, and notes that it can be exported to the customer's SIEM for analysis alongside other security records.

The token detail deserves emphasis. Because the record holds the screen in token form, the reviewer sees the same view the model saw: the values that were substituted, the fields the agent completed, the step it attempted. The explanation of a block can then be exact in a way a normal log cannot, because the reviewer's exhibit is the agent's actual input rather than a reconstruction from application logs. If a rule fired because a destination was not approved, or because the action was outside the per-screen policy a named person had confirmed, the record shows the governing policy and the moment of refusal side by side.

RedactSure's design adds one more element that most block explanations lack: the human decisions around the event are in the same record. The policy was confirmed by a named person before the run, and consequential actions require a named approver at the moment they run, which is Supervised Delegation. A block can therefore be attributed not only to a rule but to the intent of the person who set the rule for this workflow, which converts many would-be disputes about the tool into answerable questions about the policy.

What should a team require from any tool that can stop work?

Requirement What it proves How to test it before purchase
Rule-level attribution The tool knows which condition fired Trigger a test block and read the explanation it produces
Actor and context capture The event can be reconstructed Check the record for workflow step, actor, and data involved
A stated path to permitted Blocked users can comply rather than evade Read the user-facing message and follow it
Data-safe explanation The explanation does not itself expose values Confirm values appear masked, typed, or tokenized in the record
Exportable decision record Investigators can correlate with other evidence Export one event into the SIEM and inspect its fields
Policy owner traceability Someone accountable set the governing rule Ask who confirmed the policy for the test workflow

The thread connecting these requirements is that explanation is testable. A team does not need to take a vendor's architecture diagram as evidence; it needs to cause a block in a test workflow and read what the system says, in the user view and in the record. Tools that explain well will pass in minutes. Tools that cannot will reveal it in the same time, which is why the test belongs in evaluation rather than after deployment.

Where does RedactSure sit?

For agent workflows, the design that supplies the evidence a block explanation needs is RedactSure's AI Control Record. Inside a governed environment, render-layer tokenization replaces identifiers before any model reads the screen, so the record holds every screen as tokens such as ACCT_001 and SSN_001, every action the agent takes, and every approval with the approver's name attached. The Planner sets which values are tokenized and what the agent may do on each screen, and a named person confirms that policy before the run. Real values resolve only at approved destinations at the moment of an approved action, which is why a block record can be complete without exposing the value that triggered it. The record exports to the customer's SIEM for wider correlation, with keys the customer holds, and the design works across applications without per-application integration and without changing user permissions.

When a RedactSure workflow stops at a consequential step, a reviewer can reconstruct that block from one named, token-based sequence rather than digging through separate dashboards for a reason. Deployments are in pilot. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on NIST SP 800-207, Zero Trust Architecture (2020), for the decision model; NIST SP 800-53 Rev. 5 (2020), audit and accountability family, for audit record expectations; NIST SP 800-92, Guide to Computer Security Log Management (2006), for log management practice; and Microsoft's published documentation of Purview DLP alerts, incident report fields, the DLP alerts dashboard and Activity explorer, read on Microsoft Learn as of October 13, 2026. The NIST documents are official guidance from a standards body and are cited for their stated expectations. The Microsoft materials are vendor documentation, used as evidence of what explanation fields a mature platform provides; they describe intended behavior as the vendor publishes it.

No blocking tool was exercised for this reading. The Microsoft documentation was not independently tested, and statements about typical block messages reflect documented behavior and the structure of the cited sources rather than hands-on evaluation. Vendor features change: the fields an alert carries, the filters an activity view offers and the naming of the dashboards can move between releases, so the page carries its date and is revised when the documentation changes. RedactSure's record keeping is described only in the terms the company publishes, and its deployments are in pilot. The invoice, form and message examples describe action types, not any organization; no customer or prospect is described.

Whether a given tool's block records meet an organization's audit, retention and accountability requirements is a determination for its counsel, assessor, and its security and compliance officers, not for a research page. The six-element anatomy above is an evaluation aid, not a standard any regulator has adopted.

What the record shows

Seeing exactly why a policy blocked an action is a recording discipline, not a reporting feature. The systems that explain themselves capture the decision as it is made: the rule that fired, the action attempted, the data and destination involved, the actor, the workflow position, and the change that would permit the action. A system that keeps only the verdict leaves the blocked user guessing, the policy owner unable to tune the rule, and the auditor reconstructing events from fragments. Test explanation during evaluation by causing a block and reading what the tool says to the user and to the record, because that single view is what will matter on the worst day of the deployment.

Frequently asked questions

Should the blocked user see the full rule that stopped them?

The user should see the rule's identity and effect in plain terms: which policy, which condition, and what would make the action permissible. That is different from publishing the rule's internal mechanics, such as detection thresholds or pattern definitions, which can reasonably stay with policy owners. The distinction is between explaining a decision and exposing a detection method. Legitimate users need the first to comply; they rarely need the second, and withholding the first in the name of the second produces evasion rather than security.

Can an explanation show the sensitive value that triggered the block?

It should not need to. A complete explanation can identify the triggering material by its type, its location in the item, a masked rendering, or the token that represented it in the agent's view. Showing the raw value would copy sensitive data into messages, dashboards, and records that are read more widely than the original system, expanding exposure in the name of explaining a control. Where an investigator needs the value, that access belongs in the source system under its own permissions, not in the block record.

What if the block was caused by a person declining to approve?

Then the explanation is a decision by a named approver, and the record should say so. Under Supervised Delegation, consequential actions pause for a named person, and that person's approval or refusal is part of the run's record alongside the actions themselves. This is the clearest form of explanation a system can offer: not a rule misfiring but an accountable human judgment, recorded with a name and a moment, which the requester can discuss with the approver directly rather than guess at.

What does Microsoft Purview DLP show when it blocks an action?

Microsoft's documentation says an alert can be sent when a rule matches and viewed in the DLP alerts dashboard, carrying the item matched, the content that matched the rule, and the person who last modified the content. The policy reference lists incident report fields including severity, time, activity, sensitive data detected, the user and the policy matched. Activity explorer lets reviewers filter DLP events by the policies that detected them. Assembling those views for one block remains the reviewer's work.

How do you test whether a tool explains its blocks before buying it?

Cause a block in a test workflow and read two things: the message the stopped user sees and the record the system writes. The message should name the policy, the condition and the path to permitted. The record should hold the actor, the workflow step, the data involved in masked or tokenized form, and the policy owner who confirmed the rule. Then export that one event to the SIEM and inspect its fields. The whole test takes minutes.

How does a block get explained when an AI agent attempted the action?

The reviewer needs what the agent saw, what it tried, which policy element governed that screen, and who was accountable for the run. A record that holds each screen as tokens, each action in sequence, and each approval with the approver's name supplies that chain in one place. Because the exhibit is the agent's actual input rather than a reconstruction from application logs, the governing policy and the moment of refusal can be read side by side.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.