Guard rules can carry input filters that run before a tool call executes and output filters that run on the response before it reaches the agent. Input filters can block patterns, cap length, check encoding and catch jailbreak phrasing. Output filters can mask personal data, redact columns, cap rows and mask regex matches.
Input filters
| Type | What it does |
|---|---|
| block_pattern | Denies the request if its parameters match a regular expression |
| max_length | Denies the request if its parameters exceed a length |
| encoding_check | Denies the request if its parameters contain invalid encoding |
| jailbreak_check | Denies the request if its parameters match known prompt injection phrasing |
The jailbreak check works on known phrases, such as "ignore previous instructions", attempts to reveal a system prompt, or role switch tricks. That is useful and cheap, and it is also a pattern list. A new phrasing it does not know will pass. Treat it as a filter, not a guarantee.
Output filters
| Type | What it does |
|---|---|
| pii_mask | Masks common personal data patterns: emails, social security numbers, card numbers, phone numbers, IP addresses, API keys, JWTs and bearer tokens |
| column_redact | Removes named columns or fields from structured output |
| row_limit | Caps the number of rows returned |
| regex_mask | Masks any part of the response matching a regular expression |
The documentation says the available types and parameters may expand, so treat the tables as the current concepts and not a frozen schema.
An example
A rule for tools whose names start with support_ could deny on a jailbreak check and cap input length at 8,000 characters. A second rule for tools named export_ or query_ could allow the call but mask personal data, redact an ssn column and an internal notes column, and cap results at 500 rows.
The first rule protects the agent from hostile input. The second protects people from an over eager query. They solve different problems and are written as separate rules.
Thresholds and scores
Each rule can also set a jailbreak threshold and an anomaly threshold. Defaults are 0.75 for jailbreak and 0.80 for anomaly unless your deployment is configured differently. The higher the value, the more confident Guard must be before treating a request as a jailbreak or an anomaly. A rule can also carry a rate limit as a count over a time window.
Where filters stop
Patterns are not understanding. A pii mask finds patterns it knows. Free text with a name and no other signal may pass. For sensitive data, limit what the tool can reach, not only what it can return.
Redaction hides, it does not delete. A column redact keeps the data in the source system and removes it from the response.
Filters see what they are handed. They run against tool traffic, not against what a model does with it afterward.
A practical order
- Start in monitor mode and read the audit trail.
- Add output masking where data is sensitive, since it is the least disruptive.
- Add row limits for export style tools.
- Add deny rules once you trust the patterns.
Rule order and first match behavior are in how Guard rules are evaluated.
Quick check
Do filters replace access control?
No. They reduce harm when a call is allowed. Limit which tools an agent can reach in the first place.
Will the jailbreak check catch every injection?
No. It matches known phrasing and scores requests, so novel wording can slip through.
Sources
Last reviewed: 19 October 2026.
