Anti-Patterns

These aren’t bugs in TealTiger — they’re misaligned usage patterns that break determinism, weaken governance, or create compliance gaps.

1. Developers Defining Their Own Governance

Anti-pattern: Application code sets enforcement rules, cost limits, or safety controls.

// ❌ Developer sets their own limits — no separation of duties
const engine = new TealEngine({
  policy: { rules: [{ condition: { action: '*' }, automation: 'auto_allow' }] },
  cost: { per_request_max: 999.00 },  // Developer sets permissive limit
});

Why it’s bad: No separation of duties. Developers can weaken controls. No audit trail of who authorized the policy. Fails SOC 2 / ISO 42001 requirements. Do this instead: Governance team signs policy bundles. Developers load them without modification. See Governance at Scale.

2. Permanent MONITOR Mode

Anti-pattern: Deploying in MONITOR mode and never graduating to ENFORCE.

// ❌ "We'll switch to ENFORCE later" — later never comes
const engine = new TealEngine({ mode: 'MONITOR' });

Why it’s bad: Governance is never actually enforced. Violations are logged but agents proceed unchecked. You have audit evidence of violations you chose not to prevent. Do this instead: Use MONITOR for 1-2 weeks during rollout, then switch to ENFORCE. Set a calendar reminder.

3. Ignoring PENDING Decisions

Anti-pattern: Not implementing the approval workflow for approval_required actions.

// ❌ Treats PENDING as ALLOW — bypasses human oversight
const decision = await engine.evaluate(request, ctx);
if (decision.action !== 'DENY') {
  await execute(request);  // PENDING falls through as "allowed"
}

Why it’s bad: Approval gates exist for high-risk actions. Ignoring them means no human oversight for sensitive operations. Do this instead: Handle PENDING explicitly — hold execution until approveDecision() or rejectDecision() is called.

4. Using fail_open for Security Workloads

Anti-pattern: Setting fail_behavior: 'fail_open' when governance failures should block.

// ❌ Module crash → ungoverned request passes through
const engine = new TealEngine({ fail_behavior: 'fail_open' });

Why it’s bad: If a governance module crashes, requests pass through without evaluation. An attacker could intentionally trigger module failures to bypass governance. Do this instead: Use fail_closed (the default). Only use fail_open for non-security workloads where availability is more important than governance.

5. Skipping NHI Registration

Anti-pattern: Running agents without registered identities.

// ❌ No agent identity — no accountability, no scope enforcement
const decision = await engine.evaluate(
  { action: 'database.query' },
  { correlation_id: uuid() }  // No agentId
);

Why it’s bad: Without NHI, there’s no scope enforcement, no lifecycle management, no attestation. Any process can impersonate any agent. No accountability in audit trails. Do this instead: Register every agent with explicit scopes, environment constraints, and attestation. See NHI Governance.

6. Hardcoding Policies in Application Code

Anti-pattern: Defining governance rules inline in application source code.

// ❌ Policies mixed with application logic — no governance team control
if (action === 'file.delete' && env === 'production') {
  throw new Error('Not allowed');
}

Why it’s bad: No versioning, no signing, no separation of duties. Developers can change governance rules in any PR. No audit trail of policy changes. Do this instead: Use signed policy bundles loaded at runtime. Policy changes go through the governance team’s review process.

7. Evaluating After Execution

Anti-pattern: Calling evaluate() after the action has already been performed.

// ❌ Action already executed — governance is just logging, not preventing
await executeAction(request);
const decision = await engine.evaluate(request, ctx);  // Too late

Why it’s bad: You can’t un-delete a database, un-send an email, or un-leak a secret. Post-execution governance is audit, not enforcement. Do this instead: Always evaluate BEFORE execution. The decision determines whether execution proceeds.

8. Disabling Audit in Production

Anti-pattern: Turning off audit logging to reduce noise or save storage.

// ❌ No evidence trail — compliance failure
const engine = new TealEngine({ audit: { enabled: false } });

