Dome Systems

AI guardrails

AI guardrails are controls intended to keep an AI application's inputs, outputs, or actions within defined constraints. “LLM guardrails” often refers more narrowly to controls around language-model interactions. The terms cover several kinds of controls, and implementations vary.

A guardrail might detect prohibited content, check a structured response, constrain an action, or route a case for review. To evaluate a guardrail, check what it inspects, where it runs, and what happens when it fails.

Explore Dome: Dome Platform · Docs: Guards.

Guardrails vs. authorization: what are you trying to prevent?

Suppose an assistant searches customer cases and drafts an internal summary. The team has three concerns: the assistant should not access another team's cases, receive unnecessary phone numbers, or accept a malformed tool response.

ConcernControl question
Access to another team's casesIs this caller permitted to perform this operation?
Unnecessary phone numbersWhich fields should be removed or obscured?
Malformed responseDoes the response have the required fields and values?

All three may be described as guardrails, but they need different controls. Authorization determines permission, redaction limits disclosure, and validation checks content against requirements.

Dome uses rules for authorization and guards for configured content inspection.

Explore Dome: Authorization · Docs: Authorization model.

Check which content the guardrail can inspect

A filter on model responses may never see the phone number in a tool result. Check which parts of the interaction the guardrail receives: prompts, responses, tool arguments, tool results, attachments, and streamed output.

For example, Amazon Bedrock's content-filter documentation names the content types its filters evaluate and identifies exclusions for tool-use content. Check those exclusions when deciding which interactions the filters will cover.

Next, check what happens when the guardrail detects a problem. Does it block the request, rewrite content, produce a warning, or simply create a log entry? A log entry may help an investigation, but it doesn't stop the content from being disclosed.

Also decide what happens if the inspection cannot run. Should the application block the content or let it through?

Explore Dome: Tool Gateway · Docs: Guards.

Make sure useful work can still get done

Use a small evaluation set containing content that should pass, content that should be blocked or transformed, and ambiguous cases worth human review. For each case, record the expected result and inspect what the receiving component actually sees.

For the customer-case assistant, test both false positives, such as a useful summary blocked by mistake, and misses, such as a phone number reaching the recipient. The filtered result should still contain enough information to do the job.

Dome's guards documentation explains how to attach filters and validators to the request or response direction of a connection. Test the selected controls against the content and unwanted behavior they need to detect.

For each guardrail, record what it inspects, what it does on a match or failure, and the test cases used to check that behavior.

Explore Dome: Tool Gateway · Docs: Guards.