Automation Levels

TealTiger v1.3 introduces automation levels — a graduated control system that determines how governance decisions are handled. Each policy rule specifies an automation level that dictates whether the decision is applied automatically or requires human intervention.

Automation levels address the fundamental tension in AI governance: too much automation risks unsafe actions; too much human oversight creates bottlenecks. TealTiger lets you calibrate per-rule based on risk tolerance.

Why This Matters

Risk	Without Automation Levels	With Automation Levels
Over-blocking	Binary allow/deny blocks legitimate workflows	`auto_sanitize` cleans content without blocking
Alert fatigue	Every decision requires human review	Only high-risk decisions escalate to humans
Unsafe automation	All decisions applied without oversight	`approval_required` gates critical actions on human judgment
Compliance gaps	No evidence of human oversight for high-risk AI	Approval tokens provide non-repudiation evidence

Compliance alignment: EU AI Act Article 14 (human oversight), NIST AI RMF (GOVERN 3 — human-AI interaction), ISO 42001 (A.9.3 — management review).

The Four Levels

auto_allow

Lowest friction. Request proceeds without modification. Used for low-risk actions that match policy.

auto_deny

Automatic block. Request is denied without human intervention. Used for clearly prohibited actions.

auto_sanitize

Automatic remediation. Request is modified to comply with policy, then allowed. Used for fixable violations.

approval_required

Human-in-the-loop. Request is held pending explicit human approval. Used for high-risk or ambiguous decisions.

Level Details

auto_allow

The request passes governance evaluation and proceeds without modification. This is the outcome when no policy violations are detected.

// Policy rule with auto_allow
{
  condition: { action: 'knowledge_base.search' },
  automation: 'auto_allow',
  reason: 'POLICY_COMPLIANT'
}

When to use: Low-risk, well-understood actions that are clearly within the agent’s mandate. Read-only operations, approved tool calls, routine queries. Decision output:

{
  action: 'ALLOW',
  automation_level: 'auto_allow',
  reason_codes: ['POLICY_COMPLIANT'],
  pending: false
}

auto_deny

The request is automatically blocked. No human review is needed because the violation is unambiguous.

// Policy rule with auto_deny
{
  condition: { action: 'database.drop', environment: 'production' },
  automation: 'auto_deny',
  reason: 'PRODUCTION_DESTRUCTIVE_ACTION'
}

When to use: Clearly prohibited actions where there is no legitimate use case. Destructive operations in production, known-malicious patterns, policy violations with no remediation path. Decision output:

{
  action: 'DENY',
  automation_level: 'auto_deny',
  reason_codes: ['PRODUCTION_DESTRUCTIVE_ACTION'],
  pending: false
}

For actions that should never be allowed regardless of policy changes, use FREEZE rules instead of auto_deny. FREEZE rules are immutable; auto_deny rules can be modified through policy updates.

auto_sanitize

The request contains a policy violation that can be automatically remediated without blocking the request entirely. TealTiger modifies the request to comply with policy, then allows it to proceed.

// Policy rule with auto_sanitize
{
  condition: { content_contains: 'pii' },
  automation: 'auto_sanitize',
  sanitization: {
    method: 'redact',
    patterns: ['email', 'phone', 'ssn'],
    replacement: '[REDACTED]'
  },
  reason: 'PII_AUTO_REDACTED'
}

When to use: Violations where the fix is deterministic and well-defined. PII redaction, secret masking, content truncation, model downgrade. Decision output:

{
  action: 'SANITIZE',
  automation_level: 'auto_sanitize',
  reason_codes: ['PII_AUTO_REDACTED'],
  pending: false,
  sanitization: {
    applied: true,
    method: 'redact',
    fields_modified: ['content'],
    original_hash: 'sha256:abc...',  // For audit trail
    sanitized_hash: 'sha256:def...'
  }
}

Sanitization methods:

Method	Behavior	Example
`redact`	Replace sensitive content with placeholder	`[email protected]` → `[REDACTED]`
`mask`	Partially obscure content	`4111-1111-1111-1111` → `**--**-1111`
`truncate`	Remove content beyond a boundary	Trim context to 4096 tokens
`downgrade`	Replace with lower-risk alternative	`gpt-4` → `gpt-3.5-turbo`
`strip`	Remove specific fields entirely	Remove `tool_params.credentials`

approval_required

The request is held in a PENDING state until a human approver explicitly approves or rejects it. This is the highest-friction level, reserved for high-risk decisions where automated judgment is insufficient.

// Policy rule with approval_required
{
  condition: { action: 'payment.refund', amount_usd: { gt: 500 } },
  automation: 'approval_required',
  approval: {
    approvers: ['[email protected]', '[email protected]'],
    timeout: '30m',
    timeoutAction: 'DENY',  // What happens if no one approves in time
    requireJustification: true
  },
  reason: 'HIGH_VALUE_REFUND_REQUIRES_APPROVAL'
}

When to use: High-risk actions, high-value transactions, actions with irreversible consequences, regulatory requirements for human oversight. Decision output (pending):

{
  action: 'PENDING',
  automation_level: 'approval_required',
  reason_codes: ['HIGH_VALUE_REFUND_REQUIRES_APPROVAL'],
  pending: true,
  approval: {
    token: 'approval-token-xyz789',
    approvers: ['[email protected]'],
    expiresAt: '2026-06-01T15:00:00Z',
    status: 'AWAITING_APPROVAL'
  }
}

Approval Workflow

When a decision returns PENDING, the calling application must handle the approval flow:

// 1. Initial evaluation returns PENDING
const decision = await engine.evaluate(request, ctx);

