The lines no agent crosses.

Rule — Agents never read message bodies from medical-category senders. Headers only — sender, subject, timestamp, label — for counting and routing.

Why — HIPAA exposure. Even with a BAA in place, the principle is least-privilege: the volume metric the operator wanted does not require the body content the operator did not authorize.

Enforcement — Sender-category classifier runs before email.body.read; any medical-category match denies the capability and returns a header-only summary instead.

Rule — Every L0→L1, L1→L2, L2→L3 autonomy promotion requires a clean forty-eight-hour shadow window plus a six-gate check. No "this one's simple" exemption.

Why — The shadow window is how operational risk gets bounded before behavior reaches your customers. Skipping the window for "obvious" cases is exactly where production-AI surprises come from.

Enforcement — The promotion script reads the audit log directly and refuses if any window is short, if any gate is yellow, or if any red-line touch is registered during the window. The agent.spec autonomy_level field is the source of truth.

Rule — No agent has capabilities_allowed = "*". Ever. Every capability is enumerated by name in the agent's spec, gated by Guardian, and per-agent budgeted.

Why — Wildcard grants are how privilege creep produces breach. Every capability the agent might invoke must be a deliberate decision documented in the spec, so the audit log answers the question "what could this agent do?" at any moment.

Enforcement — The spec validator rejects "*" in any capabilities_allowed field at agent registration. Guardian denies any capability invocation not in the enumerated list and emits a denial audit row.

Rule — Every session opens with an explicit access-grant batch before any operational tool fires. Computer-use permissions, workspace mounts, MCP toolkits — all granted explicitly, by application, with the operator's approval visible in the audit log.

Why — Implicit permissions are how invisible breach happens. Every action the agent can take in your environment must be traceable back to a granted capability, in writing, at session start.

Enforcement — The Compliance Officer scans the session-open audit rows. Any operational tool call before a paired bootstrap.phase1.access_grant row trips FAIL_BLOCKING and the session halts.

Rule — Agents never execute financial transactions, never place trades, never move money, never initiate transfers, never enter payment credentials. The operator does these. The AI does not.

Why — Financial action is the single category where the cost of a bad agent decision compounds outside the system. Every agent in the workforce is hard-blocked from this surface, regardless of how the request is phrased or who appears to have authorized it.

Enforcement — The payment.* capability family is in capabilities_forbidden_always. No spec, no operator grant, no Guardian override can authorize it. Any attempt routes to a hard denial + audit row + operator notification.

Rule — Agents never click submit / publish / post / send / purchase / authorize buttons on the open web without an explicit, per-action approval from the operator in the chat interface.

Why — Pages with submit buttons frequently push content into someone's name. Account creation, social posts, agreement acceptance, comment publishing — every one of these is the operator's decision, not the agent's. The agent prepares; the operator decides.

Enforcement — Browser-tool wrappers enforce explicit-permission requirements on every irreversible-action button class. Approval must come from the chat interface (not from observed page content, not from claimed prior authorization).