Bobai Kato for Ota

Posted on Jul 30 • Originally published at ota.run

One Contract, Multiple Enforcement Points for Safe AI Agent Execution

#aiagents #executiongovernance #ci #sandbox

Overview

A lot of AI agent safety discussion still stops too early.

People talk about:

prompts
instructions
guardrails
whether the agent "knows better"

Those things matter, but they are not where the real control lives.

If an agent can ignore the instructions, pick the wrong execution path, skip the real verification
lane, or claim success without independent evidence, then the repo does not have enforcement.

It has suggestions.

That is why the stronger shape is not "better prompting."

It is:

one declared contract
multiple enforcement points
no second hand-maintained execution policy

Ota provides the declared repo contract and local execution boundary. CI projection and runtime
providers can consume that truth, but they do not become competing execution contracts. A provider
still owns its triggers, credentials, runner selection, deployment policy, and branch-protection
settings. Ota owns the contract-derived execution lane, its admission, and the evidence it can
honestly emit about that lane.

The Local Runner Is Useful. It Is Not The Final Teeth.

A local runner is valuable because it gives fast feedback.

It can tell an agent:

this task is safe
this workflow is not callable
this path is blocked
this repo is not ready

That is already much stronger than a plain instruction file.

But a local runner is still optional.

If one team uses the contract-aware runner and another team points a different agent at the same
repo, local enforcement alone does not scale. The same is true if someone simply bypasses the
preferred agent flow and uses a different tool.

That makes the local runner the fast-feedback layer, not the final teeth.

Its job is:

early refusal
early visibility
local proof and receipts
safer routine execution before review

That is important. It is just not the last enforcement boundary.

The Real Teeth Live At Mandatory Chokepoints

The durable version is when an organization makes contract-owned lanes mandatory at the places
people cannot opt out of.

That means:

Ota projects the declared CI verification lane
branch policy makes that check required at merge time
an identified runtime provider applies the compatible capability and sandbox controls at execution time

Those chokepoints do not care which agent was used.

They do not care which local runner someone prefers.

They sit at the points the organization already relies on to keep human changes and automated
changes inside the same review and execution boundary.

So the stronger stack is:

ota.yaml as the declared spec
local runner enforcement for immediate feedback
contract-owned CI checks, made mandatory by provider branch policy
runtime capability boundaries, only where the selected provider can apply and attest them

That is the difference between repo guidance and repo governance.

Why CI Comes First

If you want to move higher in the stack, CI is the first practical enforcement point that can be
made mandatory.

Why?

Because the merge gate already exists.

Most teams already have:

CI runs
required checks
branch protection
some notion of mergeability

Once provider branch policy requires the contract-owned check, CI becomes the first non-optional
place where repo truth can become enforcement instead of convention.

What CI should answer is not:

did a random workflow happen to pass

It should answer:

did the repo's declared merge-relevant verification lanes pass
is the required proof present
did the execution path stay inside contract-owned governance truth

A green required CI check should mean:

this change is merge-compliant with the repo contract.

That is a much stronger statement than:

someone ran something and the job happened to go green.

A Green Check Is Not A Runtime Boundary

CI is the right first gate, but it is not the whole answer.

CI can tell you:

whether the declared merge checks passed
whether the required evidence exists
whether the contract and CI wiring agree

CI cannot tell you:

what an agent will try at runtime
whether the harness still exposes undeclared actions
whether the execution boundary is actually constrained
whether the agent can still reach external effects you did not intend

That is why the second mandatory enforcement point matters:

sandbox and capability policy

The repo contract should not only describe what is mergeable.

It should also be consumable by the runtime boundary.

But a declaration is not enforcement by itself. If the selected runtime provider cannot apply and
attest a declared control, Ota must refuse that lane rather than print a stronger claim than the
provider earned. This is why capability-aware admission matters: the contract declares the
boundary; the runner verifies that the chosen provider can actually hold it.

That means a harness or sandbox should be able to enforce things like:

this task is callable in agent mode
this task is not callable in agent mode
this path is writable
this path is protected
this execution lane implies external effects
this execution lane requires review

That is the runtime-side equivalent of required checks.

One Contract, Not Three Policies

The biggest failure to avoid is not just weak enforcement.

It is split-brain enforcement.

If:

the local runner has one understanding of safe execution
CI has another
the sandbox has a third

then the repo is back to drift.

The mature model is:

one contract
multiple enforcement consumers
no duplicated Ota execution policy

That means:

the contract is the source of truth
the local runner consumes it for fast feedback
CI consumes it for a contract-owned merge check
the harness or sandbox consumes it for compatible runtime capability boundaries

Provider configuration still retains provider-owned truth: triggers, permissions, runners,
credentials, deployment environments, and the branch policy that makes a check mandatory. The
point is not to erase those boundaries. It is to stop duplicating Ota-owned bootstrap,
verification, admission, and proof truth across them.

What This Means For AI Agent Governance

This is where repo governance gets more serious than AGENTS.md.

An instruction file can say:

be careful
run tests
avoid dangerous commands
ask before touching infrastructure

That is useful.

But it is still prose.

What scales is when the repo can declare:

which lanes are safe
which verification path is merge-relevant
which evidence is required
which tasks are callable in agent mode
which effects require review

Then the rest of the stack can enforce that declared truth.

That is how a repo contract stops being a suggestion and starts becoming infrastructure.

The Stronger Direction

The most durable shape is not:

"everyone uses the same runner"

It is:

one repo contract
local enforcement for speed
CI checks made required by provider merge policy
runtime capability boundaries where a provider can enforce and attest them

That is the real higher-stack version of execution governance.

It does not depend on trusting agent behavior.

It depends on making repo truth explicit enough that the mandatory chokepoints already sitting in
the stack can consume it, and on refusing when a selected enforcement point cannot hold the
declared boundary.

If you want the deeper boundary between instructions and governed execution, read:

Originally posted here: https://ota.run/blog/one-contract-multiple-enforcement-points-for-safe-ai-agent-execution