Content filtering vs. schema validation
Content filtering inspects content and may transform, withhold, or block it according to configured criteria. Schema validation checks whether structured data conforms to a declared shape and constraints. More general validation can check additional conditions without changing the content.
Input validation checks content before an operation accepts it. Output validation checks the result before a recipient relies on it. For each, specify what acceptable content looks like.
For example, a customer record may need its phone number removed before delivery, while a record missing an account ID may need to be rejected.
Explore Dome: Tool Gateway · Docs: Guards.
Decide whether to change the content or reject it
Suppose a tool returns a customer record to an agent. The application needs an account identifier and support status, but not the customer's telephone number.
| Requirement | Appropriate behavior to consider |
|---|---|
| Remove the telephone number | Transform the returned object |
| Require an account identifier | Reject a response missing that field |
| Require a supported status value | Check the value against the allowed set |
| Refuse an oversized result | Enforce a size condition before delivery |
In this example, a filter removes the phone number, while a validator checks that the account ID is present and the support status is allowed.
Dome's guards distinguish filters, which transform content, from validators, which check it without changing it. Check the Docs for supported types and connections before choosing a configuration.
Explore Dome: Tool Gateway · Docs: Guards.
Check structure and business accuracy separately
A JSON object can parse successfully while missing required fields or containing incorrect values. A schema can constrain types, required properties, and other declared conditions. The JSON Schema basics show that an empty schema accepts any valid JSON, while a typed schema narrows the accepted values.
A schema can accept the format of an account ID even if that account doesn't exist, or accept a numeric balance that is out of date. Check those values against trusted business records.
“Structured outputs” describes an output-format mechanism, with guarantees depending on the implementation. It should not be treated as proof that a generated answer is accurate or that a requested action is authorized.
Use agent authorization when the issue is permission, and redaction when the issue is how much data to disclose.
Explore Dome: Authorization · Docs: Authorization model.
Check the result after transformation
Removing an optional phone number can leave a valid customer record. Removing a required account ID should make validation fail. Validate the filtered result against what the receiving application actually needs.
For the customer-record example, define which fields and values the receiving application needs after filtering. Then test missing fields, extra fields, nested objects, null values, wrong types, and content that triggers multiple controls.
A filter can run successfully even if a later check fails. Inspect the final content and the result of the overall operation. If a check blocks the request, record which check failed without unnecessarily logging the sensitive content itself.
Decide where a failed check should stop delivery. The guards documentation lists Dome's available types and the request or response directions in which they run.
Explore Dome: Tool Gateway · Docs: Guards.