Safe by default is only half the execution-governance problem
A repository needs a routine execution lane.
That lane should cover the work developers, CI systems, and AI agents perform repeatedly:
- lint
- test
- bounded verification
- local readiness checks
- finite generated-output checks
But serious repositories also have heavier lanes:
- publish a package
- run a migration
- deploy an environment
- modify external state
- execute a destructive recovery
- call a black-box production dependency
Pretending those lanes should never run is not governance.
Treating them like routine verification is not governance either.
Ota's position is that leaving the default-safe lane should become an explicit, auditable execution
event.
That event is a boundary crossing.
A crossing is not the same as a refusal
Agent safety and audited crossings solve different problems.
Agent mode answers:
Is this complete task or workflow closure safe for an agent to execute?
If the answer is no, Ota refuses it before selected work begins.
Audited crossing answers:
This heavier non-agent lane may be allowed, but what boundary was crossed, why was it crossed, and
what execution evidence belongs to that decision?
A grant must never turn an agent-unsafe lane into an agent-safe one. Crossing is not a bypass around
safe-task enforcement.
It is a separate governance path for allowed-but-non-routine non-agent execution.
What Ota publishes today
Ota's released governance and receipt surfaces can distinguish routine execution from a selected
lane that requires a crossing.
The important fields are:
crossing_requiredcrossing_classification- runner-authored crossing evidence linked to the selected execution
For example, current governance JSON can make the boundary visible before execution:
{
"crossing_required": true,
"crossing_classification": "escalated",
"crossing_boundary_family": "unsafe_task"
}
That is a governance decision, not approval and not evidence that the task ran. Agent-mode safety
still decides whether the selected closure is callable by an agent.
The released classification distinguishes routine posture from escalated posture. Ota does not
publish an exceptional machine classification today.
The crossing record belongs to one execution. It is evidence that the boundary was crossed. It is
not reusable approval authority for the next run.
That separation matters:
- authority answers whether this execution may cross
- the crossing record says what actually crossed
- the receipt links the decision to execution outcome
Reusing a crossing record as authority would let yesterday's evidence authorize tomorrow's work.
Ota rejects that model.
The stronger authority carrier is implemented but still in development
On the 1.6.26-implementation branch, Core implements the first preview signed-authority carrier.
V11.7 remains partial because that carrier has not completed its live-grant pressure bar and the
separate one-use broker carrier remains planned.
The preview contract names an independently managed authority:
governance:
crossing_authority:
authority_id: platform-release-authority
The repository does not carry the trust key, signed bundle path, revocation state, or sequence
state.
That is deliberate. If the caller can edit both the lane and the authority that approves it, the
approval is self-issued.
The preview invocation is:
ota run publish --grant approved-publish
The current preview admission binds the grant to:
- the exact semantic contract identity
- the complete selected task or workflow closure
- the crossing family and classification
- bounded actor posture
- mode, lifecycle, target platform, and declared effects
- a short validity window
- current signed revocation and sequence truth
A missing, stale, revoked, rolled-back, or out-of-scope grant must refuse before the selected lane
starts.
Real admitted execution must create a fresh runner-owned crossing transaction before selected-lane
mutation and finalize that transaction on success, failure, interruption, or recoverable
abandonment. Dry-run and refusal must not mint a crossing record.
The first carrier is deliberately bounded as current_process_filesystem_guarded. It verifies a
fixed system trust binding, signed bundle, revocation state, and sequence state protected from the
current unprivileged Ota process. It does not prove provider-attested privilege separation or a
verified human, CI, or platform identity.
What is not complete yet
This signed authority surface is implemented in Core, but it is not released or complete.
GitHub-hosted create-chrome-extension pressure
already proves that missing fixed authority refuses before selected work. That is useful fail-closed
evidence, but it does not prove that a live grant is protected from the job that consumes it.
The remaining gates include:
- valid, expired, revoked, and out-of-scope live-grant pressure on a pre-provisioned hardened non-root runner
- a broker-backed, atomically consumed one-use work-unit lifetime
- independently authenticated per-use transaction state beyond same-user local reconciliation
- broader protected-system authority support across platforms
Those are trust boundaries, not documentation polish.
Until they close, Ota should describe the grant carrier as active development, not as shipped
enterprise approval infrastructure.
The durable design rule
The mature model is:
- for the bounded signed-file carrier, reuse a still-live grant only while its exact scope remains valid
- for the planned broker carrier, issue and atomically consume one lease for one exact crossing
- never reuse the crossing record
- mint fresh runner-authored crossing evidence for every execution
- recheck grant liveness at the boundary
- keep principal, authorizer, and runner context separate
- refuse when Ota cannot verify the authority it would need to make the stronger claim
That keeps routine work cheap and makes non-routine execution explicit without turning every command
into approval ceremony.
It also gives reviewers a better artifact than a log line saying someone ran deploy.
Why this matters for Ota
Execution governance cannot stop at "allowed" and "denied."
Real repositories need a third answer:
allowed only through an explicit, attributable, bounded crossing
Ota already makes the crossing visible. The active authority work is about making admission
trustworthy without letting the repository or caller approve itself.
That is the difference between recording that a risky command ran and governing how it was allowed
to run.
Where does your repository record that distinction today: a workflow approval, a ticket, a CI log,
or nowhere?
References
- Audited Execution Boundary Crossings
- Safe Agent Execution and Refusal
- Execution Receipt
- Execution Governance Loop
- Prebound Crossing Authority
- Preview example
Originally posted here: https://ota.run/blog/why-heavier-repository-execution-needs-audited-boundary-crossings
Top comments (7)
The non-reusable crossing record is the part I would underline twice. I learned this one the expensive way: a metered API in one of my pipelines got a standing "allowed" and quietly re-authorized itself a dozen times in a month before the bill arrived. The fix was exactly your third state in miniature, an explicit per-run flag with no memory, so every crossing costs one deliberate human decision. A reusable approval is just an allow wearing a costume.
The design tension I would love to see ota tackle head-on: crossing friction has a half-life. If the ceremony is even slightly heavier than the operation deserves, developers alias it away in a week and the audit trail records theater instead of decisions. Keeping the record honest probably matters less than keeping the crossing cheap enough that nobody routes around it. Curious how you are thinking about that side.
Exactly. A crossing record is single-use; it cannot authorize the next run.
A reusable grant is only legitimate when it is narrow, expiring, revocable, issuer-bound, and rechecked at crossing time. Otherwise it is a standing allow with better branding.
The UX bar is equally important: routine governed work must be easier than bypassing it, while exceptional work should need one clear decision, not policy-file edits or copied IDs.
What is the smallest authorization interaction your team would actually keep using instead of routing around it?
The smallest one that survived for me is a token on the same command line as the action:
PLACES_BILLING=allow python sweep.py. No memory between runs, impossible to hit by accident, and it lands in shell history so the record writes itself.What made it stick was location, not size. It lives inside the keystroke I was already typing. Every heavier version died the same way: it made me leave the flow, and then I just stopped doing the operation that way.
The honest gap is that it proves a deliberate decision happened, but not whose. That is where your layer earns its place: capture identity and intent around the token the operator was already going to type, rather than adding a step before it.
I agree. The interaction survived because it stayed inside the command already being run.
For Ota, Iād keep that command-adjacent intent but separate it from authority. The operator supplies a per-run crossing marker; Ota resolves the pre-bound authorization, verifies scope and identity where available, and emits a fresh crossing record. No policy edits, copied grant IDs, or authority tokens passed into the task.
For exceptional work, would one broker-side approval inside that same command flow still feel lightweight enough?
It stays lightweight if the wait is bounded and the answer comes back in the same terminal. It stops being lightweight the moment approval depends on another human with no clock on it. That is not really a UX difference, it is a different operation: one blocks for seconds, the other blocks until someone else wakes up.
The failure I would watch for is not people consciously bypassing. It is batching. When a crossing costs five minutes, nobody does five crossings, they do one crossing wrapped around five operations, because that is the rational way to amortize ceremony. The approval still happens, the record still exists, and the governance quietly stops meaning anything, since the thing that was authorized is now a bundle nobody itemized. So the metric I would track is not approvals granted, it is operations per crossing. If that number starts climbing, the ceremony is too expensive, no matter how good the audit trail looks.
That batching failure is the right metric to watch.
Iād refine it from raw operations per crossing to scope breadth per crossing: executable steps, effects, resources, and whether the authorized closure keeps expanding. One declared workflow may legitimately be one operation, but a growing catch-all crossing is governance decay.
The broker path should also stay in the same terminal with a bounded wait. Timeout or ambiguity must refuse before execution, not leave a silent pending authority.
Do you treat a declared workflow as one operation, or evaluate each effectful step inside it separately?
Neither, in my experience. The unit that survives is the irreversible effect, not the workflow and not the step. A forty-step workflow where thirty-nine steps are reads and one is a write is one crossing, and asking about the other thirty-nine is the ceremony tax that starts the batching. Five writes to five resources is five effects, but it should still be one interaction that names all five up front rather than five prompts.
So the shape I would build: the crossing authorizes a declared effect set, evaluated once before execution, and the runtime refuses any effect not in that set. One interaction for the operator, itemized record for governance, and the declaration is a contract rather than a description. That also gives you your expanding-closure detector for free, since a crossing whose declared set grows every week is visible without anyone having to notice it.
One case worth designing for explicitly: effects that cannot be enumerated ahead of time. My metered API call is exactly that, since the run discovers how many lookups it needs as it goes. There the declaration has to carry a bound instead of a list, up to N calls, and hitting N refuses rather than continues. A workflow that can declare neither a set nor a bound is telling you it should be split.