Summary
Praxis can execute outbound HTTP calls through SubRequestClient, but those calls are transport-only and do not pass through an HTTP filter pipeline.
IRR already contains an internal IrrStepRunner that executes one HTTP exchange through a filter chain. However, filters running inside IRR can initiate nested network calls that bypass this mechanism.
Praxis AI currently has this problem for:
- MCP server requests.
- OpenAI Responses and Anthropic Messages web search.
- OpenAI Responses file search against OGX vector stores.
file_id metadata and content resolution through the configured OGX Files API.
Consequently, credentials injected into the incoming request by a trusted authentication component cannot be consistently applied to these outbound calls. Authorization decisions, audit context, and per-user usage attribution are also lost at the nested callout boundary.
The OGX file callouts already support manually forwarding selected request headers. This can carry a credential established before Praxis, but it does not execute outbound authorization, policy, audit, or usage filters. file_id resolution also runs during StreamBuffer pre-read, so its trusted authentication context must exist before body processing begins.
Generalize IRR's single-exchange runner into a reusable filtered-subrequest executor in praxis-filter:
IRR ----------------------\
MCP transport -------------\
Web-search callout ----------> FilteredSubrequestExecutor -> SubRequestClient -> destination
File-search callout --------/
File-ID resolution --------/
The executor owns the child filter context, request and response filter lifecycle, routing, deadlines, limits, buffered or streaming transport, and cleanup.
SubRequestClient remains the low-level transport and does not depend on filter pipelines.
The child context is isolated by default. Callers may explicitly project approved request-scoped data such as a trusted credential header, subject, tenant, authorization decision, tracing context, and deadline.
Credentials must only be disclosed to the configured destination. Arbitrary headers or request extensions must never be forwarded automatically.
The first adopters are MCP, OpenAI/Anthropic web search, OGX file search, and OGX file_id resolution. Other callouts can migrate separately.
Success Criteria
praxis-filter exposes a reusable API for executing one buffered or streaming subrequest through a prebuilt filter pipeline.
- The executor preserves filter lifecycle behavior, deadlines, size limits, cancellation, streaming cleanup, and nested-request depth controls.
- IRR uses the shared executor without behavioral regressions.
- Outbound chains are built through the active filter registry and participate safely in configuration reload.
- Unknown chains, recursive chains, and excessive nesting are rejected during configuration validation.
- Parent and child contexts remain isolated, with explicit allowlisted propagation only.
- Destination validation, DNS/SSRF protections, TLS/SNI, and
Host handling remain enforced before credential disclosure.
- Praxis AI routes all MCP exchanges, OpenAI/Anthropic web-search requests, OGX vector-store searches, and OGX
file_id metadata/content requests through configured outbound chains.
- A trusted user credential header can be forwarded unchanged to the configured destination without being logged, persisted, or added to inference payloads.
- Subject, tenant, and authorization-decision metadata remain available for authorization, audit, and per-user usage attribution.
file_id resolution consumes only trusted authentication context established before StreamBuffer pre-read.
- Credentials intended for the configured OGX Files API are never forwarded to client-controlled
file_url destinations.
- End-to-end tests prove that requests from two users use distinct credentials and produce distinct attribution across MCP, web search, OGX file search, and OGX
file_id resolution.
- Configuration examples and documentation are provided.
Area
Filter Pipeline
Summary
Praxis can execute outbound HTTP calls through
SubRequestClient, but those calls are transport-only and do not pass through an HTTP filter pipeline.IRR already contains an internal
IrrStepRunnerthat executes one HTTP exchange through a filter chain. However, filters running inside IRR can initiate nested network calls that bypass this mechanism.Praxis AI currently has this problem for:
file_idmetadata and content resolution through the configured OGX Files API.Consequently, credentials injected into the incoming request by a trusted authentication component cannot be consistently applied to these outbound calls. Authorization decisions, audit context, and per-user usage attribution are also lost at the nested callout boundary.
The OGX file callouts already support manually forwarding selected request headers. This can carry a credential established before Praxis, but it does not execute outbound authorization, policy, audit, or usage filters.
file_idresolution also runs duringStreamBufferpre-read, so its trusted authentication context must exist before body processing begins.Generalize IRR's single-exchange runner into a reusable filtered-subrequest executor in
praxis-filter:The executor owns the child filter context, request and response filter lifecycle, routing, deadlines, limits, buffered or streaming transport, and cleanup.
SubRequestClientremains the low-level transport and does not depend on filter pipelines.The child context is isolated by default. Callers may explicitly project approved request-scoped data such as a trusted credential header, subject, tenant, authorization decision, tracing context, and deadline.
Credentials must only be disclosed to the configured destination. Arbitrary headers or request extensions must never be forwarded automatically.
The first adopters are MCP, OpenAI/Anthropic web search, OGX file search, and OGX
file_idresolution. Other callouts can migrate separately.Success Criteria
praxis-filterexposes a reusable API for executing one buffered or streaming subrequest through a prebuilt filter pipeline.Hosthandling remain enforced before credential disclosure.file_idmetadata/content requests through configured outbound chains.file_idresolution consumes only trusted authentication context established beforeStreamBufferpre-read.file_urldestinations.file_idresolution.Area
Filter Pipeline