fix(guardrails): run input guardrails on /v1/responses and /v1/embeddings (#719)

[moonming]

What

Closes the input half of #719: a configured input guardrail that blocks on /v1/chat/completions was silently skipped on /v1/responses and /v1/embeddings. The same input that returns 422 content_filter on the chat surface returned 200 on these surfaces — /v1/responses echoed the content back, /v1/embeddings embedded it. A customer-configured content/DLP block was therefore bypassable just by switching surface.

This PR makes both non-chat input-bearing surfaces run the resolved input guardrail chain before dispatch, exactly as /v1/chat/completions and /v1/messages already do.

Why this happened

Guardrail invocation was inlined per-surface. chat.rs and messages.rs each resolve the chain and call check_input; responses.rs had zero guardrail calls and embeddings.rs explicitly documented "embeddings bypass guardrails today". So the enforcement gap was per-surface, not in the chain itself.

Changes

crates/aisix-proxy/src/responses.rs

• After auth + rate-limit, before dispatch: resolve the per-request chain (RequestContext { model_id, api_key_id, team_id }), and if non-empty run check_input. Block → ProxyError::ContentFiltered (422 content_filter).
• New responses_input_to_chat() synthesizes a role-preserving ChatFormat from the Responses-API body: input as a bare string, or an array of message items whose content is a string or typed parts (input_text / output_text / text); optional top-level instructions → system message. Roles are preserved so the guardrail's user-vs-all message selection behaves identically to chat. The synthesized request is for scanning only — the original body is still forwarded verbatim.

crates/aisix-proxy/src/embeddings.rs

• Same input check before the upstream call. embeddings_input_to_chat() turns the input (string / array of strings) into user messages. Embeddings responses are vectors → no output hook.
• Corrected the now-stale telemetry comment that claimed embeddings bypass guardrails.

Shared semantics (both surfaces), matching /v1/messages:

• Only Block is enforced. Rewrite/Bypass are not applied to the outgoing non-chat body (same deliberate limitation /v1/messages documents).
• Per bug: output guardrail error message echoes the matched forbidden literal back to caller #153, the verdict's matched-pattern reason is logged for ops but the wire message stays generic ("request blocked by content policy") so callers can't enumerate the blocklist by probing error responses.

Reference / spec

• Responses-API input shape (string | array of input items; message content is a string or typed parts): https://platform.openai.com/docs/api-reference/responses/create. Embeddings input (string | array of strings): https://platform.openai.com/docs/api-reference/embeddings/create.
• In-repo reference pattern this mirrors: messages.rs input check (resolve chain → is_empty() guard → translate body → check_input → ContentFiltered on Block).
• Mainstream AI gateways apply their moderation/guardrail hooks uniformly across every input-bearing surface, not only the chat endpoint; this change brings the non-chat surfaces in line with that norm.

#719 scope status

• /v1/responses runs input guardrails — this PR
• /v1/embeddings runs input guardrails (carries scannable user content) — this PR
• Anthropic /v1/messages runs input + output guardrails — already present (messages.rs input :398, output non-streaming :1353, streaming :1529); verified, no change
• Output guardrails on non-chat surfaces that return a body (/v1/responses non-streaming + streaming) — deliberately deferred to a follow-up PR

Why output is a separate PR (not in this one)

Output coverage on /v1/responses must be all-or-nothing: adding it to the non-streaming path only would make stream:true a new asymmetric bypass of the exact class #719 is about. Streaming output requires parsing the Responses-API SSE event protocol (response.output_text.delta / response.completed) — which the gateway deliberately does not do today (SSE is passed through verbatim; streaming usage extraction was itself deferred under #404). That is a focused, protocol-specific change with its own regression surface, so it is isolated for independent review rather than bundled with this clean, high-value input fix. Follow-up will use buffer-then-scan (BufferFull) semantics, matching the chat surface's secure default.

Test plan

6 new wiremock unit tests (3 per surface):

• block on string input → 422 + error.type == content_filter + upstream never contacted (expect(0))
• block on array input → 422 content_filter
• benign input → upstream is called (expect(1)) → 200 (guardrail must not block clean traffic)
• the blocked literal must not leak into the wire message (bug: output guardrail error message echoes the matched forbidden literal back to caller #153)

cargo fmt + cargo clippy --all-targets clean; 385 aisix-proxy lib tests pass.

The real-Azure M1 acceptance test (held back in AISIX-Cloud#718) will be re-added to AISIX-Cloud once this merges, per the source-blind discipline.

Independent audit (CLAUDE.md §8) — findings + resolution

A fresh agent reviewed this PR cold. It verified the core fix is solid: synthesized text is actually scannable (message_scan_text), the input check runs before the streaming split (covers both modes), #153 redaction holds (no blocklist leak), 422 content_filter confirmed, the forwarded upstream body is byte-identical, the no-guardrail path is a pure no-op, and the 6 tests genuinely assert the contract (wiremock expect(0)/expect(1)).

• MEDIUM-1 — function_call_output tool-result text not scanned (narrowed feat(bedrock): honor ANONYMIZE — mask-and-continue instead of block #719 bypass on the tool-result channel): FIXED in code (commit 3fba23d). responses_item_text now scans both content and output; such items map to a user message and are scanned by every guardrail kind. New tests cover it (function_call_output block + instructions block).
• MEDIUM-2 — a guardrail-blocked request burns a rate-limit slot (reservation runs before the block): JUSTIFIED + follow-up filed (Guardrail input check runs after rate-limit reservation on /v1/messages, /v1/responses, /v1/embeddings (burns a quota slot on a content block) #542). This matches the existing /v1/messages ordering (intentionally mirrored), so it is consistent shipped behavior, not a regression. Aligning all passthrough endpoints with chat.rs (which checks before reservation) is tracked in Guardrail input check runs after rate-limit reservation on /v1/messages, /v1/responses, /v1/embeddings (burns a quota slot on a content block) #542.
• LOW-1 — blocked responses/embeddings not attributed as guardrail blocks in telemetry: follow-up filed (Attribute guardrail blocks in telemetry for /v1/responses and /v1/embeddings (Blocked tab under-counts) #543). Observability only; the Blocked dashboard tab under-counts non-chat blocks. Threading applied_guardrails/guardrail_blocked through the non-chat emit paths is tracked in Attribute guardrail blocks in telemetry for /v1/responses and /v1/embeddings (Blocked tab under-counts) #543.
• LOW-2 — extra test cases: ADDED (instructions-only block; function_call_output block). The Bypass/fail-open path is correct by construction (the if let Block match forwards every non-Block verdict) and exercised by the benign-forwards test.

A second, focused audit of the MEDIUM-1 fix returned MERGE: the function_call_output channel is fully closed (string + array-of-parts forms; no over-scan of normal items; #153 intact), and it confirmed the generic output read also covers custom_tool_call_output / *_call_output. It found one further LOW residual — mcp_approval_response.reason (a niche MCP-approval justification that also reaches the model) was unscanned. Fixed (commit appended): responses_item_text now also reads reason, with a test. Net: every input-bearing channel on the input union is scanned.

Merge gate: both MEDIUMs fixed-or-justified; both LOW residuals fixed; LOW telemetry tracked in #543. No HIGH findings; both audits recommend merge.

Refs #719, #379, #542, #543.

[coderabbitai]

Warning

Review limit reached

@moonming, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 6 seconds. Learn how PR review limits work.

Your organization has run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Free

Run ID: eca0edf4-97e9-4424-b1fe-c712186149d6

📥 Commits

Reviewing files that changed from the base of the PR and between 8aaab9b and bd2984d.

📒 Files selected for processing (1)

• crates/aisix-proxy/src/responses.rs

📝 Walkthrough

Walkthrough

This PR extends input content filtering to embeddings and responses endpoints. Both handlers now convert their request inputs into chat format, execute configured guardrail chains, and block requests with 422 content-filter errors before reaching upstream when guardrails trigger. Tests verify blocking and pass-through behavior for both string and array input forms.

Changes

Input Guardrails for Embeddings and Responses

Layer / File(s)	Summary
Embeddings input guardrails crates/aisix-proxy/src/embeddings.rs	Import ChatFormat, add embeddings_input_to_chat helper to convert string or array inputs to chat messages, execute guardrail chain in handler with content-filter short-circuit on block, update documentation, and test guardrail blocking and pass-through for both input forms.
Responses input guardrails crates/aisix-proxy/src/responses.rs	Import chat types, add conversion utilities extracting text from response instructions and typed content inputs, execute guardrail chain with content-filter short-circuit before upstream dispatch, and test guardrail blocking for string and array inputs with upstream isolation.

Sequence Diagrams

sequenceDiagram
  participant Client
  participant EmbeddingsHandler
  participant GuardrailChain
  participant UpstreamEmbedding
  Client->>EmbeddingsHandler: POST /v1/embeddings with input
  EmbeddingsHandler->>EmbeddingsHandler: Convert input to ChatFormat
  EmbeddingsHandler->>GuardrailChain: Resolve guardrail chain
  alt Guardrail Blocks
    GuardrailChain-->>EmbeddingsHandler: GuardrailVerdict::Block
    EmbeddingsHandler-->>Client: 422 content_filter error
  else Guardrail Passes
    GuardrailChain-->>EmbeddingsHandler: GuardrailVerdict::Pass
    EmbeddingsHandler->>UpstreamEmbedding: Forward embedding request
    UpstreamEmbedding-->>Client: Embedding response
  end

Loading

sequenceDiagram
  participant Client
  participant ResponsesHandler
  participant GuardrailChain
  participant UpstreamResponse
  Client->>ResponsesHandler: POST /v1/responses with instructions and input
  ResponsesHandler->>ResponsesHandler: Convert instructions and input to ChatFormat
  ResponsesHandler->>GuardrailChain: Resolve guardrail chain
  alt Guardrail Blocks
    GuardrailChain-->>ResponsesHandler: GuardrailVerdict::Block
    ResponsesHandler-->>Client: 422 content_filter error
  else Guardrail Passes
    GuardrailChain-->>ResponsesHandler: GuardrailVerdict::Pass
    ResponsesHandler->>UpstreamResponse: Forward response request
    UpstreamResponse-->>Client: Response completion
  end

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

---

Note

🎁 Summarized by CodeRabbit Free

Your organization has reached its limit of developer seats under the Pro Plan. For new users, CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please add seats to your subscription by visiting https://app.coderabbit.ai/login.If you believe this is a mistake and have available seats, please assign one to the pull request author through the subscription management page using the link above.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}