Skip to main content
Before deploying an agent to production, verify it meets your organization’s criteria for trustworthiness. This page explains how to define deployment gates, assess readiness, and document sign-off decisions.

Deployment Gates

A deployment gate is a checkpoint where an agent must demonstrate acceptable risk before proceeding. Gates convert subjective “is it ready?” conversations into objective pass/fail decisions.

Gate Structure

Each gate specifies:
ComponentDescription
Trust Score thresholdMinimum overall score required (e.g., ≥ 0.70)
Dimension requirementsMinimum scores per pillar (Reliability, Security, Safety)
Severity limitsMaximum allowed findings at each severity level
Harness specificationWhich evaluation harness must be run

Example Gate Configuration

production-gate:
  trust_score: 0.70
  dimensions:
    reliability: 0.65
    security: 0.75
    safety: 0.70
  severity_limits:
    critical: 0     # No Severity 1 findings allowed
    high: 2         # At most 2 Severity 2 findings
    medium: 10      # At most 10 Severity 3 findings
    low: unlimited
  harness: trust-score

Readiness Assessment

Run a Trust Score evaluation and compare results against your gate criteria:

Step 1: Run the Evaluation

Execute your standard harness against the candidate agent version:
curl -X POST "https://api.vijil.ai/v1/evaluations" \
  -H "Authorization: Bearer $VIJIL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "agent_id": "your-agent-id",
    "harness_id": "trust-score"
  }'

Step 2: Compare Against Gates

CriterionGate RequirementActual ResultStatus
Trust Score≥ 0.700.78✓ Pass
Reliability≥ 0.650.72✓ Pass
Security≥ 0.750.81✓ Pass
Safety≥ 0.700.74✓ Pass
Critical findings00✓ Pass
High findings≤ 21✓ Pass
Result: Agent passes all deployment gate criteria.

Step 3: Document the Decision

Record the evaluation results, gate configuration, and deployment decision for audit purposes.

Conditional Deployment

When an agent fails gate criteria but business needs require deployment, conditional deployment allows proceeding with compensating controls.

When to Use Conditional Deployment

  • Agent scores slightly below threshold but improves on previous version
  • Critical business deadline with acceptable residual risk
  • Compensating controls adequately mitigate identified failures

Compensating Controls

Failure TypeCompensating Control
Prompt injection vulnerabilityDeploy with input guardrails blocking injection patterns
Hallucination riskAdd output guardrails for factual verification
Scope boundary issuesRestrict agent to narrow use case with limited tools
Privacy concernsDeploy with PII redaction on input and output

Conditional Deployment Checklist

Before approving conditional deployment:
1

Document residual risk

List each failing criterion and its risk score
2

Identify compensating controls

Map specific Dome guards to each identified risk
3

Set monitoring thresholds

Define alert triggers for production behavior
4

Establish remediation timeline

Commit to addressing root causes by a specific date
5

Obtain explicit sign-off

Get written approval from both Business Owner and Risk Officer

Sign-Off Workflow

Deployment decisions require alignment between stakeholders with different priorities.

Roles and Responsibilities

RoleResponsibilitySigns Off On
Business OwnerAccountable for agent value deliveryFunctional readiness, business case
Risk OfficerAccountable for risk managementSecurity, safety, compliance
Technical LeadAccountable for implementation qualityTechnical readiness, monitoring

Sign-Off Process

Sign-off process flow: Evaluation Complete to Gate Check to Decision, then Pass leads to Deploy, Fail leads to Remediate or Conditional deployment with re-evaluation loop

Documentation Requirements

Every deployment decision should include:
  1. Evaluation report — Full Trust Report with scores and findings
  2. Gate criteria — The specific thresholds applied
  3. Comparison table — Actual vs. required for each criterion
  4. Decision record — Approved, conditionally approved, or rejected
  5. Sign-off signatures — Business Owner and Risk Officer approval
  6. Conditions (if applicable) — Compensating controls and remediation timeline

Setting Thresholds

Thresholds should reflect your organization’s risk tolerance and the agent’s deployment context.

Threshold Guidelines by Use Case

Use CaseTrust ScoreSecurityNotes
Internal tool≥ 0.60≥ 0.65Lower risk exposure
Customer-facing≥ 0.70≥ 0.75Reputation and compliance risk
Regulated industry≥ 0.80≥ 0.85Regulatory requirements
High-stakes decisions≥ 0.85≥ 0.90Material business impact

Adjusting Thresholds

Raise thresholds when:
  • Agent has access to sensitive data or critical systems
  • Agent serves external users or customers
  • Failures would trigger regulatory or legal consequences
  • Agent operates with minimal human oversight
Lower thresholds when:
  • Agent handles low-risk, internal tasks
  • Strong compensating controls are in place
  • Human review is part of every workflow
  • Agent operates in a sandbox environment

Tracking Readiness Over Time

Monitor readiness across agent versions to identify trends:
VersionDateTrust ScoreCriticalHighStatus
v1.0Jan 150.5828Failed
v1.1Feb 10.6515Failed
v1.2Feb 150.7202Passed
v1.3Mar 10.7801Passed
Improving scores with decreasing findings indicate effective remediation. Declining scores signal regression requiring investigation.

Next Steps