Distinguish a hard block from a user override
A message labeled blocked may still offer a permitted continuation. Evaluate the action a user can complete, not just the wording of the notification. Warning, justification, redaction and unconditional restriction solve different policy requirements.
For Security policy owners and technical evaluators
Two fictional cases with different policy decisions
A team allows justification for a low-risk fictional document but requires prevention for a separate synthetic restricted fixture. The same evaluator checks both rules on an approved test device.
What you are working with
- A vendor-approved synthetic fixture assigned to a rule that requires unconditional submission prevention.
- A separate fictional example assigned to a rule where a documented user exception is acceptable.
- A written decision table distinguishing allow, warn, override, redact and block for this pilot.
A safer approach
- Confirm which actions the evaluated product actually supports before preparing the policy comparison.
- Use only visible, authorized continuation controls; this is policy validation, not an attempt to bypass endpoint security.
- Record final submissions and available evidence without assuming that justification text or every user action is logged.
Expected outcome: An evaluator can demonstrate the intended distinction between a prohibited send and a permitted exception, including what the user is told in each case.
Work through the procedure
Write the required outcome
Translate policy language into an observable result. For an unconditional restriction, define what must not reach the destination. For an exception, identify who may continue and what review is required. Avoid treating an interface label as the policy specification.
Trigger the configured actions
Run each synthetic case with its agreed rule on a fixed provider and browser combination. Read the full message and identify all presented controls. Note whether closing a dialog cancels the submission, leaves it pending or permits another documented action.
Complete the permitted paths
Exercise the ordinary actions allowed by the interface, including cancel and any authorized override. Inspect the resulting conversation where appropriate and record the actual outcome. A redacted submission should be checked for its sanitized content rather than counted as an unchanged allowed send.
Review exception evidence
Inspect whatever policy events the product makes available and compare them with your worksheet. Establish which facts can support an exception review. If an expected field is absent, agree another evidence process or revise the policy requirement instead of assuming collection.
What to check before proceeding
1. Unconditional restriction
- Ready when
- The prohibited action cannot continue through the evaluated interface's ordinary user controls.
- If the check fails
- Do not label the rule a hard block; investigate its configuration and supported behavior.
2. Permitted exception
- Ready when
- Only the agreed exception path proceeds and its instructions are clear to the test user.
- If the check fails
- Correct the policy or user message before making the exception available broadly.
3. Reviewability
- Ready when
- Available evidence is sufficient for the review obligation defined in the decision table.
- If the check fails
- Add a separate approved review process or choose a policy that does not depend on unavailable evidence.
Common mistakes to avoid
- Calling a warning with a Continue button an unconditional block because the initial notification uses restrictive language.
- Assuming every restriction needs an override, even when the approved policy requires the data to stay out of the AI service.
Evaluate this workflow with Aona
Where Aona can help
Ask Aona to demonstrate the supported policy actions on your synthetic cases and confirm how any exception workflow is evidenced.
What to confirm
Do not infer arbitrary approval chains, justification fields or immutable audit records from a blocking demonstration.
Evaluating a control for your organization?
Bring your target AI tool, device and acceptance criteria. Review the supported control path, the evidence you need and any limitations before deciding on a pilot.