Roll out pattern policies without turning exceptions into bypasses

Specify the rule and the decision separately

A string matcher answers a narrow question. It does not decide whether a document is confidential, whether a provider may receive it, or whether the requester owns the account. Write those decisions separately so a rule that finds one marker is never described as a complete PII scanner.

OWASP's input-validation guidance distinguishes field-specific syntax and semantic requirements from authorization and downstream protections. Apply the same discipline to request screening: identify the field, accepted representation, pattern scope, action on a match, and handling of an unavailable checker.

Label the business intent before looking at matches

Consider an original teaching rule: find an uppercase token FAKE_ACCOUNT_ followed by exactly four ASCII digits in the message field. Require token boundaries: an adjacent ASCII letter, digit, or underscore prevents a match. Search within the message after its defined protocol decoding. This is a deliberately limited definition, not an implemented detector.

All following inputs and account references are fabricated. The exercise labels an internal account reference as restricted and a public documentation quotation as allowed, before evaluating the pattern. No customer data, model request, or test result is involved.

The final row is consistent with the four-digit rule. Its failure is the mismatch between that limited rule and a broader promise about account disclosure. Likewise, the quoted marker matches correctly but blocks an allowed task. A checker can be mechanically correct and operationally unsuitable.

Choose a response before widening the rule

For the benign quotation, first ask whether the model needs the literal marker. Replace it with “the example identifier” when that preserves the task, then review the resulting request normally. Do not delete arbitrary characters until a request happens to pass; transformations can alter meaning and conceal what the system actually sent.

For unsupported formats or confidential prose with no known pattern, use the workflow's data classification and provider policy. Reject the request, construct a minimized permitted payload, or hold it for authorized review. “No match” is not a permission to send every remaining value.

Begin with an offline labeled fixture. An observe-only stage in a real application can still send sensitive data downstream, so it needs an appropriate independent data boundary. Do not collect raw rejected prompts merely to tune the rule.

Make a temporary exception smaller than a policy change

Suppose a documentation task truly requires the literal synthetic marker. A reviewed exception may permit that one quotation under a named rule. It must not become “disable screening for this user.” The following record is a proposed design, not an available Boundary feature.

• Request binding: immutable request version and exact outbound payload reference; changed text requires new review.
• Data and rule scope: public-documentation class, the particular quoted marker, and the single rule being excepted.
• Destination: approved provider, model, endpoint, and relevant processing mode; fallback is not automatically included.
• Identity: tenant and caller derived from trusted application state, plus the authenticated reviewer's authority.
• Lifetime: a short explicit expiry, revocation state, and one-use limit where one dispatch is intended.
• Policy binding: reviewed policy revision, justification, owner, and decision record.

OWASP recommends checking authorization on every request. The trusted enforcement point should verify these fields immediately before dispatch. A model-generated approval flag or a browser-only exception cannot establish that authority. Other tenant, destination, usage, and mandatory data restrictions remain effective.

Review revisions and revocation at the enforcement point

Keep exception administration separate from ordinary request submission. Record who can grant, revoke, or change scope. If an exception is single use, consumption needs shared atomic state; a retry requires the explicitly defined retry policy rather than an accidental reusable permit.

A policy revision should trigger review of affected exceptions. Reject a revision mismatch unless a reviewed migration explicitly reauthorizes the record. Expiry and revocation must reach every enforcement replica and any decision cache within a declared bound.

OWASP's policy-distribution guidance distinguishes publishing an update from activating it everywhere. Verify the effective decision after revocation, not just a successful administration response. When required identity, policy, or exception freshness cannot be established, deny the affected dispatch instead of converting uncertainty into a permit.

Decide what evidence would justify rollout

Before enabling a revised rule, have another reviewer check the labels and proposed exception. Exercise matching, nonmatching, near-match, changed-payload, wrong-tenant, changed-destination, expired, revoked, and old-revision cases in an isolated harness. Include benign counterparts and a checker timeout. These checks are suggested, not performed here.

Report false positives against labeled allowed cases and false negatives against labeled restricted cases, with their respective denominators and sampling limits. Keep unsupported data classes visible. A small fixture cannot establish production detection rates, and a successful exception does not demonstrate protection over all requests.

Boundary's request-path pattern checks are planned prelaunch capabilities. This guide implements no scanner or exception engine. The existing local simulator evidence concerns separate synthetic agent-action rules, not this policy rollout or general sensitive-data recognition.