Python: [Feature]: Define FIDES labeling for context-provider messages #9645

Problem

ContextProvider instances are trusted framework plugins, but there is no first-class contract for attaching integrity and confidentiality labels to the messages they add to SessionContext. This makes it difficult for providers that wrap retrieved or remembered external data to integrate consistently with SecureAgentConfig without routing the data through a tool or implementing custom preprocessing.

The existing context-provider trust model remains valid: provider code itself is trusted and has access to the conversation and session state. The missing capability is a standard way for a trusted provider to describe the provenance and restrictions of the data it injects.

Use Case and Evidence

Memory, retrieval, and search providers may return a mixture of locally trusted records and externally sourced content. Applications using FIDES need to express, at message or content-item granularity, that provider-injected data is untrusted, private, or identity-scoped so that the cumulative context label and downstream tool policy reflect those restrictions.

Today providers can add ordinary Message objects, and SessionContext.extend_messages(...) adds source attribution, but SecureAgentConfig does not define an enforcement contract for provider-supplied labels. LabeledMessage exists, but it is not integrated into the context-provider assembly pipeline.

Desired Outcome

Define an opt-in, first-class provider-message labeling contract that allows trusted context providers to attach restriction-only integrity and confidentiality information. SecureAgentConfig should consume the labels after provider context has been assembled, preserve them through supported history and transport paths, and update the cumulative FIDES context label consistently.

The design should explicitly define defaults for unlabeled provider messages, how trusted local configuration may establish authority, and how caller- or remote-supplied labels are prevented from reducing restrictions.

Alternatives Considered

• Continue treating all context providers as trusted and require each provider/application to manually sanitize or hide retrieved data. This remains the current documented model but does not provide consistent FIDES propagation.
• Route provider data through FIDES-labeled tools. This works but changes provider architecture and can add unnecessary model/tool turns.
• Use LabeledMessage directly. This lacks an integrated post-provider enforcement point and clear authenticity, serialization, and compatibility rules.

Proposed Direction

• Add a provider-facing message/content labeling API, likely using the existing ContentLabel vocabulary.
• Apply labels only after all providers have run, before the first model call.
• Treat labels carried by ordinary messages as restriction-only unless trusted local configuration establishes them as authoritative.
• Decide and document the compatibility default for unlabeled provider messages.
• Preserve labels across history providers and supported transports.
• Add coverage for mixed-trust provider output, forged label downgrades, provider ordering, streaming/non-streaming parity, and history restoration.

Scope and Non-Goals

In scope: provider-injected message/content labels and their interaction with SecureAgentConfig, history, and transports.

Non-goals: sandboxing untrusted provider code, changing the documented rule that ContextProvider implementations are trusted plugins, automatic semantic classification of retrieved text, or exposing hidden FIDES values to providers.

Language

Python

Contribution Intent

I can help with implementation or testing

Acknowledgements

• I searched existing issues and did not find a duplicate.
• I will wait for explicit maintainer agreement before starting implementation of a non-trivial change.