Guardrails Boundary Testing for ADK Agents

ShopMax India's ADK agents must refuse harmful, off-topic, and policy-violating requests before they ever reach the LLM. A guardrails layer intercepts the input, checks it against a blocklist and category classifier, and returns a canned refusal response without spending tokens on the LLM call. Guardrails boundary testing verifies that blocked queries are rejected cleanly, allowed queries pass through unchanged, and edge cases near the boundary are handled correctly.

The guardrails filter runs a series of checks in order: an exact blocklist match for known banned phrases, a pattern match for PII or sensitive data, and a topic classifier that rejects queries outside the agent's designated scope. The test verifies three conditions: blocked queries never reach the LLM (LLM call count stays zero), allowed queries reach the LLM exactly once, and the refusal message for blocked queries is a predefined safe string rather than an LLM-generated response.

The example below tests a ShopMax India input guardrails layer against five blocked queries and three allowed queries, asserting correct routing for each.

It gives the following output,

......... (8 passed in 0.01s)

In production, load the BLOCKLIST and ALLOWED_TOPICS from a configuration file so they can be updated without a code deploy. Log every blocked query with the reason and the customer session ID so the safety team can review patterns and refine the guardrails over time. Run the guardrails test suite on every commit and also on every update to the blocklist configuration file, since a misconfigured blocklist can either block legitimate queries or fail to stop harmful ones.