My strict re-land of the LIKE exemption still had a bypass

I landed a safety-guard exemption at 4:53 PM on October 3rd and wrote in the commit that real tables would still be refused. Sixteen minutes later I had reverted it.

Why the guard refuses a leading wildcard

The guard sits in front of production database access and refuses scan-shaped queries. A leading-wildcard LIKE against a real table in prod is the query you want stopped before it runs.

The exemption I landed

sys.* and INFORMATION_SCHEMA.* are catalog views, which are not real tables. A leading-wildcard LIKE against them is harmless, but the guard refused it anyway. So I added an exemption that allows the LIKE when it is confined to catalog views. I wrote tests and committed it with this message: “any real-table target still refused.”

That sentence was wrong.

The BLOCKER

The revert commit cites an Opus review BLOCKER. The exemption let real-table LIKEs through, which was exactly what my message said it would not do.

I reverted it, and the revert message says why: it let real-table LIKEs through. Then I re-landed it strict. Every FROM and JOIN now had to be directly followed by a catalog name. A comma join, a comment, a quoted or dynamic name, APPLY, a write, EXEC or string building all made the guard refuse the query again.

It still wasn’t enough. The second Opus review found another bypass.

The four commits, in order:

1. Exempt catalog-view LIKEs.
2. Revert: real-table LIKEs got through.
3. Re-land the exemption, strict.
4. Withdraw the exemption entirely.

Withdrawing it

I withdrew the exemption. The guard is back to fully strict, with no catalog carve-out at all. The bypass cases stay in the test suite as tests that assert they are blocked, so the suite keeps a record of what got through.

Review found a hole in the “narrow” rule twice, and the second withdrawal came at 5:30 PM.

What stays

A leading-wildcard LIKE against a catalog view is refused again. The bypass cases stay in the test suite as blocked tests.

dxdev LESSON · paste into your AI coding agent
LESSON: Do Not Grant A Safety Guard A Narrow Exemption Unless It Can Prove Every Reference In The Query Qualifies
SOURCE: dxdev.com/blog/narrow-exemption-opus-review-reverted
WHAT HAPPENED: The guard refuses scan-shaped queries, including a leading-wildcard LIKE on a real prod table. I landed an exemption that allowed the LIKE when it was confined to catalog views, with tests, and a commit message saying any real-table target would still be refused. The review marked it a BLOCKER because real-table LIKEs were getting through. I reverted it and re-landed a stricter version, and the second review found another bypass. I then withdrew the exemption entirely and kept the bypass cases in the test suite as blocked tests.
THE RULE: A safety guard that decides from query text should rely on a single simple fact and refuse on it, not carve out exemptions that require proving every table reference is safe. If an exemption fails review, remove it and keep the bypass cases as tests.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Every refusal rule in the guard can be decided from one simple property of the query text, without having to prove that all table references in the query belong to an allowed set.
      2. Each exemption that was tried and withdrawn has its known bypass queries kept in the test suite as tests asserting they are blocked.
      3. Any commit that adds or narrows an exemption to a safety guard has been reviewed specifically for whether the exempted form can be spelled to reach a real production table.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.