FREEZE Rules & Immutable Controls

FREEZE rules are TealTiger’s circuit breaker for governance — non-overridable safety controls that cannot be modified, disabled, or bypassed regardless of policy changes, hot-swaps, or administrative actions. They represent the absolute floor of governance enforcement.

FREEZE rules are intentionally immutable. Any attempt to modify, disable, or remove a FREEZE rule triggers a FREEZE_TAMPER_ATTEMPT event that is logged, alerted, and cannot be suppressed. This is by design — these are your last line of defense.

Why This Matters

Risk	Without FREEZE Rules	With FREEZE Rules
Policy hot-swap attack	Attacker replaces policy bundle to remove safety controls	FREEZE rules persist across hot-swaps — cannot be removed
Insider threat	Admin disables critical guardrails	FREEZE rules reject modification attempts with tamper evidence
Configuration drift	Safety controls gradually weakened over time	FREEZE rules are immutable — no drift possible
Prompt injection escalation	Injected prompt convinces agent to disable governance	FREEZE rules operate below the agent layer — unreachable by prompts
Compliance regression	Regulatory controls accidentally removed during deployment	FREEZE rules survive all deployment operations

Compliance alignment: NIST AI RMF (GOVERN 1.2 — accountability mechanisms), ISO 42001 (A.8.4 — AI system integrity), EU AI Act Article 15 (accuracy, robustness, cybersecurity).

How FREEZE Rules Work

FREEZE rules are evaluated before the normal policy pipeline. They operate as a pre-evaluation gate that cannot be bypassed:

Request → FREEZE Rule Check → NHI Verification → Policy Evaluation → Decision
          (immutable gate)    (identity)          (configurable)

If a FREEZE rule matches, the decision is DENY immediately. No further evaluation occurs. The FREEZE rule’s reason code and evidence are attached to the decision.

Defining FREEZE Rules

import { TealEngine, FreezeRule } from 'tealtiger';

const engine = new TealEngine({
  freeze: [
    {
      id: 'FREEZE-001',
      description: 'Never allow deletion of production databases',
      condition: {
        action: 'database.drop',
        environment: 'production'
      },
      reason: 'FREEZE_PRODUCTION_DB_DELETE',
      severity: 'critical'
    },
    {
      id: 'FREEZE-002',
      description: 'Never allow disabling audit logging',
      condition: {
        action: 'audit.disable'
      },
      reason: 'FREEZE_AUDIT_DISABLE',
      severity: 'critical'
    },
    {
      id: 'FREEZE-003',
      description: 'Never allow PII exfiltration to external endpoints',
      condition: {
        action: 'data.export',
        classification: 'pii',
        destination: { not: { pattern: '*.internal.acme.com' } }
      },
      reason: 'FREEZE_PII_EXFILTRATION',
      severity: 'critical'
    }
  ],
  policy: { /* normal policy config */ }
});

FREEZE Rule Structure

interface FreezeRule {
  /** Unique identifier — immutable after creation */
  id: string;

  /** Human-readable description of what this rule prevents */
  description: string;

  /** Condition that triggers the FREEZE rule */
  condition: FreezeCondition;

  /** Reason code attached to DENY decisions */
  reason: string;

  /** Severity level for alerting */
  severity: 'critical' | 'high';

  /** Optional: compliance framework reference */
  compliance?: string[];
}

Immutability Guarantees

FREEZE rules provide three immutability guarantees:

1. Persist Across Hot-Swaps

When a policy bundle is hot-swapped (replaced at runtime), FREEZE rules from the original configuration are preserved. The new bundle cannot remove or weaken them.

// Initial configuration with FREEZE rules
const engine = new TealEngine({
  freeze: [
    { id: 'FREEZE-001', condition: { action: 'database.drop' }, /* ... */ }
  ],
  policy: originalPolicy
});

// Hot-swap policy bundle — FREEZE rules are preserved
await engine.hotSwapPolicy(newPolicyBundle);
// FREEZE-001 still active, regardless of what newPolicyBundle contains

2. Cannot Be Modified or Disabled

Any programmatic attempt to modify a FREEZE rule is rejected and logged:

// This throws FreezeViolationError and logs FREEZE_TAMPER_ATTEMPT
try {
  engine.modifyFreezeRule('FREEZE-001', { condition: { action: 'database.drop', environment: 'staging' } });
} catch (error) {
  // error.code === 'FREEZE_TAMPER_ATTEMPT'
  // error.ruleId === 'FREEZE-001'
  // Audit event already emitted — cannot be suppressed
}

3. Tamper Detection

Any modification attempt — whether through the API, configuration reload, or bundle replacement — triggers a FREEZE_TAMPER_ATTEMPT event:

// Tamper attempt event structure
{
  event_type: 'freeze.tamper_attempt',
  severity: 'critical',
  rule_id: 'FREEZE-001',
  attempted_action: 'modify',  // 'modify' | 'delete' | 'disable'
  attempted_by: '[email protected]',
  timestamp: '2026-06-01T14:30:00Z',
  correlation_id: 'req-abc-123',
  // This event cannot be filtered, suppressed, or redirected
}

FREEZE_TAMPER_ATTEMPT events are emitted through a separate, hardcoded evidence channel that cannot be reconfigured. Even if the primary audit sink is compromised, tamper attempts are still recorded.

Use Cases

Critical Safety Controls

