Honor SecurityClass in pipeline security checks

[liavweiss]

What?

Pipeline validation treats a hardcoded name list as the source of
truth for "this filter is security-critical." Custom filters
registered through the public registry API (including praxis-ai
filters) cannot join that set, even when they are already marked
SecurityClass::Security.

SecurityClass already exists on the registry. Builtins are
classified with it, and out-of-tree filters can opt in via
register_with_class. The fail-open, conditional-security, and
SkipTo-bypass checks still match names against SECURITY_FILTERS
instead of that class.

The idea is that registration decides whether a filter is
security-critical, and the existing checks follow that
classification. Core would not list downstream filter names.

Goals

• Config-time fail-open / condition / SkipTo checks apply to any
  filter registered as SecurityClass::Security, not only builtins.
• Out-of-tree and AI-registered security filters can opt in without
  a core name-list change.
• Builtins keep the same operator-facing behavior they have today
  (failure_mode: open still requires
  insecure_options.allow_open_security_filters).

Why?

A security filter with failure_mode: open skips the check on
provider timeout, network error, or other FilterError and forwards
the request. Core already refuses that misconfiguration at startup
for builtins (ip_acl, guardrails, csrf, …).

That safety net is a closed list of core names. A filter registered
later, even as SecurityClass::Security, is not in the list, so
operators get no warning.

This showed up downstream in
praxis-proxy/ai#753
for ai_guardrails: it is a security gate (PII / injection
screening via an external provider), but failure_mode: open is
accepted with no config-time error. The same gap exists for other
AI filters that already call register_with_class(..., SecurityClass::Security) today (for example credential_inject).
Marking them Security does not currently change validation.

ai_guardrails is one consumer, not the core change. Core should
not special-case that name. Any future security-class filter
(AI or otherwise) should get the same checks by registering as
Security.

User stories

• As a proxy operator, I want failure_mode: open on a
  security-class filter to fail startup (unless I set
  allow_open_security_filters), so a provider outage cannot
  silently bypass the check.
• As a filter author outside core, I want to mark a filter
  SecurityClass::Security and have the existing pipeline
  checks apply, so I do not need a core PR per filter name.
• As a Praxis maintainer, I want one classification used by both
  the registry and the checks, so the two cannot drift.

Alternatives considered

1. Add downstream names to SECURITY_FILTERS. Works for one
   filter. Every new AI/out-of-tree security filter still needs a
   core PR, and core starts owning names it does not implement.
2. Duplicate the checks in praxis-ai (or other consumers).
   Ships without a core change, but splits the safety net and is
   easy to miss for the next filter. SkipTo / conditional checks
   would have to be copied too.

Honoring SecurityClass in the existing checks looks like the
option that scales and matches what the registry API already
advertises.

Open questions

• Should SECURITY_FILTERS remain as a builtin snapshot, or should
  the registry class become the only source of truth once the
  checks use it?

[aslakknutsen]

I "think" this has been prepare "for the future" that hasn't come yet. It makes perfect sense to honor the SecurityClass in the registration and replace the old SECURITY_FILTERS. I see no reason to give Core filters any privilege over external ones.

[szedan-rh]

+1 @aslakknutsen