[Feature Request] Improve safety filter context-awareness for legitimate defensive security engineering

Bug Description

Feedback: Fable 5 safeguards repeatedly flag legitimate first-party defensive engineering

*Two recurring cases from the same commercial engineering program: identity (IAM)
implementation, and an internal code-quality audit method.*

---

Who is reporting this

I am the owner and Principal of Redwood Compliance LLC, a California company
established April 2016, headquartered in San Mateo, CA, with a federal Tax ID.
We have delivered work for NASA, the U.S. Department of the Interior, the
Federal Aviation Administration, and other federal and commercial clients.

I mention this only to establish that this is an accountable U.S. business
running an ordinary commercial engineering program on infrastructure it owns —
not an anonymous or unattributable use case. I am happy to be identified and to
provide transcripts.

Summary

Fable 5 repeatedly flags my sessions and reroutes them to another model across
two distinct internal engineering workflows on systems my company owns and
operates. Both are defensive and authorized. Both are flagged because their
subject matter requires the same vocabulary that offensive security content
uses. The reroute happens mid-task, on a large fraction of turns.

Context: we build and operate a private OpenStack-based cloud platform. Both
workflows below are internal engineering on our own systems and our own
proprietary code. Neither touches third-party systems. Nothing is adversarial
toward anyone.

---

Example 1 — identity and access management (IAM) engineering

We are building the platform's identity layer: a Keycloak identity provider
deployed as an HA pair, two OpenStack Keystone instances federated to it over
OIDC, group-to-project authorization mapping, backup and restore of the identity
database, and automated tests covering all of it. Ordinary platform engineering,
in the identity domain.

Why it trips the filter. Doing this work well requires writing and
reasoning about exactly the language that signals attack content. Real phrases
from the work, with why each one appeared:

• "MFA bypass" — I found that residual local passwords would let users bypass

our own multi-factor authentication after a planned cutover. I needed to name
the hole in order to close it.

• "cross-tenant access" / "cross-customer leakage" — I was writing automated

tests to prove that one customer cannot reach another customer's resources.

• "break-glass credentials" — the emergency administrator path that every

identity system must have and must document.

• "adversarial review" — a deliberate exercise in which several agents tried

to break my own authentication design before I built it, so the flaws would
be found on paper rather than in production.

• "privilege escalation", "token theft", "session fixation", "open redirect"

— the standard threat list, enumerated in order to defend against each item.

The irony is that the more rigorously we do defensive security, the more the
work resembles offensive security. A careless identity implementation that
never mentioned MFA bypass would presumably pass without comment. Ours was
flagged precisely because we went looking for the bypass in order to fix it.

Example 2 — an internal code-quality audit method (arguably the clearer case)

We maintain an internal standard we call a "deployability audit": an engineering
review we run on our own service code before release. It asks whether every
feature actually works, whether the service is secure, whether it matches its
roadmap, and whether it is operationally sound. It produces a report and files
issues. It does not change code. Invoking this method reliably triggers the
same flag and reroute.

Two things make this the sharper example.

First, the disambiguating context is already stated explicitly in the
document. Its purpose section reads, verbatim:

"an authorized, first-party, defensive internal engineering audit … a quality-and-security review of our own proprietary code, run to find and fix defects before broader release."

That is in plain English at the top of the file. The filter fires anyway. So
this is not a case of missing context — it is a case of stated context not
being weighted.

Second, the word most likely triggering it means the opposite of what is
presumably assumed. The method's central rule is "adversarial
verification": every finding is handed to a second, independent reviewer whose
job is to refute it, defaulting to "not confirmed," so that false positives
are dropped before anything is reported. It is a rigor technique for
suppressing bad findings — being skeptical of our own claims. The document
uses "adversarial" five times, always in that sense. Nothing is being attacked.

The remaining flagged vocabulary is similar: "cross-tenant", "injection",
"exploit", "bypass" appear because a quality checklist has to name the defect
classes it looks for. A review that could not say "check for injection" would…
Note: Content was truncated.