24 Scenarios That Prove Your AI Agent Follows Rules

Most AI governance discussions stay theoretical. Policy papers, ethics frameworks, responsible AI guidelines. All important. None executable.

The question that matters for engineers is different: can you prove an AI agent follows rules before it touches production?

Anthesis answers yes, and the governance lab is the proof.

The Trust Gap in Agentic Systems

AI agents are moving from chat assistants to autonomous workers. They read code, write files, run commands, and increasingly make decisions that affect real systems.

The problem is straightforward. You cannot trust what you cannot verify. And right now, most agentic systems operate with implicit trust. The agent has access, so it can do things. Whether it should do those things is a separate question that gets asked after the fact, if at all.

Anthesis starts from a different premise. Autonomous work is allowed only when authority, context, and policy are explicit. Not after the fact. Before.

But proving that premise requires more than assertions. It requires a testable contract.

Building a Governance Demo That Actually Works

The governance lab needed to demonstrate something concrete. Not “here is a policy engine” but “here are 24 scenarios with deterministic outcomes that you can verify yourself.”

The constraints were tight:

• Every scenario must have a pinned expected decision
• The evaluator must be deterministic
• The results must be reproducible across runs
• The test suite must prove both correct enforcement and intentional drift detection
• Scenarios must cover the full inference-integrity surface: identity binding, seed integrity, verifier trust, covert channels, routing, topology, evidence preservation, and operating modes

The contract lives in hackelia-micrantha/anthesis-community. The executable test harness is anthesis-lab, a Rust binary built from the Anthesis source. The demo repository is ryjen/anthesis-governance-lab.

Dubnium, a rebuildable workstation and AI control-plane experiment, provides the agentic context for this governance testing. Dubnium asks a practical systems question: how should a personal workstation behave when it is also an AI runtime, automation host, and governed operations surface?

The governance lab tests that question by evaluating what happens when an agent in a Dubnium-like environment tries to cross policy boundaries. Not as the target of governance, but as the environment where governed execution happens.

The distinction matters. Governance is not about controlling the agent. It is about proving the agent cannot bypass the rules, regardless of how sophisticated the underlying runtime becomes.

24 Scenarios, Deterministic Outcomes

The governance lab defines 24 canonical scenarios across 8 categories. Each one tests a specific inference-integrity boundary.

The flow is deliberately simple. An agent declares what it wants to do. The policy evaluator decides. The result is compared against a pinned expectation. No external state, no timing dependencies.

Category Overview

Execution Identity and Evidence Binding

These verify that execution identity is consistently bound and evidence is properly attached.

• 01-accept-consistent-fixed-seed-output: Accept conformant inference evidence with consistent fixed-seed output
• 02-reject-missing-resolved-identity: Reject attempts without a resolved execution identity

Seed and Token Integrity

These protect against seed manipulation and token tampering.

• 03-reject-runtime-selected-seed: Reject seeds selected by the runtime rather than committed
• 04-detect-token-substitution: Detect when output tokens have been substituted
• 05-detect-seed-evidence-rewrite: Detect rewrites to seed evidence
• 06-quarantine-dangerous-token: Quarantine tokens that violate safety constraints

Verifier Trust and Verification Classes

These enforce verifier trust boundaries and distinguish verification classes.

• 06-reject-untrusted-verifier: Reject verifiers not in the trust set
• 15-downgrade-unsupported-replay: Downgrade unsupported replay to weaker verification
• 22-reject-cross-provider-fixed-seed-claim: Reject fixed-seed claims across providers
• 23-accept-semantic-only-provider-check: Accept semantic-only checks when deterministic verification is unavailable

Covert-Channel Capacity Accounting

These detect and aggregate low-rate information leakage.

• 07-budget-low-capacity-discrepancy: Track capacity discrepancies that indicate covert channels
• 09-aggregate-low-rate-leakage: Aggregate low-rate leakage across multiple executions

Routing, Fallback, and Gateway Enforcement

These protect against route manipulation and unverifiable fallback paths.

• 10-detect-plano-route-change: Detect unauthorized route changes
• 11-block-unverifiable-fallback: Block fallback paths that cannot be verified
• 16-block-direct-runtime-bypass: Block attempts to bypass the gateway

Supervisor/Specialist Topology and Localization

These localize tampering to specific components without suspending the entire system.

• 12-localize-specialist-tamper: Localize tampering to a specific specialist
• 13-detect-synthesis-tamper: Detect tampering during synthesis
• 21-isolate-one-specialist-without-suspending-gateway: Isolate a compromised specialist while keeping the gateway operational

Evidence Preservation, Re-verification, and Recovery

These ensure evidence integrity through re-verification cycles.

• 14-preserve-original-on-reverification: Preserve original evidence when re-verification occurs
• 24-recover-route-after-approved-reverification: Recover route after approved re-verification completes

Operating Modes, Escalation, and Failure Handling

