Skip to main content
Understanding these core concepts will help you get the most out of Agent Control. Start with the high-level architecture to see how components fit together, then dive into evaluators to understand how checks are implemented.

​
Controls

A Control is a single rule that defines what to check and what to do when a condition is met. 
Control = Scope + Condition + Action
Example: “If the output contains an SSN pattern, block the response.” 
{
  "name": "block-ssn-in-output",
  "execution": "server",
  "scope": { "step_types": ["llm"], "stages": ["post"] },
  "condition": {
    "selector": { "path": "output" },
    "evaluator": {
      "name": "regex",
      "config": { "pattern": "\\b\\d{3}-\\d{2}-\\d{4}\\b" }
    }
  },
  "action": { "decision": "deny" }
}
Leaf conditions pair a selector with an evaluator. Composite conditions can use and, or, and not to combine multiple leaf checks.

​
Scope

Scope defines when a control runs by filtering which steps are evaluated. Fields:
  • step_types: Step types to target (e.g., ["tool", "llm"]). If null, applies to all types.
  • step_names: Exact step names to target (e.g., ["search_db", "send_email"]).
  • step_name_regex: Regex pattern to match step names (e.g., "^db_.*").
  • stages: When to evaluate — ["pre", "post"].
    • pre: Check before execution (block bad inputs, prevent prompt injection)
    • post: Check after execution (filter bad outputs, redact PII)
Example: apply to all tool steps before execution: 
{
  "scope": {
    "step_types": ["tool"],
    "stages": ["pre"]
  }
}
Example: target specific database operations: 
{
  "scope": {
    "step_names": ["query_database", "execute_sql", "db_lookup"],
    "stages": ["pre"]
  }
}
Example: match multiple steps with regex: 
{
  "scope": {
    "step_name_regex": "^db_.*",
    "stages": ["pre", "post"]
  }
}

​
Selectors

A Selector defines what data to extract from the payload for evaluation.
PathDescriptionExample Use
inputStep input (tool args or LLM input)Check for prompt injection
outputStep outputCheck for PII leakage
input.queryTool input fieldBlock SQL injection
nameStep name (tool name or model/chain id)Restrict step usage
context.user_idContext fieldUser-based rules
*Entire stepFull payload analysis
Controls can also scope by step type/name/stage: 
{
  "scope": {
    "step_types": ["tool"],
    "step_names": ["search_database", "execute_sql"],
    "step_name_regex": "^db_.*",
    "stages": ["pre"]
  }
}

​
Evaluators

An Evaluator receives the selected data and checks it against configured rules. 
{
  "evaluator": {
    "name": "list",
    "config": {
      "values": ["DROP", "DELETE", "TRUNCATE"],
      "case_sensitive": false
    }
  }
}

​
Actions

An Action defines what happens when a control matches. 
{
  "action": {
    "decision": "deny"
  }
}

​
Priority Semantics

  1. Deny wins — if any deny control matches, execution is blocked.
  2. Steer second — if any steer control matches (and no deny), steering context is returned.
  3. Allow/warn/log — observability actions that do not block execution.

​
Learn more