Why it’s bad: No evidence for compliance reviews. No forensics capability during incidents. No proof that governance was enforced. Fails every audit framework. Do this instead: Always keep audit enabled. Use redaction modes to minimize sensitive data. Forward to SIEM for correlation.

9. Using LLMs to Make Governance Decisions

Anti-pattern: Calling an LLM to decide whether an action should be allowed.

// ❌ Non-deterministic governance — different answer every time
const shouldAllow = await llm.chat('Should this action be allowed? ' + JSON.stringify(request));

Why it’s bad: LLM outputs are non-deterministic. Same input can produce different decisions. Not auditable, not reproducible, not testable. Adds latency and cost to the governance path. Do this instead: TealTiger’s governance is deterministic by design. Same input + same policy = same decision. Use TealClassifier for ML-assisted detection, but the final decision is always rule-based.

10. Attempting to Bypass FREEZE Rules

Anti-pattern: Trying to disable or work around FREEZE rules programmatically.

// ❌ All of these fail with FREEZE_TAMPER_ATTEMPT logged
engine.removeFreezeRule('FREEZE-001');
engine.configure({ freeze: { disable: true } });
engine.loadPolicy({ freeze_rules: [] });  // Cannot remove via hot-swap

Why it’s bad: FREEZE rules exist because the governance team determined these actions must NEVER happen. Attempting to bypass them is a security event that gets logged and alerted. Do this instead: If a FREEZE rule is blocking legitimate work, escalate to the governance team. They can modify the rule through the proper signing process.

Summary

Anti-Pattern	Risk	Correct Approach
Developers define governance	No separation of duties	Signed bundles from governance team
Permanent MONITOR mode	Governance never enforced	Graduate to ENFORCE after validation
Ignoring PENDING	No human oversight	Implement approval workflow
fail_open for security	Bypass via module crash	Use fail_closed (default)
No NHI registration	No agent accountability	Register every agent identity
Hardcoded policies	No versioning or signing	Signed policy bundles
Post-execution evaluation	Can’t prevent damage	Evaluate BEFORE execution
Disabled audit	No compliance evidence	Always keep audit enabled
LLM-based decisions	Non-deterministic	Deterministic rule evaluation
Bypassing FREEZE	Security event	Escalate to governance team

Best Practices

What to do instead

Governance at Scale

Enterprise operating model

Getting Started

Core Concepts

Governance Domains

Policy Authoring

Architecture

Integrations

Deployment

API Reference

Cookbook

Compliance & GRC

Guides

Reference

Versions

Playground

Dashboard

Blog

1. Developers Defining Their Own Governance

2. Permanent MONITOR Mode

3. Ignoring PENDING Decisions

4. Using fail_open for Security Workloads

5. Skipping NHI Registration

6. Hardcoding Policies in Application Code

7. Evaluating After Execution

8. Disabling Audit in Production

9. Using LLMs to Make Governance Decisions

10. Attempting to Bypass FREEZE Rules

Summary

Best Practices

Governance at Scale

​1. Developers Defining Their Own Governance

​2. Permanent MONITOR Mode

​3. Ignoring PENDING Decisions

​4. Using fail_open for Security Workloads

​5. Skipping NHI Registration

​6. Hardcoding Policies in Application Code

​7. Evaluating After Execution

​8. Disabling Audit in Production

​9. Using LLMs to Make Governance Decisions

​10. Attempting to Bypass FREEZE Rules

​Summary

​Related Documentation

Best Practices

Governance at Scale

1. Developers Defining Their Own Governance

2. Permanent MONITOR Mode

3. Ignoring PENDING Decisions

4. Using fail_open for Security Workloads

5. Skipping NHI Registration

6. Hardcoding Policies in Application Code

7. Evaluating After Execution

8. Disabling Audit in Production

9. Using LLMs to Make Governance Decisions

10. Attempting to Bypass FREEZE Rules

Summary

Related Documentation