AISIX 1.0.0: Make AI Guardrails Measurable Before You Rely on Them

Key Takeaways

• AISIX 1.0.0 connects saved-rule testing in AISIX Cloud with scores from screened requests, helping teams evaluate a policy before relying on it.
• A useful rollout moves from representative samples to real traffic: verify the decisions, investigate unavailable checks, and confirm the intended coverage.
• Inspection depends on the request path. Files API traffic, model-generated reasoning, and the timing of MCP tool execution require explicit design decisions.
• Review the release's configuration, provider-integration, and cooldown changes as part of the same application rollout.

A support assistant needs to handle three requests: a customer asking how to reset a password, a caller telling it to ignore its instructions, and a customer quoting that same instruction while reporting a suspected attack.

The team wants to serve the first, refuse the second, and understand how to handle the third. Turning on a safety rule is only the beginning. Before relying on it, the team needs to know why it reaches a decision, whether that decision holds on real traffic, and which parts of the assistant's work it actually covers.

AISIX 1.0.0, released on September 4, 2026, helps teams work through those questions. Saved-rule testing, semantic scores, and clearer failure attribution make guardrail behavior easier to examine throughout a rollout. The support assistant provides a practical way to see how these capabilities fit together.

Start with a Decision You Can Explain

The assistant's first challenge is separating prohibited instructions from legitimate conversation. Semantic screening uses an embedding model to compare text with examples, complementing keyword matching when callers express similar ideas in different words.

The resulting similarity score needs context. It is not a probability that a request is malicious, and its meaning depends on the model, examples, languages, and application traffic. A threshold should therefore reflect the team's own evaluation cases.

In AISIX, a text is refused when it reaches a deny example's threshold. With an allow list, it is refused when it falls below the threshold for every allow example. Deny takes precedence. Raising a threshold consequently has different effects on these two lists.

The new AISIX Cloud test panel makes these decisions easier to inspect. It shows the score, threshold, nearest example, and verdict for a saved semantic guardrail. The team can test its routine questions, prohibited instructions, and quoted attack reports, then examine where the policy disagrees with its expectations. These are proposed evaluation cases, not claims about the scores a model will produce.

Save changes before testing: the panel evaluates the stored configuration. It runs through the control plane and does not verify gateway deployment or attachment coverage. The open-source gateway has no equivalent dashboard panel and can begin calibration with real traffic in monitor mode.

For the team using AISIX Cloud, a satisfactory test result now creates the next question: does the same rule actually run when a customer calls the assistant?

Follow the Decision into Real Traffic

To answer that question, attach the rule at the intended scope and observe requests in monitor mode. The calibration workflow uses live scores to connect the team's sample-based expectations with what the gateway evaluates.

A screened request can carry guardrail_scores even when it is allowed. That matters for the assistant's ordinary password-reset questions: the team can look for evidence of evaluation rather than infer coverage from a quiet block counter.

The score record identifies the closest example by index without copying the example or screened text into that record. It provides decision context while limiting the contents of that field. Other content-capture and exporter settings still need their own retention review.

Suppose the assistant continues serving requests, but an embedding service becomes unavailable. A successful response alone cannot tell the team whether a check completed. AISIX 1.0.0 records fail-open attribution more consistently through guardrail_bypassed_reason and expands bypass metrics. Rules that cannot build at runtime also become visible in /status/config.

These signals lead to different corrective actions. An incorrect match calls for reviewing examples and thresholds. An unavailable check calls for examining dependencies and failure policy. A rule absent from the request path calls for checking configuration and scope. Tuning the threshold cannot solve all three.

Once the team has reviewed real matches, missed cases, and failures, it can move to block mode and verify both allowed and refused requests. AISIX supplies the evidence; the team chooses the acceptable trade-off.

That establishes confidence in the tested conversation path. The next step is to follow what the assistant does beyond answering a message.

Check Coverage as the Assistant Starts Doing More

Suppose the same assistant can update a support ticket through an MCP tool. A rule that applies to its model requests does not automatically inspect the tool call: MCP calls have no model, so model-scoped guardrails do not apply.

The existing MCP guardrail model also separates two moments. An input block prevents the call from reaching the upstream tool. An output block withholds the result after execution and cannot undo the action.

For a ticket update, the team should therefore verify permission and prohibited arguments before execution, then treat result inspection as a separate control. This gives the earlier question—whether the rule runs on the intended traffic—a concrete business consequence.

Now consider a file-upload workflow. The 1.0.0 inspection boundaries exclude /v1/files from input and output guardrail checks. Inspecting a batch request envelope does not inspect the records in its uploaded file. An application that requires file-content screening needs to address that before sending the file through the gateway.

Conversation history introduces another boundary. Caller-replayed reasoning is inspected on supported paths, while model-generated reasoning is outside output inspection. Anthropic signed thinking blocks can trigger a block action, but mask actions do not rewrite those signed bytes.

Following the assistant's actual workflow makes these limits easier to evaluate: messages, tool arguments, tool results, and files enter at different points. The team can decide where each required control belongs and test that point directly, instead of extrapolating from a successful chat test.

Bring the Same Checks into the 1.0.0 Upgrade

This application-level review also gives the release's other changes a practical place in the rollout. Use the 1.0.0 upgrade notes as the complete migration checklist, and prioritize four checks in staging:

1. Validate policy configuration. Non-empty semantic example lists require their corresponding thresholds. Some previously accepted values now fail validation; migration can also repair previously skipped guardrail rows so they begin enforcing.
2. Exercise unavailable checks. Verify request- and response-side failure policies with unreadable content. Held-back streaming output has stricter fail-closed handling when no scannable content can be recovered.
3. Make cooldown explicit. Set cooldown.enabled: true on direct models that should retain implicit pre-1.0 cooldown. Without it, failed targets are not temporarily removed by cooldown. Check this separately from per-request retries and failover.
4. Verify clients and deployment scripts. Exercise the documented streaming error changes and pin full image versions rather than expecting abbreviated tags to advance.

If the assistant forwards caller context or uses different model providers, review those integrations at the same time. Version 1.0.0 extends client-header forwarding across model traffic, MCP servers, passthrough routes, and Realtime. Confirm which caller-controlled values may reach each upstream, with particular attention to credentials and the release-specific forwarding contract.

The new reasoning-effort mapping lets the selected direct model adapt an application's requested effort to an upstream's vocabulary. With mappings medium → high and high → max, a request for medium becomes high once, not max. The lookup is exact and case-sensitive; absent or unmapped values stay unchanged, and the upstream must support the result.

These integration changes address request handling rather than guardrail accuracy. Test them alongside policy changes so that application owners can distinguish a safety decision from a changed provider request or routing behavior.

Make One Application the Starting Point

For the support assistant, the rollout now has a clear progression: explain the rule's decisions on representative text, observe those decisions on real requests, and verify coverage wherever the application reads content or performs an action.

AISIX 1.0.0 makes that process easier to support with evidence. Start with one application and a policy whose intended behavior the team can describe, follow the semantic guardrail calibration guide, and keep the resulting cases as a repeatable check for future changes. The team then has a concrete basis for deciding when to enable a rule and when to revisit it.