XFBA checks that code is internally consistent. XSIA maps what else breaks when it lands. XFSA is the third gate: on every edit, it scans for secrets, credentials, injection sinks, unsafe deserialization, and authorization gaps. Not every fix is worth shipping at the cost of a security regression. XFSA sees what a code-shaped check can't.
Part of Quality Gates
Connect with GitHub — it's freeXFSA runs in the same Stage 1/2 gate as XFBA + XSIA. Hardcoded credentials, secret-like strings, injection sinks (SQL, shell, template), unsafe deserialization, auth checks that were present and disappeared — all caught before the change reaches disk.
Security rules live in the XFMT tree like every other XF artifact: organized, searchable, contradiction-aware. Domain-specific rules (Flask, FastAPI, Flutter, Supabase) route to the right subtree for the project. Stale rules get flagged and pruned.
Repeatedly suppressing the same rule in the same context trains XFPA to auto-skip it for you. The rule stays firing for first-time users. Per-user trust graduates without weakening the default protection for everyone else.
You ask Claude to edit or write code.
XFBA + XSIA + XFSA fire together at PreToolUse.
XFSA scans for secrets, injection, deserialization, auth regressions against the project's rule subtree.
Clean: stamp fires, edit proceeds.
Exposure: edit blocked. Concern surfaced with what + risk + recommended fix.