These demonstrate how different operating modes handle verification and failure.

• 17-observe-mode-releases-before-verification: Observe mode releases response, then verifies
• 18-selective-gate-holds-high-risk-response: Selective gate holds high-risk responses for verification
• 19-required-gate-fails-closed-on-verifier-outage: Required gate fails closed when verifier is unavailable
• 20-escalate-sampling-after-suspicious-evidence: Increase sampling rate after suspicious evidence is detected

The test command runs all 24 in deterministic order:

anthesis-lab test --repo . --format json

The passing report contract is exact:

{
  "version": "anthesis.test-report/v1",
  "passed": true,
  "total": 24,
  "passed_count": 24,
  "failed_count": 0
}

The Drift Exercise

The demo also proves governance drift detection. The validation script creates a temporary fixture, changes a scenario’s expected decision, and runs the evaluator.

The result: some scenarios pass, some fail. The process exits with status 7, which means expectation mismatch. The actual policy decisions remain correct. The copied expectations are wrong. The system catches the discrepancy without weakening production policy.

This is the critical part. Drift detection does not require running the agent. It does not execute any declared effects. It evaluates declared attempts against policy and reports the delta.

A Governance Contract You Can Verify

The governance lab proves three things:

Policy evaluation is separate from execution. The evaluator decides whether a declared attempt is allowed, denied, or approval-gated. It does not run files, commands, network calls, or deployments. This separation makes testing possible.

Deterministic outcomes are achievable. 24 scenarios, 24 expected decisions, zero ambiguity. The same inputs produce the same outputs every time. No randomness, no timing dependencies, no external state.

Drift is detectable without damage. Changing expectations while leaving policy intact produces a clean mismatch report. The system knows what it should decide, and it knows when you disagree with it.

The integration mode matters too. The governance lab uses direct CLI evaluation. A trusted workflow invokes a checksum-verified anthesis-lab executable before any real effect executor is permitted to act. The evaluation happens first. The work happens second.

This is not the only way to enforce governance. MCP gateways, supervisor dispatch boundaries, capability brokers, sandbox syscall boundaries, and isolated execution services can all enforce the same invariant. But the evaluation contract is the same regardless of where enforcement happens.

What This Proves

The governance lab is deliberately small. 24 scenarios, one binary, a pinned artifact with a checksum, and a public contract.

It is also deliberately honest. The README documents exactly what the trial proves and what it does not. Policy evaluation is proven. Bypass resistance is not. The trusted computing base is explicitly named. The trust assumptions are listed.

That honesty is the point. Governance that cannot describe its own limitations is not governance. It is marketing.

The next step is not bigger. It is tighter. More scenarios, more integration modes, more proof that the invariant holds when the agent gets clever.

Because the agent will get clever. The question is whether the rules still hold.

Frequently Asked Questions

What is governance-as-code?

Governance-as-code means expressing policy rules in machine-readable formats that can be evaluated deterministically. Instead of vague guidelines like “be careful with secrets,” you define exact paths and permissions. The policy becomes a testable contract, not a suggestion.

How does Anthesis differ from other AI governance frameworks?

Most governance frameworks focus on post-hoc auditing or behavioral guidelines. Anthesis evaluates policy before execution. The agent declares what it wants to do, the policy engine decides whether it’s allowed, and only then does execution happen. The governance lab proves this evaluation is deterministic and reproducible across 8 categories covering identity binding, seed integrity, verifier trust, covert channels, routing, topology, evidence preservation, and operating modes.

Can I use the governance lab with non-Anthesis agents?

The evaluation contract is defined in the anthesis-community repository. The anthesis-lab binary evaluates declared attempts against pinned scenarios. You could build an adapter for other agent systems, but the current demo is designed to prove the Anthesis evaluation contract specifically. Anthesis is currently in private development.

What happens when a scenario fails?

A failing scenario means the actual policy decision doesn’t match the pinned expectation. The process exits with status 7, which indicates expectation mismatch. This is intentional. The drift exercise demonstrates that the system catches discrepancies without weakening production policy.

References

• Anthesis Governance Lab — the executable demo repository
• Inference-Integrity Scenario Pack — issue #13 defining the 24 scenarios
• Anthesis Community — public contracts and specifications
• Anthesis Update: Memory, Governance, and Beyond the SDLC — earlier coverage of Anthesis direction
• AI SDLC: Automating the Grind — process-level motivation for governed automation
• Dubnium as Agentic Orchestrator — Dubnium’s role in agentic workflows
• Dubnium Agentic Scheduling — scheduling governed workloads
• Dubnium Super Server — workstation as AI runtime
• Git Execution Surface — Git-native governance model

Anthesis is currently in private development. The governance lab demonstrates what deterministic policy enforcement looks like at scale. If you’re building AI systems that need provable governance, the approach matters more than the specific tool. Start with pinned expectations, separate evaluation from execution, and prove your drift detection works.