One Contract, Multiple Enforcement Points for Safe AI Agent Execution

Ota introduces a multi-layer enforcement framework for safe AI agent execution, moving beyond instruction files to repo governance via a declared contract (ota.yaml). The system enforces compliance at CI merge gates and runtime boundaries, ensuring agents follow verified execution lanes rather than relying on suggestions.

A lot of AI agent safety discussion still stops too early. People talk about: 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: 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. A local runner is valuable because it gives fast feedback. It can tell an agent: 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: That is important. It is just not the last enforcement boundary. The durable version is when an organization makes contract-owned lanes mandatory at the places people cannot opt out of. That means: 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 specThat is the difference between repo guidance and repo governance. 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: 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: It should answer: 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. CI is the right first gate, but it is not the whole answer. CI can tell you: CI cannot tell you: That is why the second mandatory enforcement point matters: 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: That is the runtime-side equivalent of required checks. The biggest failure to avoid is not just weak enforcement. It is split-brain enforcement. If: then the repo is back to drift. The mature model is: That means: 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. This is where repo governance gets more serious than AGENTS.md . An instruction file can say: That is useful. But it is still prose. What scales is when the repo can declare: 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 most durable shape is not: It is: 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 https://ota.run/blog/one-contract-multiple-enforcement-points-for-safe-ai-agent-execution