Python: [Feature]: Inbound chat middleware sample for an optional third-party pre-model screener

Language / SDK

Python

Summary

I would like maintainer direction before writing code.

Little Canary is a third-party inbound screener maintained by Hermes Labs, and I am affiliated with Hermes Labs. The proposed integration would remain optional and externally maintained.

The intended implementation target is existing Python chat middleware, subject to maintainer confirmation that its current pre-model and termination semantics are the supported integration seam. No framework API change is requested.

Problem and proposed behavior

An operator may want to screen supported outbound text before it reaches a model while retaining an explicit record of whether screening occurred.

If accepted, the integration would:

• inspect supported outbound text through the current public Little Canary API, reverified immediately before implementation;
• preserve the checker’s current public result fields without renaming or inventing values;
• make degraded behavior operator-selectable, with allow/fail-open as the default;
• pass unsupported or non-text content through while marking it unscreened;
• avoid breaking Agent Framework imports when the optional dependency is absent; and
• use only the current, maintainer-approved middleware and termination contracts.

This is not proposed as a replacement for existing security wiring. It makes no claim of parity, efficacy, comprehensive safety coverage, or adoption.

Overlap and route decision

Before filing, I was unable to complete a conclusive duplicate and owner-history check within the verification timebox. Please point me to an existing issue or integration if this overlaps prior work.

Otherwise, please select one or neither:

1. one small sample under python/samples;
2. an external integration maintained in Little Canary, with a documentation link from the appropriate Agent Framework security or samples page; or
3. neither.

Tests if accepted

• A permitted result continues exactly once.
• A configured blocking result terminates through the supported middleware contract and the model is not called.
• Disabled mode makes no checker call.
• Both configured degraded behaviors are covered.
• Unsupported and non-text content passes through explicitly marked unscreened.
• Boundary-length behavior follows the reverified dependency contract rather than an invented framework limit.
• A missing optional dependency produces a clear integration error without breaking unrelated host imports.

No implementation or PR will begin until maintainers confirm the route.

Exact wait event: maintainer selects option 1, option 2, or neither.