Acceptance criteria
Enforce before submission, so a blocked payload is never sent and a denied tool call never runs. State where each decision is evaluated (device, browser or cloud), whether TLS interception, a forward proxy or a managed certificate is required, and whether each surface fails open or fails closed.
Why it matters
Where a decision runs and how it fails decide whether data is actually stopped.
How to verify
The vendor documents enforcement points and failure modes per surface, and the pilot confirms them.
OWASP adoption context
Enforcement points and failure behavior can differ by surface, so each listed context needs its own answer.
Framework mappings
A documented enforcement point and failure mode support secure-architecture and resilience decisions, and show whether data in transit is actually stopped. Neither fail-open nor fail-closed is right in every case; the buyer must choose per surface and test the behavior. SOC 2: CC6.7 supports restrictions on unauthorized data transfers. Tested fail-open/fail-closed behavior provides evidence for assessing disruption risks and selecting mitigation under CC9.1. The buyer must approve the trade-off and implement the response; documenting a failure mode alone does not establish a complete mitigation plan.
Knowing where decisions run and what happens when they cannot be made documents the control's deployment requirements and dependencies. It is readiness evidence, not proof of correct behavior under failure.