Verifier integration
The verifier integration allows Guardrail API to delegate gray-area decisions to a separate service. Instead of executing untrusted code or blindly allowing ambiguous requests, Guardrail can ask a verifier to analyze intent and risk and return a structured recommendation.
When to use a verifier
Rules and pattern-based policy are ideal for clear allow/block scenarios. A verifier is useful when intent is hard to classify deterministically, such as:
- Multi-step or indirect prompts that may hide malicious behavior.
- Requests involving complex context, such as code snippets or uploaded files.
- Situations where the potential impact of a mistake is high and additional scrutiny is required.
High-level integration model
When configured, Guardrail API calls the verifier with a structured payload that contains the relevant request and response data along with metadata. The verifier returns a decision object, which Guardrail uses as one input to its final allow / block / clarify decision.
- Guardrail receives a request and evaluates it against policy packs.
- If policy determines that a verifier is required, Guardrail builds a verifier payload (including the content and metadata necessary to assess risk).
- Guardrail sends this payload to the configured verifier endpoint.
- The verifier analyzes the payload and returns a structured recommendation.
- Guardrail merges that recommendation with rule-based policy and produces a final decision.
Design goals for verifiers
Verifiers are designed as assessment engines, not execution engines. They should help you understand intent and risk, not run arbitrary user code or directly interact with external systems.
- Keep verifier inputs and outputs strictly structured and documented.
- Treat verifier timeouts or failures conservatively, favoring safety if a clear decision cannot be made.
- Log verifier interactions so you can later explain why a decision was made in a particular way.
Operational considerations
Because verifiers may rely on external models or services, they can introduce latency and additional points of failure. Use them selectively for the highest-risk or most ambiguous requests rather than every interaction.
- Define clear timeouts and fallbacks for verifier calls.
- Decide ahead of time how to handle cases where the verifier is unavailable (for example, block, allow with restrictions, or require human review).
- Monitor verifier performance and error rates alongside Guardrail Core metrics.