Safe by default is only half the execution-governance problem
A repository needs a routine execution lane.
That lane should cover the w...
For further actions, you may consider blocking this person and/or reporting abuse
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?
Auditing the boundary crossings is the detail most people skip until something leaks across one. I treat every jump between the repo and an external call as a place to log and check, because that is where the hard-to-trace failures hide. Curious whether you enforce those boundaries at runtime or catch them in review.
Short answer: both, with different strengths.
Runtime should be the enforcement layer for hard boundaries.
Ota catches those jumps when they can cause side effects: e.g. task execution mode, service/network exposure, working directory, toolchain/provider usage, and writable/protected paths. If it’s not enforceable in execution, review-only checks are not enough.
Review/code-level validation should be the intent layer.
We catch missing intent before runtime: missing agent boundaries, weak/ambiguous launch definitions, unsafe defaulting, mixed contexts, and schema violations.
How do you go about it at the moment?