March 16, 2026 mirrorosai-governanceopen-source

Before the Agent Acts: The Governance Gap in Enterprise AI

By Kevin Ryan Khan & Brandon Lee Zeek — Co-founders, Strikaris LLC

First published on the AWS Builder Center on March 16, 2026: https://builder.aws.com/post/3B2Othx0PuB3yI8DMKyE9FBl2Wa_p/before-the-agent-acts-the-governance-gap-in-enterprise-ai

Kevin brings 10+ years of NetSuite experience at Benchmark Education, where he progressed to Solutions Architect, specializing in SuiteScript, SDF/SuiteCloud, and large-scale ERP integrations. Brandon, who passed away in May 2026, was a full-stack engineer and Strikaris co-founder; he served as Tech Lead at LOJI and previously as a Technical Lead at Benchmark Education. Together they founded Strikaris to deliver governance-first AI automation for enterprise environments.

The Problem Nobody Is Talking About Yet

Picture this: you’ve just deployed an AI agent to help manage your company’s accounts payable queue. It’s fast, it’s accurate, and it’s saving your team hours every week. Then one day it approves a $15,000 payment to a vendor your compliance team never cleared. Nobody told the agent it wasn’t allowed to do that. Nobody built in a rule. The agent didn’t hallucinate — it just acted, because nothing stopped it.

This isn’t a hypothetical. It’s the direction enterprise AI is heading right now, and the governance infrastructure to handle it doesn’t exist yet.

That’s the problem Strikaris set out to solve when we built MirrorOS.

See It in Action First

Before we explain how it works, here’s what it looks like.

LedgerLark is an accounts payable orchestration agent governed by MirrorOS. It processes an expense queue, routing each expense through two policy checks before any action is taken: a routing check (which agent handles this?) and an approval check (is that agent authorized for this amount?).

Expense	Vendor	Result	Route
$450	Office Supplies Co	PERMITTED	→ clerk
$8,500	Cloud Infra Ltd	PERMITTED	→ auditor
$300	Unknown Vendor Co	REJECTED	blocked at routing gate
$15,000	Strikaris Dev Services	PERMITTED	→ auditor

The unknown vendor never reaches the AP system. The $15,000 expense goes to an auditor, not a clerk. Every decision is sealed in a tamper-evident, hash-chained ledger (strikaris-chain). The agent acts only on what it has been formally permitted to do.

No human reviewed these in real time. No LLM decided who was authorized. The verdicts came from formal logic — and they are deterministic. Run the same queue a thousand times and you get the same result every time.

How It Works

MirrorOS is an open-source governance substrate for agentic AI systems. It sits between an agent and the systems it wants to touch. Before the agent does anything — approves a payment, updates a record, triggers a workflow — MirrorOS runs two checks:

Gate 1 — Prolog behavioral verification. Does this action violate any rule in the Codex? The Codex is a set of formal laws written in SWI-Prolog. Rules like “a clerk may not approve payments over $1,000” or “an agent may not approve a bill that was not routed to it.” These aren’t prompts. They’re logic.

Gate 2 — Z3 structural verification. Is this action mathematically consistent with the system’s axioms? Z3 is a formal theorem prover from Microsoft Research. It doesn’t guess — it proves.

If both gates pass, the agent executes. If either gate fails, the agent is blocked. The decision is sealed in a tamper-evident ledger (strikaris-chain), where any later alteration breaks the record’s cryptographic verification.

The gate verdicts are deterministic. The audit ledger is tamper-evident.

MirrorOS is agent-agnostic. It doesn’t care what kind of agent is asking — a browser automation tool, a LangChain agent, a custom ERP integration, a scheduled script, or any code-driven system that can call the MRS bridge. If it declares intent, MirrorOS governs it.

Why Nova Act Specifically

Our Nova Act demo — built for the AWS Nova Act hackathon — shows the key architectural distinction from standard Nova Act integrations.

Standard pattern:

nova.act(
    "Go to invoices, find #1042 for $25,000, check if it's within "
    "approval limits and the vendor is verified, then approve if compliant"
)

The LLM decides whether to approve. The governance is inside the prompt. It’s probabilistic and cannot be audited.

MirrorOS pattern:

# Prolog already ruled — verdict is PERMITTED
# Nova Act is a cursor, not a decision-maker
nova.act(f"Approve invoice {invoice_id}")

By the time Nova Act receives an instruction, MirrorOS has already evaluated the action against the Codex, verified structural consistency with Z3, and sealed the verdict in the ledger. Nova Act is never asked whether the action is allowed. It is only told what to click.

You cannot prompt-inject Nova Act into approving a prohibited payment. It was never asked. The gate is upstream of the model.

Why This Matters — For Two Different Audiences

For Compliance and Audit Teams

The hardest part of deploying AI in enterprise isn’t the model — it’s the compliance question. How do we prove to our auditors that the AI only did what it was supposed to do?

Today, most teams answer that with logs. But logs are descriptive — they tell you what happened after the fact. MirrorOS is prescriptive — it prevents violations before they happen and proves compliance mathematically at the moment of action.

Instead of reviewing thousands of log entries after a quarter closes, you get a sealed, verifiable decision trail where every action carries a formal proof of authorization.

For Enterprise AI Builders

MirrorOS gives you something prompt engineering never can — a guarantee. Not because you trust the model, but because the model’s actions are constrained by law, not by hope.

The authority hierarchy is explicit and never inverted:

Prolog (Law) → Z3 (Verification) → Python (Bridge) → Agents (Action)

No temperature. No hallucination. No prompt injection.

Why NetSuite Specifically

At Strikaris, our work lives inside NetSuite environments. We’ve seen firsthand what happens when automation runs without guardrails: scripts that quietly drift out of compliance, scheduled jobs with unrestricted record access, integrations that bypass approval workflows.

When an AI agent makes thousands of micro-decisions a day across your ERP environment, you need governance that operates at the same speed. MirrorOS is that layer — formal Codex rules that reflect real business policies, enforced before every action, not after.

What Comes Next

Our prototype phase gave us a working foundation. What we were building toward:

Governed MCP usage: MirrorOS sitting between an LLM and MCP servers means every tool call — NetSuite, Shopify, any connected system — routes through the dual gate before it executes. Formal constraints on MCP tool use, with a tamper-evident audit trail. This is the natural next layer for any team already adopting the Model Context Protocol.
SDF analyzer → MirrorOS pipeline: Strikaris has since built the SuiteCloud SDF Analyzer, which produces deterministic snapshots of a NetSuite environment — what scripts exist, what they access, how they connect — giving governance architects the full picture before they write a single Codex rule. Connecting it to MirrorOS is the step that remains.
LLM-powered risk assessment: integrating a domain-specialized language model to provide plain-English risk assessments alongside MirrorOS’s formal verdicts.
Expanded Codex rule sets: covering procurement, HR, CI/CD, and financial workflows.

The core insight we want to leave builders with:

Trust in AI agents isn’t built by making better models — it’s built by making better systems around them.

MirrorOS is that system.

MirrorOS is open-source at github.com/Strikaris-Tech/mirroros. Strikaris builds the SDF Analyzer and its audit service for NetSuite teams at strikaris.com. If you’re building agentic systems in enterprise environments and want to talk governance, reach out.