Skip to main content

​
Overview

Policies in Cascade define the rules that govern acceptable agent behavior. A policy is a declarative object that is evaluated against agent traces captured at runtime. Policies do not execute code and do not directly enforce behavior. Instead, they produce structured evaluations that enforcement modes act upon. Cascade supports multiple policy types, each designed to address a different class of agent behavior. Policies are defined as structured configuration files (for example JSON) and can be reused across agents and workflows. At runtime, traces emitted by the agent are compared against the active policies to determine whether behavior remains in compliance.

​
Policy Structure

All policies share a common top-level structure. 
{
  "name": "example_policy",
  "type": "tool",
  "description": "Restricts which tools the agent may access",
  "severity": "high",
  "rules": {}
}
Common fields:
  • name: Unique policy identifier
  • type: Policy type
  • description: Human-readable description
  • severity: Impact level if violated
  • rules: Type-specific configuration

​
Policy Types

Cascade currently supports the following policy types.

​
Tool Policies

Tool policies define which tools an agent is allowed or disallowed to use, including indirect usage through other agents or third-party systems. Tool policies are evaluated whenever a tool is invoked. If a section is left empty, it is treated as unrestricted by default. 
{
  "name": "tool_access_policy",
  "type": "tool",
  "severity": "critical",
  "rules": {
    "allowed_tools": [
      "SearchTool",
      "ReadOnlyDBTool"
    ],
    "disallowed_tools": [
      "DeleteDatabaseTool",
      "PaymentExecutionTool"
    ]
  }
}
Behavior:
  • If allowed_tools is specified, only those tools may be used
  • If disallowed_tools is specified, those tools are always blocked
  • If both are empty, no tool restrictions are applied

​
Categorization Policies

Categorization policies classify agent outputs into semantic categories and mark certain categories as out of policy. These policies are evaluated on LLM outputs and final agent responses. 
{
  "name": "content_safety_policy",
  "type": "categorization",
  "severity": "high",
  "rules": {
    "disallowed_categories": [
      "harmful",
      "hateful",
      "violent",
      "self_harm"
    ]
  }
}
Behavior:
  • Agent outputs are categorized at runtime
  • If an output is assigned to a disallowed category, the policy is violated
  • Categories are used as structured signals across safety and security systems

​
Semantic Policies

Semantic policies define behavioral constraints using natural language. These policies are evaluated using semantic reasoning over agent traces and outputs. 
{
  "name": "semantic_behavior_policy",
  "type": "semantic",
  "severity": "medium",
  "rules": {
    "description": "The agent must not provide legal or medical advice or present speculative information as fact.",
    "patterns_to_exclude": [
      "API keys",
      "SSN patterns",
      "PII"
    ]
  }
}
Behavior:
  • Natural language rules define unacceptable behavior
  • Semantic evaluation considers intent and context
  • Optional pattern exclusion provides deterministic safeguards for sensitive data

​
Severity Levels

Each policy includes a severity level that indicates the impact of a violation. 
Critical – critical security violation  
High     – high risk  
Medium   – moderate risk  
Low      – low risk
Severity is used by:
  • Enforcement modes
  • Alerting systems
  • Risk aggregation and reporting

​
Policy Integration

Policies are stored as standalone files and referenced during agent initialization or execution. This allows policies to be updated without modifying agent code.

​
Referencing Policies at Initialization

from cascade import init_tracing

init_tracing(
    project="my_project",
    enforcement_mode="detect",
    metadata={
        "policies": {
            "tool_access": "policies/tool_access_policy.json",
            "content_safety": "policies/content_safety_policy.json"
        }
    }
)

​
Referencing Policies per Workflow

from cascade import trace_run

with trace_run(
    "SupportAgent",
    metadata={
        "agent_id": "support-agent",
        "policies": {
            "semantic_behavior": "policies/semantic_behavior_policy.json"
        }
    }
):
    agent.run(ticket)
Policies can be mixed and matched across agents and workflows.

​
Policy Validation

Before using a policy in production, Cascade provides a validation utility to ensure the policy format is correct. This helps catch configuration errors early and prevents runtime failures. 
from cascade import validate_policy

validate_policy("policies/tool_access_policy.json")
Validation checks include:
  • Schema correctness
  • Required fields
  • Supported policy types
  • Valid severity values
Only validated policies should be deployed to production.

​
Templates and Examples

Cascade provides a set of ready-to-use policy templates for common use cases. Examples include:
  • Restricting tool access for production agents
  • Preventing harmful or unsafe outputs
  • Blocking sensitive data exposure
  • Enforcing scope boundaries for autonomous agents
Templates can be downloaded and should be changed to fit specific workflows.

​
Next Steps

After defining policies:
  1. Validate policy files
  2. Attach policies to agents or workflows
  3. Start in Observe mode to understand behavior
  4. Progress to Detect or Enforce as confidence increases