# GRD-013: Support monitor, warn, block, and restrict actions


- Area: Runtime Guardrails

- Verification: Live test
- OWASP adoption tier: AT1–AT4
- Formerly: DAT-003
- URL: /r/GRD-013

**Acceptance criteria:** Set the action per policy and let the policy owner configure the intervention choices and block-page wording including removing any bypass, and record both the evaluation and the action. Support a monitor-first rollout. Where policy permits a user to proceed after a warning, require a business justification before continuing. Do not offer an override where policy disables bypass.

**Why it matters:** A control that can only block drives work onto personal devices. Graduated actions let policy match the risk.

**How to verify:** Pilot users see monitor, warn and block outcomes with your wording, and each action is logged. For a warning policy that permits proceeding, show that the user must enter a business justification before continuing. For a blocking policy configured with no bypass, show that the user cannot override the block.

**OWASP adoption context:** Intervention options are relevant across ordinary employee AI and connected-agent workflows, but each surface may support different monitor or enforcement actions.

**Mappings:**
- NIST CSF 2.0: PR.DS-02 — Configured block or restrict actions can protect data in transit when they act before egress. Monitor and warning modes do not establish enforced prevention.
- NIST AI RMF: MANAGE 1.3; ISO 42001: A.9.2 — Owner-configured interventions translate documented AI risk responses and responsible-use rules into operational choices. Their effect depends on the selected action; monitor-first rollout does not imply blocking.
- OWASP ASI: ASI02 — Policy-controlled interventions can limit agent tool misuse when applied to the tool action itself. General prompt monitoring does not establish that unsafe tool invocations are constrained.
- SOC 2: CC5.3, CC6.7; ISO 27001: Cl. 8.1, A.8.12, A.8.15 — Configurable interventions operationalize data-handling policy, and evaluation/action records provide an event trail. To prevent disclosure, restrictive actions must be enabled and tested before transfer; monitoring and warnings do not prevent egress.
ISO/IEC 27001: A.8.12: Use an active, approved leakage-control workflow at the stated data boundary; classification alone is insufficient. If claiming blocking, demonstrate it before egress. A.8.15: Keep attributable event records with appropriate retention, protection and analysis; a live view is insufficient. Policy approval, rollout criteria and exception ownership remain organizational responsibilities.