const safetyFreezeRules: FreezeRule[] = [
  {
    id: 'FREEZE-SAFETY-001',
    description: 'Prevent agents from modifying their own governance configuration',
    condition: { action: 'governance.config.modify', actor_type: 'agent' },
    reason: 'FREEZE_SELF_GOVERNANCE_MODIFICATION',
    severity: 'critical',
    compliance: ['NIST-AI-RMF-GOVERN-1.2', 'OWASP-ASI-09']
  },
  {
    id: 'FREEZE-SAFETY-002',
    description: 'Prevent any identity from disabling FREEZE rules',
    condition: { action: 'freeze.disable' },
    reason: 'FREEZE_META_TAMPER',
    severity: 'critical',
    compliance: ['ISO-42001-A.8.4']
  },
  {
    id: 'FREEZE-SAFETY-003',
    description: 'Prevent execution of shell commands in production by any agent',
    condition: { action: 'shell.execute', environment: 'production' },
    reason: 'FREEZE_SHELL_EXECUTION',
    severity: 'critical',
    compliance: ['OWASP-ASI-03']
  }
];

Regulatory Compliance Controls

const complianceFreezeRules: FreezeRule[] = [
  {
    id: 'FREEZE-HIPAA-001',
    description: 'Never transmit PHI to non-BAA endpoints',
    condition: {
      data_classification: 'phi',
      destination: { not: { in: '$BAA_ENDPOINTS' } }
    },
    reason: 'FREEZE_PHI_UNAUTHORIZED_TRANSMISSION',
    severity: 'critical',
    compliance: ['HIPAA-164.502', 'HIPAA-164.504']
  },
  {
    id: 'FREEZE-GDPR-001',
    description: 'Never transfer EU personal data outside approved jurisdictions',
    condition: {
      data_classification: 'personal_data',
      data_subject_region: 'EU',
      destination_region: { not: { in: '$GDPR_ADEQUATE_COUNTRIES' } }
    },
    reason: 'FREEZE_GDPR_TRANSFER_VIOLATION',
    severity: 'critical',
    compliance: ['GDPR-Article-44', 'GDPR-Article-46']
  }
];

FREEZE vs. Normal Policy Rules

Aspect	FREEZE Rules	Normal Policy Rules
Mutability	Immutable — cannot be changed at runtime	Mutable — can be hot-swapped
Override	Cannot be overridden by any mechanism	Can be overridden by higher-priority rules
Evaluation order	First — before all other checks	After FREEZE and NHI checks
Tamper detection	Yes — logs `FREEZE_TAMPER_ATTEMPT`	No — modifications are normal operations
Failure mode	Always DENY — no fail-open option	Configurable (fail-closed or fail-open)
Use case	Safety-critical, regulatory, non-negotiable	Business logic, operational policies
Audit channel	Hardcoded, non-configurable	Configurable audit sinks

Configuration

# tealtiger.config.yaml
freeze:
  rules:
    - id: FREEZE-001
      description: "Prevent production database deletion"
      condition:
        action: database.drop
        environment: production
      reason: FREEZE_PRODUCTION_DB_DELETE
      severity: critical
      compliance:
        - SOC2-CC6.1
        - ISO-42001-A.8.4

    - id: FREEZE-002
      description: "Prevent audit log tampering"
      condition:
        action: audit.*
        operation: [delete, modify, disable]
      reason: FREEZE_AUDIT_TAMPER
      severity: critical

  # Tamper detection settings
  tamperDetection:
    alertChannel: 'security-critical'  # Cannot be changed at runtime
    requireAcknowledgment: true
    escalationTimeout: '5m'

Best Practices

Start Small

Begin with 3-5 FREEZE rules covering your most critical safety invariants. You can always add more, but you cannot remove them.

Document Justification

Every FREEZE rule should reference a specific risk scenario or compliance requirement. Future teams need to understand why each rule exists.

Test Before Deploying

Use the Policy Test Harness to validate FREEZE rules against your expected traffic patterns before deployment. False positives in FREEZE rules cannot be quickly resolved.

Separate from Business Logic

FREEZE rules are for safety invariants, not business logic. If a rule might need to change based on business requirements, it belongs in normal policy.

TealEngine v1.3 API — Pre-evaluation pipeline with FREEZE gates
Anti-Tamper Controls — Bundle integrity and forbidden config keys
Automation Levels — How FREEZE interacts with auto_deny
NHI Governance — Identity verification before FREEZE evaluation
SOC/IR Pipeline — How FREEZE_TAMPER_ATTEMPT events flow to SIEM

Getting Started

Core Concepts

Governance Domains

Policy Authoring

Architecture

Integrations

Deployment

API Reference

Cookbook

Compliance & GRC

Guides

Reference

Versions

Playground

Dashboard

Blog

FREEZE Rules & Immutable Controls

Why This Matters

How FREEZE Rules Work

Defining FREEZE Rules

FREEZE Rule Structure

Immutability Guarantees

1. Persist Across Hot-Swaps

2. Cannot Be Modified or Disabled

3. Tamper Detection

Use Cases

Critical Safety Controls

Regulatory Compliance Controls

FREEZE vs. Normal Policy Rules

Configuration

Best Practices

Start Small

Document Justification

Test Before Deploying

Separate from Business Logic

​Why This Matters

​How FREEZE Rules Work

​Defining FREEZE Rules

​FREEZE Rule Structure

​Immutability Guarantees

​1. Persist Across Hot-Swaps

​2. Cannot Be Modified or Disabled

​3. Tamper Detection

​Use Cases

​Critical Safety Controls

​Regulatory Compliance Controls

​FREEZE vs. Normal Policy Rules

​Configuration

​Best Practices

Start Small

Document Justification

Test Before Deploying

Separate from Business Logic

​Related Documentation

Why This Matters

How FREEZE Rules Work

Defining FREEZE Rules

FREEZE Rule Structure

Immutability Guarantees

1. Persist Across Hot-Swaps

2. Cannot Be Modified or Disabled

3. Tamper Detection

Use Cases

Critical Safety Controls

Regulatory Compliance Controls

FREEZE vs. Normal Policy Rules

Configuration

Best Practices

Related Documentation