Third-Party Guardrail Data Flow
Compare where each remote guardrail provider evaluates content, what AISIX sends it, and what comes back, across all six remote guardrail integrations.
Six of the guardrail providers documented under Choosing a Guardrail Provider send request or response content to a service outside your AISIX deployment to get an evaluation decision. This page collects their data flow in one place so a security or compliance review does not have to open all six pages to answer "where does the content go."
The four built-in guardrails — keyword, semantic screening, PII, and Presidio — are not in this table. Keyword and PII evaluate inside AISIX. Presidio calls a service you deploy and control, not a third-party vendor endpoint. Semantic screening sends the flagged text to whichever embedding model provider you configured for it, which is the same provider-key data flow already documented for that model, not a dedicated guardrail vendor.
What Each Remote Provider Receives
Every guardrail below is scoped by hook point: an input guardrail sends the caller's request content, an output guardrail sends the model's response content, and both sends each direction separately as it passes that hook point. None of the six batches request and response content together in one call.
| Provider | Guardrail kind | Evaluates at | What AISIX sends | What comes back |
|---|---|---|---|---|
| Lakera Guard | lakera | Lakera's API (api.lakera.ai by default, or a regional/self-hosted Lakera endpoint you configure) | The message text at the scoped hook point, plus your Lakera API key and optional project ID | A flagged/not-flagged decision with detector categories; PII-only detections include span offsets AISIX uses to mask the text locally |
| OpenAI Moderation | openai_moderation | OpenAI's Moderation API (api.openai.com by default, or a compatible endpoint you configure) | The message text at the scoped hook point, plus your OpenAI API key | A flagged boolean and per-category scores; the guardrail never rewrites text, so a flagged detection blocks |
| AWS Bedrock Guardrails | bedrock | The AWS Bedrock ApplyGuardrail API in the region you configure | The message text at the scoped hook point, sent under AWS SigV4 with your access key (or STS session token) | A block/anonymize decision; anonymized text comes back with placeholders such as {EMAIL} that AISIX forwards in place of the original value |
| Azure AI Content Safety | azure_content_safety, azure_content_safety_text_moderation | Your Azure AI Content Safety resource endpoint (*.cognitiveservices.azure.com), which you choose the region for when you create the resource | The message text at the scoped hook point, plus your Azure subscription key | A Prompt Shield attack-detected flag, or Text Moderation category severities and blocklist matches; the guardrail never rewrites text |
| Alibaba Cloud Content Moderation | aliyun_text_moderation | Alibaba Cloud's TextModerationPlus API, at green-cip.<region>.aliyuncs.com for the region you configure | The message text at the scoped hook point, plus your Alibaba Cloud credential | A risk level AISIX compares against your configured threshold; the guardrail never rewrites text |
| Alibaba Cloud AI Guardrails | aliyun_ai_guardrail | Alibaba Cloud's MultiModalGuard API, at green-cip.<region>.aliyuncs.com for the region you configure | The message text at the scoped hook point, plus your Alibaba Cloud credential | A composite decision driven by the policy configured in the AI Guardrails console: block, or sensitive-data masking; every call is also recorded in that console |
Reading This Table for a Data-Processing Review
A few points apply across all six rows:
- The vendor, not AISIX, chooses the region for AWS Bedrock, Alibaba Cloud Content Moderation, and Alibaba Cloud AI Guardrails — you set
regionon the guardrail, and AISIX derives the endpoint from it. Lakera and Azure AI Content Safety are scoped by the endpoint or resource you provision with that vendor. OpenAI Moderation calls a fixed default endpoint unless you override it with a compatible service. - Failure handling is a separate setting from data flow. Whether a guardrail blocks or allows traffic when the remote call itself fails (
fail_open) does not change what was already sent in that call. See When a Guardrail Cannot Complete Its Check for that setting. - Caller-facing errors never echo the evaluated content back. Only your gateway log and usage record retain guardrail evidence, per What the Gateway Records — this page is about what leaves your deployment toward the guardrail vendor, not what AISIX retains afterward.
- Streamed responses are buffered before an
outputorbothguardrail can inspect them. See Streaming Output for how that affects latency and partial-content handling; it does not change which text is sent once the buffer is evaluated.
For each vendor's own data retention, sub-processor, and certification posture, see that vendor's own security or trust documentation — this page describes what AISIX sends and receives, not how the vendor handles it afterward. For API7's own compliance posture, see Compliance and Trust Center.
Next Steps
- Guardrail Behavior — hook points, enforcement modes, and remote failure handling shared by every guardrail in this table.
- Choosing a Guardrail Provider — compare all guardrails, including the four that do not send content to a third party.
- Data Residency Matrix — where AISIX Enterprise itself sends configuration and usage data, as a separate question from the guardrail data flow on this page.