Guards

This page lists Guard types and the catalogs that back them.

• Filters rewrite or withhold content.
• Validators are pure predicates that block tool traffic when structured checks fail.

For how content inspection works, see the Guards concept. To configure Guards, see Inspect content.

Filters

Filters inspect and rewrite model or tool content on a connection and direction. They run in an ordered chain. A matching BLOCK short-circuits the chain.

Kinds

Filter kind is immutable after create.

Actions and precedence

When more than one JSON action targets the same path, precedence is BLOCK > OMIT > REDACT.

Path syntax

JSON Filter matcher.path values use a locked-down dialect. It is not JSONPath.

Exact-path matching is the default. The **. prefix redacts a field by name wherever it appears.

Recursive descent (**.phone) fits when the field name is a reliable sensitivity signal regardless of depth, when response shapes vary across tools, or when enumerating every exact path is brittle. Exact paths (primary_contact.phone) fit when only specific occurrences are sensitive and a same-named field elsewhere should pass through.

** is only recognized as a leading prefix. Mid-path ** (for example a.**.b) is treated as literal key characters and never matches. There is no JSONPath .., no wildcards, and no slice ranges.

Content matchers

JSON Filters can match on field values as well as key paths. Author them in matcher.contentMatchers on a JSON Filter config.

Supported content matcher arms: substring, ssn, credit_card, phone, digits, ip, email, and url.

Network-pattern matchers

Text and JSON content matchers can recognize common network-facing values without maintaining a literal list. Use ip with one or both address families enabled; email recognizes email addresses; and url recognizes absolute URLs with a scheme and host.

{
  "text": {
    "components": [
      {
        "action": "FILTER_ACTION_REDACT",
        "matchers": [
          { "ip": { "v4": true, "v6": true } },
          { "email": {} },
          { "url": {} }
        ]
      }
    ]
  }
}

At least one of ip.v4 or ip.v6 must be enabled. These matchers identify values by their standard address or URL syntax; use a substring matcher when you need to match one specific hostname, domain, or address.

For FILTER_ACTION_REDACT, set redactTarget to REDACT_TARGET_CONTENT_MATCHES to rewrite only the matched spans. Omit redactTarget to redact the whole field value. REDACT_TARGET_CONTENT_MATCHES requires a non-empty contentMatchers list.

{
  "json": {
    "components": [
      {
        "field_actions": [
          {
            "matcher": {
              "path": "**.note",
              "contentMatchers": [{ "ssn": {} }]
            },
            "action": "FILTER_ACTION_REDACT",
            "redactTarget": "REDACT_TARGET_CONTENT_MATCHES"
          }
        ]
      }
    ]
  }
}

Tool payload coverage

JSON Filters traverse every tool-result shape the MCP server can return.

Field matchers apply at any depth. A matching BLOCK short-circuits the Guard chain and replaces the result with a safe placeholder. The audit event identifies the blocking Filter.

Guard audit events

Every acting Filter chain emits guard.filter.evaluate at stage=completed. The event is verdictless: its payload records what the Filter did, while the enclosing tool.call or model.call carries result=allowed or result=denied.

Use payload direction (request or response), connectionType, toolName, model, and provider to distinguish the path. A blocking action produces a denied enclosing call with denial.reason=guard_blocked.

Filter-chain payloads carry:

Validator runs emit guard.validator.evaluate, also verdictless and completed-only. Its payload carries direction, failedByValidatorIds, failureReasons, connectionId, toolName, and connectionType. A failed Validator makes the enclosing tool.call denied with denial.reason=guard_blocked.

If an assigned Filter cannot be decoded or compiled, the gateway fails closed for that connection and direction until you roll back or clear the chain.

Streaming window

The effective window at stream time is max(workspace floor, connection override, per-request override). Any layer set to 0 drops out of the max.

Workspace floor fields are llm_filter_window_bytes and llm_filter_window_tokens. Per-connection flags live on Models. Setting the layers is on Configure the streaming window.

Validators

Validators are a Guard type for tool connections. They never rewrite content. Every assigned Validator must pass (order-independent AND). A failure blocks the whole tool request or response and records which conditions failed.

Kinds

Validator kind is immutable after create. Response Validators are MCP-only. Dome rejects assigning a tool_response Validator to a REST tool connection.

Conditions

Each Validator config is a protojson dome.guards.v1.ValidatorConfig with either a toolRequest or toolResponse arm.

A Validator must set at least one condition. Empty json objects are rejected.

Response target values:

JSON-bearing blocks are the same shapes Filters unwrap: text blocks whose value is JSON, and resource.text on resource blocks. Plain prose is skipped.

Assignment

Validators attach to a tool connection as an unordered set on one direction. Attach and detach are atomic. Direction must match the Validator kind (request with tool_request, response with tool_response).

Unlike Filters, Validator assignment is not an ordered chain. Every assigned Validator runs, and any failure blocks.

Create, assign, and inspect Validators on Inspect content.

Next steps

• Guards concept for Filters, Validators, directions, and fail-closed behavior
• Configure Guards to create, assign, and tune windows
• Models for per-connection filter windows