Guards
Why Dome inspects request and response content on tool and model connections
Guards inspect request and response content on tool and model connections. Filters can redact, omit, or block matching text. Validators block tool traffic when structured checks fail.
High-level overview
Guards attach to a specific model or tool connection and to one direction (request or response). They run on the content path after the call is authorized. When an assigned Guard cannot be evaluated, the gateway blocks that connection and direction. It never relays the traffic without inspection.
Two Guard types are available:
- Filters rewrite or withhold content. You assign them in an ordered chain on a connection and direction.
- Validators are pure predicates on tool connections. They never mutate. Every assigned Validator must pass.
Assigning a Filter and seeing it run looks like this:
- An operator creates a text Filter that redacts SSNs and assigns it to the response direction on a model connection.
- On the next gateway config sync, that connection runs the Filter over streamed completions.
- Matching spans are redacted before the agent sees them.
- If an assigned Filter later cannot be decoded, the gateway blocks that direction until the operator rolls back or clears the chain.
Guards inspect content at the connection and fail closed when inspection cannot run.
Directions
Each Guard assignment binds to one direction on a connection.
| Direction | Model connection | Tool connection |
|---|---|---|
request | Prompt before dispatch to the model provider | Tool arguments before dispatch to the MCP server |
response | Streamed completion before it reaches the agent | Tool result before it reaches the agent |
Request Guards can transform content or block a call. Response Guards run before any inspected content reaches the caller.
Filters
A Filter is workspace-scoped and versioned. Assigned connections pick up the active version on the next gateway sync. Previous versions remain available for rollback. Filter kind is immutable and decides which connections the Filter can attach to.
| Kind | Connection | Role |
|---|---|---|
text | Model | Substring and pattern inspection on prompts or completions |
json | Tool | Field-path and optional value-content inspection on tool arguments or results |
Each (connection, direction) slot holds one ordered Filter chain. Setting a chain replaces the complete list for that slot. Model connections accept only text Filters. Tool connections accept only json Filters.
Narrow transforms ahead of broad blocking matchers keep audit attribution predictable when multiple matchers could fire. A matching BLOCK short-circuits the chain. Kinds, actions, path syntax, and content matchers are on the Guards reference.
JSON Filters apply symmetrically to MCP tool calls. A request-direction Filter inspects outbound tools/call arguments before the gateway forwards them. A response-direction Filter inspects the tool result before it reaches the agent. Use Filters when sensitivity is a property of the content (free-text arguments, documents, transcripts). Prefer path matchers when sensitivity is a property of the field name.
On a JSON chain, REDACT and OMIT can co-occur — neither short-circuits the other. BLOCK wins the chain, but earlier actions remain in the audit payload. Acting Filters emit the verdictless guard.filter.evaluate event with direction, actions, blockedByFilterIds, redactedByFilterIds, and omittedByFilterIds. A block makes the enclosing tool.call or model.call complete with result=denied and denial.reason=guard_blocked. Payload details are on the Guards reference.
Validators
A Validator is workspace-scoped and versioned. It checks structured conditions on a tool request or MCP tool response and blocks when any condition fails. Validators never redact or omit fields.
| Kind | Edge | Role |
|---|---|---|
tool_request | Request | Required paths and size limits on tool arguments |
tool_response | Response | Required paths and shape checks on MCP tool results |
Validators attach as an unordered set on a tool connection and direction. Every assigned Validator must pass. Response Validators are MCP-only. Condition catalogs are on the Guards reference.
Streaming model responses
LLM chat responses arrive as fragmented SSE chunks. The gateway buffers each connection's response into a sliding window and runs response Filters over the decoded text so multi-chunk patterns are visible.
The effective window is max(workspace floor, connection override, per-request override). A layer set to 0 drops out of the max. Window bounds and where each layer is set are on the Guards reference. How to set them is on Guards.
Next steps
With the Guards content-inspection model in mind, continue with:
- Architecture concept for where Guards sit in the request path
- Rules concept for allow and deny before content inspection
- Guards reference for Filter and Validator catalogs
- Configure Guards to create Filters and Validators, assign them, and tune streaming windows