Rule Types Overview

Rules decide whether a tool call should happen. Workflow Gates decide whether the agent has earned the right to move forward.

Use both together:

• rules for single-call behavior
• Workflow Gates for staged process enforcement

Pick The Right Tool

The pipeline order is:

1. check rules
2. sandbox rules
3. session rules
4. tool execution
5. check_output rules

Workflow Gates run with the runtime session and recorded evidence. They are enforced by run(), not dry-run evaluate().

Check Rules

Check rules run before the tool executes. If the condition matches, Edictum blocks the call or pauses for approval.

- id: block-dotenv
  type: pre
  tool: read_file
  when:
    args.path: { contains: ".env" }
  then:
    action: block
    message: "Read of sensitive file denied: {args.path}"

Use check rules when the bad behavior is specific and easy to name:

• block .env reads
• ask before production deploys
• block rm -rf
• block file writes outside a change request

Check Output Rules

Check output rules run after the tool executes. They inspect output and create violations.

- id: pii-in-output
  type: post
  tool: "*"
  when:
    output.text:
      matches_any:
        - '\b\d{3}-\d{2}-\d{4}\b'
        - '\b[A-Z]{2}\d{2}\s?\d{4}\s?\d{4}\s?\d{4}\s?\d{4}\s?\d{0,2}\b'
  then:
    action: redact
    message: "PII pattern detected in output."

Use check_output rules when the bad behavior is in the returned data, not the input arguments:

• redact SSNs from tool output
• warn on secret-looking strings
• block returning full database dumps from read-only tools

action: warn, action: redact, and action: block are valid here. redact and block only modify output for pure and read tools. write and irreversible tools fall back to warnings because the action already happened.

Session Rules

Session rules track cumulative behavior across the session.

- id: session-limits
  type: session
  limits:
    max_tool_calls: 50
    max_attempts: 120
    max_calls_per_tool:
      deploy_service: 3
      send_notification: 10
  then:
    action: block
    message: "Session limit reached. Summarize progress and stop."

Use them when you need:

• a hard cap on total tool calls
• a per-tool limit on dangerous actions
• attempt limits to catch retry loops

Sandbox Rules

Sandbox rules flip the model. Instead of listing bad cases, you define the boundary and block everything outside it.

- id: file-sandbox
  type: sandbox
  tools: [read_file, write_file, edit_file]
  within:
    - /workspace
    - /tmp
  not_within:
    - /workspace/.git
  outside: block
  message: "File access outside workspace: {args.path}"

Use sandbox rules when the surface area is open-ended:

• shell commands
• arbitrary file paths
• external URLs
• multi-tool file access patterns

They use within, not_within, allows.commands, and allows.domains. They do not use when / then.

Rulesets

Rules live in a ruleset:

apiVersion: edictum/v1
kind: Ruleset
metadata:
  name: my-agent-rules
defaults:
  mode: enforce
rules:
  - id: block-dotenv
    type: pre
    tool: read_file
    when:
      args.path: { contains: ".env" }
    then:
      action: block
      message: "Read of sensitive file denied: {args.path}"

defaults.mode can be enforce or observe. Observe mode lets rules fire and log without blocking the call.

Workflow Gates Are Separate

Rulesets are about tool calls. Workflow YAML is separate:

apiVersion: edictum/v1
kind: Workflow
metadata:
  name: feature-delivery

stages:
  - id: implement
    entry:
      - condition: file_read("specs/feature.md")
    checks:
      - command_matches: "git diff"
    exit:
      - condition: exec("pnpm test", exit_code=0)

Use Workflow Gates when the question is "what must happen first?" instead of "is this single tool call okay?"

Load The Ruleset

from edictum import Edictum

guard = Edictum.from_yaml("rules.yaml")

Next Steps

• Writing Rules
• Workflow Gates Runtime
• Sandbox Rules
• YAML Reference
• How the Pipeline Works