if (decision.pending) {
  // 2. Notify approvers (via your notification system)
  await notifyApprovers(decision.approval.approvers, {
    token: decision.approval.token,
    request: request,
    reason: decision.reason_codes,
    expiresAt: decision.approval.expiresAt
  });

  // 3. Wait for approval (webhook, polling, or event-driven)
  const approvalResult = await waitForApproval(decision.approval.token);

  if (approvalResult.approved) {
    // 4. Resume with approval token
    const finalDecision = await engine.approveDecision(
      decision.approval.token,
      {
        approvedBy: approvalResult.approver,
        justification: approvalResult.justification
      }
    );
    // finalDecision.action === 'ALLOW'
    // finalDecision.approval.status === 'APPROVED'
  }
}

Approval Token

The approval token is a cryptographic proof that:

A specific request was reviewed by a specific human
The approval was granted within the validity window
The approval cannot be replayed for a different request

interface ApprovalToken {
  /** Unique token identifier */
  id: string;

  /** The original request hash — prevents token reuse */
  requestHash: string;

  /** Who can approve */
  approvers: string[];

  /** When the token expires */
  expiresAt: string;

  /** Current status */
  status: 'AWAITING_APPROVAL' | 'APPROVED' | 'REJECTED' | 'EXPIRED';

  /** Approval evidence (populated after approval) */
  evidence?: {
    approvedBy: string;
    approvedAt: string;
    justification: string;
    signature: string;  // Non-repudiation
  };
}

Mapping to Policy Rules

Each policy rule specifies its automation level. Rules can use different levels for different conditions:

# tealtiger-policy.yaml
rules:
  - name: "File operations"
    conditions:
      - action: file.read
        automation: auto_allow

      - action: file.write
        path: { not: { pattern: '/etc/**' } }
        automation: auto_allow

      - action: file.write
        path: { pattern: '/etc/**' }
        automation: approval_required
        approval:
          approvers: ['[email protected]']
          timeout: '10m'

      - action: file.delete
        environment: production
        automation: auto_deny

  - name: "Content governance"
    conditions:
      - content_contains: pii
        automation: auto_sanitize
        sanitization:
          method: redact

PLAN_ONLY Mode

TealEngine v1.3 supports a PLAN_ONLY evaluation mode that returns what the automation level would be without executing it. This is useful for:

UI previews showing what will happen before the agent acts
Dry-run validation of policy changes
Agent planning loops that need to know constraints before acting

const plan = await engine.evaluate(request, {
  ...ctx,
  mode: 'PLAN_ONLY'
});

// plan.action === 'PENDING' (what would happen)
// plan.automation_level === 'approval_required'
// plan.executed === false  // Nothing was actually enforced

Timeout Behavior

When approval_required decisions are not resolved within the configured timeout:

`timeoutAction`	Behavior
`DENY` (default)	Request is denied after timeout — fail-closed
`ALLOW`	Request is allowed after timeout — use with caution
`ESCALATE`	Escalate to a secondary approver group

{
  automation: 'approval_required',
  approval: {
    approvers: ['[email protected]'],
    timeout: '15m',
    timeoutAction: 'ESCALATE',
    escalation: {
      approvers: ['[email protected]'],
      timeout: '30m',
      timeoutAction: 'DENY'  // Final fallback
    }
  }
}

Choosing the Right Level

When to use auto_allow

Read-only operations within the agent’s scope
Actions explicitly permitted by policy
Low-risk, high-frequency operations where latency matters
Operations that have been validated through MONITOR mode

When to use auto_deny

Actions that violate clear safety boundaries
Known-malicious patterns (prompt injection, exfiltration attempts)
Operations outside the agent’s registered scope
Actions prohibited by regulation with no exception process

When to use auto_sanitize

PII detected in outbound content (redact and proceed)
Secrets in prompts (mask and proceed)
Context exceeding size limits (truncate and proceed)
Model requests for disallowed models (downgrade and proceed)

When to use approval_required

High-value financial transactions
Irreversible destructive operations
Actions requiring regulatory human oversight (EU AI Act)
First-time actions by newly registered agents
Operations flagged by drift detection as anomalous

TealEngine v1.3 API — evaluate() and approveDecision() methods
FREEZE Rules — Immutable controls (stronger than auto_deny)
NHI Governance — JIT grants use approval_required internally
Code Change Governance — Two-person rule uses approval_required
TealFlow — Workflow automation with approval gates

Getting Started

Core Concepts

Governance Domains

Policy Authoring

Architecture

Integrations

Deployment

API Reference

Cookbook

Compliance & GRC

Guides

Reference

Versions

Playground

Dashboard

Blog

Why This Matters

The Four Levels

auto_allow

auto_deny

auto_sanitize

approval_required

Level Details

auto_allow

auto_deny

auto_sanitize

approval_required

Approval Workflow

Approval Token

Mapping to Policy Rules

PLAN_ONLY Mode

Timeout Behavior

Choosing the Right Level

​Why This Matters

​The Four Levels

auto_allow

auto_deny

auto_sanitize

approval_required

​Level Details

​auto_allow

​auto_deny

​auto_sanitize

​approval_required

​Approval Workflow

​Approval Token

​Mapping to Policy Rules

​PLAN_ONLY Mode

​Timeout Behavior

​Choosing the Right Level

​Related Documentation

Why This Matters

The Four Levels

Level Details

auto_allow

auto_deny

auto_sanitize

approval_required

Approval Workflow

Approval Token

Mapping to Policy Rules

PLAN_ONLY Mode

Timeout Behavior

Choosing the Right Level

Related Documentation