ZeroGate: agents should carry bounded action passes.

We built ZeroGate because governed agents cannot feel like a human approval queue forever.

That does not mean governance should disappear. It means the common path has to be engineered differently. The normal action should arrive at the runtime boundary carrying enough bounded authority to be checked locally. The exceptional action should slow down. The unsafe action should fail closed. The proof should remain replayable after the fact.

The design inspiration came from a very different category: Japanese transit infrastructure.

The useful lesson from Suica and FeliCa is not simply "make it fast." The deeper lesson is system shape. The gate does not make the passenger wait while a remote back office reconstructs the whole trip. Slow facts are prepared before passage. The gate consumes a bounded object. Exceptions are routed explicitly. Settlement and reconciliation happen after the minimum transaction exists.

That is the mental model behind ZeroGate.

The problem

Most agent governance designs put too much work on the wrong side of the boundary.

Before an AI agent touches a ticket, a database, a payment workflow, a cloud resource, a GitHub issue, or a customer-facing system, the company needs to know what is being approved. But if every ordinary action must synchronously reconstruct policy, state, approval context, verifier evidence, and audit material from scratch, the system becomes slow enough that teams start bypassing it.

The opposite failure is worse. If the runtime only checks broad tool permission, it may know that the agent can call a tool, but not whether this exact action still matches the approved boundary.

That is the gap ZeroGate is meant to close.

What ZeroGate adds

ZeroGate introduces an Action Pass.

An Action Pass is not a broad credential and not a nicer audit log. It is a short-lived, signed, locally checkable execution ticket for one bounded action. It binds the runtime decision to the exact CAVA action fingerprint, granted authority, policy digest, state digest, holder/session identity, nonce, budget, revocation state, and minimum receipt condition.

At the commit boundary, the runtime should only need to do a compact local check:

verify the pass envelope
match the CAVA action fingerprint
check holder and runtime session
check policy and state freshness
consume nonce and budget
emit minimum receipt
execute, slow down, or fail closed

The important word is "boundary." ZeroGate is not trying to make the whole governance system disappear. It moves slow and explainable work out of the commit instant, while preserving the evidence needed to prove what happened later.

How it fits OSuite

ZeroGate does not replace CAVA, PCAA, BAF, or AREG.

It connects them at the runtime boundary.

This is why we think ZeroGate is an upgrade path rather than a fork. The existing OSuite stack still decides what the action is, who had authority, and what evidence must survive. ZeroGate changes when the runtime has to ask for that decision again.

Three lanes, not one queue

The product experience should not be "ask a human every time."

It should look more like runtime traffic control.

This gives operators a better interface. They do not need to review every moving part. They need to see which actions have a valid pass, which actions left the fast lane, and why.

What we measured

The first public ZeroGate release is intentionally careful about what it claims.

It includes a synthetic regression oracle, a multi-runtime fixture corpus, a public GitHub Actions corpus, a concurrent implementation load study, noisy recognition checks, and operations-research routing simulations. Some of those are accuracy-style checks over authored cases. Some are coverage and abstention studies. Some are local evaluator timing studies. They should not be collapsed into one marketing number.

The headline numbers are still useful:

Those numbers do not claim hosted customer SLA. They do show something narrower and important: the boundary evaluator itself can remain small, local, and strict while the rest of the governance system remains replayable.

Why this matters

The agent stack is moving quickly toward harnesses, protocols, control planes, tool gateways, and agent-to-agent identity.

Those layers matter. They get the agent to the gate.

ZeroGate asks a different question: does this exact bounded action get through the gate now?

That question becomes urgent when a company has hundreds or thousands of agents producing action-like events all day. A governance system cannot linearly treat every context item, dependent subaction, retry, and ambiguous wrapper as the same kind of decision. It has to recognize the passage object, fold context where it belongs, slow down collisions, and reserve scarce review capacity for work that cannot be safely committed locally.

That is why the ZeroGate paper includes not only latency checks, but also action-stream recognition and operations-research routing models. Speed without classification is just a faster bypass. Governance without routing becomes a queue.

What comes next

We are treating ZeroGate as a product primitive, a benchmark lane, and a research direction.

The blog version is the public doorway. A whitebook will explain the design intuition visually, including the transit-system inspiration and OSuite product implications. The arXiv paper will carry the formal model, benchmark boundary, limitations, and reproducible artifact.

For now, the public v0.1 release is available here:

Inspect the ZeroGate v0.1 release

The simple version is this:

Identity gets the agent to the gate.

The Action Pass decides whether the action gets through.

The receipt proves what happened afterward.