Why Agent Safety Needs Enforced Boundaries, Not Just Declared Ones

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.

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.

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.

Imagine a repo declares:

• test is safe for agents
• publish is 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.

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.

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.

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.

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:

• Execution Receipt

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.

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.