Overview
Agent safety does not get real the moment a repo declares:
- safe tasks
- protected paths
- review-required lanes
- external-effect lanes
That is only the first half.
The second half is whether anything fails when those declarations are wrong, stale, or bypassed.
That is the real line between repo governance and well-formatted advice.
Declared Boundaries Are Necessary
A repo should absolutely declare:
- which tasks are safe for routine agent use
- which workflows are review-required
- which files are writable
- which files are protected
- which commands can mutate external state
- which verification paths are finite and meaningful
Without that, the agent has to infer boundaries from README prose, CI jobs, helper scripts, and old maintainer habits.
That is not a safety model.
It is guesswork with better intentions.
But Declared Boundaries Are Not Enough
If the repo contract says one thing and the actual execution path does another, the declaration degrades quickly.
It becomes one more soft signal beside:
AGENTS.md.env.example- a stale contributor guide
- a CI workflow nobody meant to be canonical
That is why a repo contract only stays true if it lives inside the execution loop.
The local runner has to consume it.
CI has to consume it.
Receipts have to record the path that actually ran.
Otherwise the repo has declared boundaries, but no enforced boundaries.
A Simple Failure Shape
Imagine a repo declares:
-
testis safe for agents -
publishis not -
migrations/is protected - production-facing tasks require review
That sounds fine on paper.
But now imagine:
- the runner still lets an agent invoke
publish - CI never checks whether the declared verification lane was the one that passed
- the agent edits a protected file and nothing complains
- the receipt only says "task completed" without recording the contract path or refusal state
At that point the repo has not actually governed anything.
It has just documented preferred behavior.
The dangerous part is that this can still look disciplined. The contract exists. The docs look good. The review story sounds serious.
But the boundary has no teeth.
Execution Is What Keeps Safety Truth Honest
A boundary becomes real when crossing it changes behavior.
That means:
- an unsafe lane is refused by the runner in agent mode
- a protected path boundary is enforced or surfaced by the consuming runner or harness instead of staying as passive metadata
- a required verification lane is enforced at merge
- a runtime capability boundary only exposes the callable surface the contract allows
- the receipt shows whether execution was allowed, refused, blocked, or only advisory
This is the important shift:
agent safety is not only about what the repo can declare.
It is about what the repo can enforce.
Execution is the preservative for safety truth.
The settings the engine actually reads stay accurate far longer than the settings a team merely writes down.
Why Local Runner Enforcement Matters
The local runner is the fastest place to stop bad routine behavior.
If an agent asks for a task outside the declared safe surface, the runner should be able to refuse before the task starts.
That matters because:
- the agent gets a clear stop signal early
- the repo does not have to rely on prompt obedience
- refusal becomes evidence, not folklore
This is where declared safe tasks stop being metadata and start becoming a real execution boundary.
Why CI Enforcement Matters
Local runner enforcement is not enough on its own.
Teams can use different agents.
People can route around local conventions.
Tools can drift.
The merge gate is where the repo gets one mandatory chokepoint.
That is why CI has to enforce the same contract truth too:
- which verification lanes are required
- which proof must exist
- which workflow is canonical
- whether contract and CI wiring have drifted apart
If the contract lies, the build should break visibly.
That is much stronger than hoping the next human or agent notices the mismatch by reading more context.
Why Receipts Matter
Safety also needs evidence.
If a boundary was crossed, refused, or bypassed, someone should not have to reconstruct that from chat logs or terminal fragments later.
Receipts are the durable layer that can say:
- which contract path ran
- which actor mode was used
- whether the lane was allowed or refused
- what evidence was collected
- whether execution stayed inside the declared boundary
That is what makes enforcement auditable instead of anecdotal.
For the public receipt surface, see:
This Is Why Ota Is Not Just A Better Instruction File
The weaker model is:
- write better guidance
- tell the agent to be careful
- document what should happen
The stronger model is:
- declare the boundary once
- enforce it locally
- enforce it at merge
- emit evidence when the boundary is crossed, blocked, or refused
That is the difference between declared agent safety and enforced agent safety.
Ota is trying to live on the stronger side of that line.
Bottom Line
Agent safety needs declared boundaries.
But it does not stop there.
If nothing consumes those boundaries, nothing fails when they drift, and no evidence is emitted when they are crossed, the repo has not built a safety system.
It has built documentation.
That is why agent safety needs enforced boundaries, not just declared ones.
Original posted here: https://ota.run/blog/why-agent-safety-needs-enforced-boundaries-not-just-declared-ones-4m7q
Top comments (2)
Enforced beats declared, agreed. The catch is that an enforcement layer decays into a declared one silently: a runner that refuses unsafe tasks can stop refusing (config drift, an allowlist hole, a regressed check), and from the outside a broken gate and a never-built gate look identical, both let the action through. So enforcement needs the same negative control it imposes on the agent: a canary unsafe action that must be refused on every run and fails the build the moment it slips through. Otherwise "enforced" quietly rots back to "declared" while the receipts still read task completed.
Solid point. A gate is only real if it can keep proving it still refuses.
Otherwise, enforcement can silently decay back into declaration and from the outside it looks the same as a boundary that never had teeth.
I agree the right bar is a negative control: a known unsafe lane that must be refused, with that refusal recorded as evidence instead of assumed from the policy alone.
That is undoubtedly the kind of pressure we want Ota to handle because “task completed” is not enough if the thing that should have been blocked was never challenged.
Curious what form that canary usually takes for you in practice: a synthetic unsafe task, a protected-path write, an external-effect lane, or something else?