One Contract, Multiple Enforcement Points for Safe AI Agent Execution

One Contract, Multiple Enforcement Points for Safe AI Agent Execution

Tópico: One Contract, Multiple Enforcement Points for Safe AI Agent Execution
Categoria: Tutoriais | Programação & Tecnologia
Idioma Principal: Português (Conteúdo de Tecnologia)

Descrição do Conteúdo / Informações:
-------------------------------------------------------------------------

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:

• AGENTS.md Is Not Enough for Safe AI Agent Execution

• What Belongs in AGENTS.md vs ota.yaml

• How to Align Local, CI, and Agent Execution

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