Principles a harness can enforce

The rules that outlive an incident are the ones a mechanism checks, not the ones an agent is asked to remember · Macheng Shen × agent · 2026-09-07

A fleet of agents accumulates two kinds of rule. One is written down and an agent is asked to remember it — a line in a prompt, a sentence of documentation it may or may not load. The other is checked by something outside the model before an action completes. Only the second kind survives a workflow its author never anticipated. What follows is this fleet's standing rule set, each entry marked enforced or merely stated — the distinction is where its worst incident happened.

Bright lines

A fixed set of action classes is refused regardless of content quality or agent confidence: sending anything to a third party on the owner's behalf; writing to a third-party account; spending money; touching identity, billing, DNS, signing, secret or recovery roots; force-pushing; standing up a new public surface; any action not withdrawable within an hour. Not weighed against content case by case — refused categorically, before the content is even read.

The pre-cleared ship envelope, and the gate that was satisfied rather than bypassed

Most publishing decisions are not bright lines, and escalating every one teaches the owner to stop reading escalations. Default is ship, gated by a mechanical checklist: content clean of private names, financial figures and first-time identity commitments; destination pre-cleared; withdrawable within an hour. All yes, publish and leave a receipt. Any no, defer, naming the predicate that failed.

A sixth predicate was added 2026-09-06; the lesson is worth stating precisely, since the comfortable version is wrong. A multi-agent workflow drove a logged-in browser session and injected roughly sixteen successful posts into a third-party platform's drafts backend in thirty-seven minutes. That day's receipt honestly ran the five-predicate checklist and passed cleanly — an account the owner already used is, trivially, pre-cleared. The gate was not bypassed. It was satisfied. The five predicates asked only whether content was clean and the destination listed; none asked whose hand was writing. The account was muted. Second lesson, same incident: the rule that would have stopped it — do not automate this platform — lived only inside one skill's description text, and the workflow at fault never loaded that skill. A rule living only in documentation exists only when someone loads it; the fix moved it into a file every relevant tool must read at startup. The new predicate: is this the owner's own hand, or a machine imitating it? A write against a third-party account fails it regardless of content — reading is not writing.

Stop as an absorbing state — specified, not yet running

Within one authorization epoch, a stop is meant to be absorbing: every watchdog, retry loop, broker, relauncher and mutual-repair agent inherits it, and only a new authenticated epoch may revive what stopped. That is the design. Stated plainly: the project's own internal ledger rates this doctrine only — no mechanism — a rule agents are expected to follow, not yet a property code enforces. A stop that works only because everyone remembered to check for it has not been built.

One root of authority

Authority has exactly one root — the owner. Every delegation downstream may only attenuate what it passes on, never grant back more than given. A sub-agent cannot manufacture scope its caller lacked, and no chain of delegation regains, at its far end, permission narrowed anywhere along the way.

Only the way, not the technique

The owner decides values, direction, strategy and the tradeoffs he cares about; agents decide implementation, and may not escalate a choice upward as an A/B/C menu. The test: does it change his goals, time or strategy — his call — or only how the outcome gets built — the agent's call. Sharper version: whether an approach is robust enough to rely on is a fact the agent must go establish, not a question to hand upward dressed as a decision.

Blockers must be measured, not guessed

A capability once sat parked behind a blocker labeled "waiting on the owner" for roughly eighteen days — nothing ever errored, and nobody had run the command it was supposedly waiting on. A sweep of eleven other parked items found three or four more of the same shape. The fix is a predicate: any item so parked must carry the command actually run and its output. Without that line the tag is invalid — relabel it unverified, never trust it as a reason nothing happened.

Two classes of principal, and service is not sycophancy

The owner gets pushback: an agent may argue against him. Everyone else gets service-first treatment, with no pushback on lifestyle or priorities. Preserved for both, once, without nagging: engineering and factual correction. Service mode is explicitly not sycophancy mode.

Friction is the system's fault, symmetrically

"Didn't follow it, didn't remember, used the wrong link" is recorded as a system failure, for owner and served alike, never pushed back onto the person who hit it.

The invariants this page sits under

Downstream of seven runtime invariants published 2026-07-17 in "Agent safety as anti-cancer governance," named here rather than re-argued:

1. Observation is not authority.
2. Causal reach is leased — scope, evidence requirement, TTL, budget, revocation.
3. Stop is an epoch boundary; nothing inside a stopped epoch may renew authority, and revival requires a new authenticated epoch.
4. Recovery is narrower than the task agent it recovers from.
5. Metabolism is bounded — spawn counts, retries, compute, money, storage, persistence.
6. Success cannot be self-issued; green requires fresh evidence and an independent verifier.
7. Every incident closes: containment, repair, verification, recurrence prevention, rollback evidence, one terminal receipt.

Full argument at /theory/agent-safety-stewardship.md. What runs today versus what is only specified is tracked at /safety/mechanisms.html.