AI Safety-Scanner Enforcement Automation: A Toggle That Saved, Read Back, and Blocked Nothing

A settings toggle that saves, persists across reloads, and even passes an automated test proving it persists looks, by every normal measure, like a working feature — persistence is usually the hard part to get right, and a passing test for it is real, reassuring evidence. What a persistence test can't tell you is whether anything downstream actually reads that setting at the moment it matters. A toggle can be perfectly, verifiably saved and simultaneously completely inert, and the gap between those two facts is invisible from the settings screen itself — it only becomes visible by tracing whether the real, live code path that's supposed to respect the setting actually asks for its value.

Building and testing a settings screen — the form, the save call, the read-back, a persistence test — is a genuinely complete, verifiable piece of work on its own, which is exactly why it's easy to treat as proof the whole feature works. The setting only becomes meaningful the moment something else in the codebase actually branches its behavior on that stored value, and that wiring is a structurally separate piece of work that a settings-focused test never touches. When that second half never gets built, everything that WAS built continues to work exactly as tested — the setting still saves, still reads back, still shows the right toggle position — while doing nothing whatsoever for the actual behavior it claims to govern.

The gap was found as part of the same internal audit that rewrote Axiom's proof-of-action mechanism (covered on this pillar's companion page): a recurring pattern of a feature not yet fully wired presenting itself as complete. For the Safety Scanner specifically, the audit's own account is direct — the three settings (auto-scan prompts, auto-scan outputs, block on high threat) were correctly saved and read, with a passing persistence test to prove it, but the underlying `scan()` function was only ever invoked from the scanner's own settings page, when a person pasted text in to test it manually. The real AI conversation path — where prompts are actually sent and responses actually received — never called it at all. No prompt was ever automatically scanned, no output was ever automatically scanned, and nothing was ever actually blocked, regardless of what the toggle said.

A second, specific defect compounded the first: when that manual test scan found a threat, the existing code logged an audit event of type `safety_scan_blocked` — even though, at that point in the code's history, nothing anywhere had an actual blocking mechanism. The audit trail was recording a block that structurally could not have happened. An audit record describing an event that never occurred is worse than a missing record, because an audit record is specifically the thing people read as proof something happened.

The fix adds a new function, `scanAndEnforce()`, that checks the org's actual configuration, runs the real scan, and — critically — is confirmed by direct inspection of the current `hooks/useSession.ts` file to be genuinely called on both the real prompt-sending path and the real AI-output path, not just described as fixed in a historical commit message. It is now the ONLY code path in the entire scanner that is allowed to log a `safety_scan_blocked` event, and it does so only at the exact moment a block genuinely occurs — with the audit log write placed deliberately before the function throws, so the record exists even if whatever calls it doesn't handle the resulting error. The function also fails closed on a specific edge case: if the scan itself can't be completed for some reason and the organization's policy requires blocking on high threat, the request is refused rather than allowed through on the assumption that no news is good news.

A related, separate defect in the same file was fixed alongside it: the function computing a conversation's overall threat level compared detected threats' severity using `array.indexOf()` against a fixed severity list. An unrecognized severity value — a custom pattern an organization configured with a severity value outside the expected set, or a legacy database row — returns -1 from `indexOf()`, and -1 is never greater than the initial running maximum of 0, so an unrecognized threat silently ranked as the least severe possible outcome: safe. The fix replaces the array-and-indexOf approach with a closed, exhaustive mapping from every valid severity to a numeric rank that TypeScript's own type system forces to stay complete, with any value genuinely unrecognized at runtime now explicitly ranked as the MOST severe category rather than falling through to the least.

Someone sends a prompt containing a pattern the org has configured as high-severity, with the "block on high threat" setting turned on. Before the fix, that setting had no bearing on what actually happened — the prompt reached the AI regardless, because nothing in the real path ever checked the setting. After the fix, the same prompt is genuinely intercepted before it reaches the AI, and the block is both enforced and honestly recorded — not one without the other.

A safety setting an administrator turns on now genuinely changes what happens to real prompts and real AI responses, rather than only changing what a settings screen displays. And because the audit trail can now only record a block when a block genuinely occurred, a compliance reviewer reading that log is reading a description of real events, not a record that could describe something that structurally never happened.

This fix makes an existing, org-configurable safety policy actually enforceable — it does not add new threat-detection patterns beyond what the scanner already checked for, and it does not replace an organization's own judgment about which patterns to configure as high-severity in the first place. A team expecting an expanded built-in threat library from this specific fix will not find that here; what changed is that the existing scanning and blocking logic is now genuinely connected to the real conversation.

Building and testing a settings screen thoroughly is real, necessary work — but it proves only that the setting is stored correctly, never that anything downstream actually reads it at the moment that matters. Centriu Axiom's fix closes exactly that gap: the same three settings that always saved correctly are now genuinely read and enforced on the real path they were always meant to govern, verified directly against the live code rather than assumed from the settings screen working as designed.