Enforcement Flow

Policy modes and automation levels control what happens AFTER a governance evaluation produces a decision. Understanding enforcement flow helps you safely roll out policies from testing to production.

Policy Modes

Policy modes determine whether decisions are enforced or just observed:

Mode	Behavior	Use When
`ENFORCE`	Decisions are enforced — DENY blocks the request	Production (after validation)
`MONITOR`	Violations logged but requests allowed	Testing new policies, collecting data
`REPORT_ONLY`	All requests allowed, metrics collected	Initial rollout, compliance reporting
`PLAN_ONLY`	Evaluate without side effects or evidence	Agent planning loops, UI previews

Mode Precedence

Modes can be set at multiple levels. Higher precedence wins:

Per-request override — ctx.mode in the evaluation context
Policy bundle mode — Set by governance team in signed bundle
Engine constructor — mode in TealEngineOptions
Default — MONITOR (safe for testing)

// Engine default
const engine = new TealEngine({ mode: 'MONITOR' });

// Per-request override (e.g., for specific high-risk actions)
const decision = await engine.evaluate(request, { ...ctx, mode: 'ENFORCE' });

Enforcement Behavior by Mode

ENFORCE Mode

evaluate() → Decision(DENY) → Request BLOCKED → Evidence emitted → Reason codes returned
evaluate() → Decision(ALLOW) → Request PROCEEDS → Evidence emitted
evaluate() → Decision(PENDING) → Request HELD → Approval token issued

MONITOR Mode

evaluate() → Decision(DENY) → Request ALLOWED → Evidence emitted with MONITOR_MODE_VIOLATION
evaluate() → Decision(ALLOW) → Request PROCEEDS → Evidence emitted

In MONITOR mode, the decision is computed identically to ENFORCE, but DENY decisions are downgraded to ALLOW with the MONITOR_MODE_VIOLATION reason code. This lets you observe what WOULD be blocked without actually blocking.

PLAN_ONLY Mode

evaluate() → Decision computed → NO evidence emitted → NO approval tokens → decision.plan = true

PLAN_ONLY is for agent planning loops. The decision tells you what would happen, but nothing is enforced or recorded.

Automation Levels (v1.3)

Automation levels add a second dimension to enforcement — they determine HOW the decision is applied:

Automation Level	Final Action	Human Involvement
`auto_allow`	ALLOW immediately	None
`auto_deny`	DENY immediately	None
`auto_sanitize`	MODIFY (sanitized content)	None
`approval_required`	PENDING (hold for human)	Required

Interaction with Policy Modes

Policy Mode	Automation Level	Result
ENFORCE	auto_deny	DENY (blocked)
ENFORCE	approval_required	PENDING (held)
MONITOR	auto_deny	ALLOW + `MONITOR_MODE_VIOLATION` logged
MONITOR	approval_required	ALLOW + logged (no approval token)
PLAN_ONLY	any	Decision computed, `plan: true`, no enforcement

FREEZE Rules and Enforcement

FREEZE rules bypass the mode system entirely. They ALWAYS enforce, regardless of the policy mode:

Policy Mode	FREEZE Rule Matches	Result
ENFORCE	Yes	DENY (`FREEZE_BLOCK`)
MONITOR	Yes	DENY (`FREEZE_BLOCK`) — not downgraded
REPORT_ONLY	Yes	DENY (`FREEZE_BLOCK`) — not downgraded
PLAN_ONLY	Yes	DENY (`FREEZE_BLOCK`) — still enforced

FREEZE rules are the only controls that override MONITOR and REPORT_ONLY modes. This ensures critical safety controls are never observational.

Graduated Rollout Pattern

The recommended approach for introducing new governance controls:

Week 1-2:  REPORT_ONLY  → Collect baseline data, no impact
Week 3-4:  MONITOR      → Log violations, observe patterns
Week 5:    ENFORCE      → Block violations in production

// Week 1: Observe
const engine = new TealEngine({ mode: 'REPORT_ONLY' });

// Week 3: Monitor (violations logged, not blocked)
const engine = new TealEngine({ mode: 'MONITOR' });

// Week 5: Enforce (violations blocked)
const engine = new TealEngine({ mode: 'ENFORCE' });

Use FREEZE rules from day one for critical safety controls (database.drop, system.shutdown). These don’t need a graduated rollout — they should always enforce.

Fail-Closed vs Fail-Open

When a module throws an exception during evaluation:

Setting	Behavior	Use When
`fail_closed` (default)	Module failure → DENY	Security-critical workloads
`fail_open`	Module failure → ALLOW	High-availability requirements

const engine = new TealEngine({
  fail_behavior: 'fail_closed',  // Default — recommended for security
});

fail_open means an attacker could potentially bypass governance by triggering module failures. Only use for non-security workloads where availability is more important than enforcement.

Evaluation Flow

How the 3-stage pipeline works

Automation Levels

The 4 automation levels in detail

FREEZE Rules

Immutable controls that bypass modes

Phased Adoption

Graduated rollout strategy

Getting Started

Core Concepts

Governance Domains

Policy Authoring

Architecture

Integrations

Deployment

API Reference

Cookbook

Compliance & GRC

Guides

Reference

Versions

Playground

Dashboard

Blog

Policy Modes

Mode Precedence

Enforcement Behavior by Mode

ENFORCE Mode

MONITOR Mode

PLAN_ONLY Mode

Automation Levels (v1.3)

Interaction with Policy Modes

FREEZE Rules and Enforcement

Graduated Rollout Pattern

Fail-Closed vs Fail-Open

Evaluation Flow

Automation Levels

FREEZE Rules

Phased Adoption

​Policy Modes

​Mode Precedence

​Enforcement Behavior by Mode

​ENFORCE Mode

​MONITOR Mode

​PLAN_ONLY Mode

​Automation Levels (v1.3)

​Interaction with Policy Modes

​FREEZE Rules and Enforcement

​Graduated Rollout Pattern

​Fail-Closed vs Fail-Open

​Related Documentation

Evaluation Flow

Automation Levels

FREEZE Rules

Phased Adoption

Policy Modes

Mode Precedence

Enforcement Behavior by Mode

ENFORCE Mode

MONITOR Mode

PLAN_ONLY Mode

Automation Levels (v1.3)

Interaction with Policy Modes

FREEZE Rules and Enforcement

Graduated Rollout Pattern

Fail-Closed vs Fail-Open

Related Documentation