Overview

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.

Path	Description	Example Use
`input`	Step input (tool args or LLM input)	Check for prompt injection
`output`	Step output	Check for PII leakage
`input.query`	Tool input field	Block SQL injection
`name`	Step name (tool name or model/chain id)	Restrict step usage
`context.user_id`	Context field	User-based rules
`*`	Entire step	Full 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

Deny wins — if any deny control matches, execution is blocked.
Steer second — if any steer control matches (and no deny), steering context is returned.
Observe — non-blocking observability action that does not affect execution.

Getting Started

Concepts

How-to Guides

Integrations

Third-Party Agents

Examples

Reference

Controls

Scope

Selectors

Evaluators

Actions

Priority Semantics

Learn more

​Controls

​Scope

​Selectors

​Evaluators

​Actions

​Priority Semantics

​Learn more

Controls

Scope

Selectors

Evaluators

Actions

Priority Semantics

Learn more