proposal: add SecurityClass pipeline checks

[liavweiss]

Summary

• Add proposal #1044: pipeline security checks follow SecurityClass instead of the hardcoded SECURITY_FILTERS name list, so out-of-tree filters get the same fail-open, condition, and SkipTo checks as builtins.
• What? and Why? were agreed in the linked discussion. How? is the implementation plan: the registry class is the source of truth, and core builtins have no privilege over external filters.

Tested

• Proposal structure checked against proposals/template.md (frontmatter, What / Why / How).

Context

• Discussion: https://github.com/orgs/praxis-proxy/discussions/1044
• Downstream motivation: ai_guardrails: failure_mode:open not caught by security-filter config validation; no caching for growing conversation history ai#753

[praxis-bot-app]

Proposal validation failed:

• proposals/01044_security-class-pipeline-checks.md: new proposals must not include the ## How? section in the first PR. Submit What? and Why? first; add How? in a follow-up.

See proposal process for requirements.

[liavweiss]

• What? and Why? were agreed in the linked discussion. How? is the implementation plan: the registry class is the source of truth, and core builtins have no privilege over external filters.

What? and Why? were agreed in the linked discussion.

[praxis-bot]

PR Review

Summary: The proposal is well-structured and clearly motivates the need for SecurityClass-based pipeline checks instead of hardcoded name lists. The design approach of stamping is_security during pipeline build is sound. However, one critical edge case around registry lookup failure is not specified, and there is a minor inconsistency in the Non-goals section.

Severity	Count
Large	1
Medium	1

[praxis-bot]

[Large] Lines 154-161 describe stamping is_security during pipeline build by reading registry.is_security_filter(&entry.filter_type), but the proposal never specifies what happens if the filter type is not found in the registry.

This is a critical edge case because:

1. Custom filters might be referenced in config before registration completes (race condition during startup)
2. Config reload might reference a filter that was unregistered
3. Malformed config might reference a non-existent filter type

Possible behaviors:

• Default to false — treat unknown filters as non-security (could create security gaps)
• Fail pipeline build — safer, but might break existing configs
• Log warning and default — middle ground but still requires a default choice

Specify the intended behavior explicitly, e.g., "If registry.is_security_filter returns None for a filter type, pipeline build fails with an error indicating the filter is not registered." or document that this cannot happen because config validation already ensures all referenced filters exist in the registry.

[praxis-bot]

[Medium] Line 140-142 states "Registering ai_guardrails as Security in praxis-ai" is a non-goal, but lines 231-234 in the Implementation PRs section explicitly describe a "Downstream (not this repo)" PR that registers ai_guardrails as SecurityClass::Security.

This is inconsistent: if downstream registration is covered in Implementation PRs, it's part of the coordinated delivery plan, not truly a non-goal. Either:

1. Remove the non-goal bullet (since the proposal does coordinate the downstream change), or
2. Move the Implementation PRs note about ai_guardrails to a separate "Downstream follow-up" section that clarifies it's outside this proposal's direct scope but enabled by it.

[aslakknutsen]

We have a certain proposal filename naming issue here after we consolidated every proposal into a single repo;
https://github.com/praxis-proxy/enhancements/blob/main/docs/process.md#3-issue

In the old process we should create an Epic in "this" repo to track this formal proposal and the how etc and use that Epic number as a filename prefix.. But I'm not sure it makes sense to run Epics out of the enhancements repo, especially not for a rather simple change like this. Then again, if it's cross repo concerns that's proposed it makes sense to have the Epic outside e.g. Core. We might want to adjust the process definition here some how. @shaneutt ?

Strictly speaking I don't even think this PR is required by the process:
"Small changes (bug fixes, minor enhancements, documentation updates) do not require proposals. Proposals are for features that span multiple PRs, introduce new architectural patterns, affect a project's public interface, or are complex enough to warrant more process."

Beyond that, the content of the PR looks good, I would close it(no bad feelings), write a short issue in Praxis for it.. and I'm looking forward to the impl. :)

[liavweiss]

Thank you @aslakknutsen.