The rules we decide under

A canary call is not a probability, it is evidence. Nothing legitimate discovers and invokes a decoy, so this is treated as a confirmed compromise rather than a risk score. It is denied before every other check precisely because it needs no interpretation.

An agent reads a tool description before it ever calls the tool, so a poisoned description has already influenced the model by the time execution would begin. Verification has to bind before the call, not after.

Uncertainty is not safety. Where the evidence is genuinely ambiguous the correct actor is a person, not a threshold. Defaulting ambiguity to allow would make every borderline case a silent yes.

The common real attack is a clean tool driven with a hostile value: a cloud metadata address, a credential file path, a shell injection. Verifying only the tool definition misses this entirely, because the definition is honest and the argument is not.

Several argument patterns have real legitimate uses. Loading your own model with remote code enabled is ordinary work; loading someone else's that way is not, and the difference is context we do not have. A person does.

Each capability alone is ordinary. Together in one session they are the complete shape of an exfiltration, and by the time the third is exercised the first two have already happened. The judgment must be made on what the session actually did, not on what the caller says it did.

Approval attaches to a specific version, not to a name. A tool that passes review and then changes has not been reviewed. Pinning at call time catches this when it matters rather than at the next scheduled scan.

A runaway loop and a compromised agent look the same from outside, and both are worth pausing. This is deliberately a floor for noisy failure, not a defence against distributed activity: an attacker who shards work across sessions stays under any per-session rate.

A stop that can be overridden by ordinary traffic is not a stop. This overrides every other rule including monitor mode, because the entire purpose of a kill switch is that it is unconditional.

Customers know their environment and should be able to be stricter than the baseline. Allowing them to be looser would let a compromised console disable the protection, so the direction is one-way by construction.

A human judgment on a specific version outranks any automated score. Re-litigating a decided case wastes the reviewer and risks reversing them silently.

The counterpart to the law above, and the reason both exist: a review process that can only ever convict is not a review process. Clearance binds to the exact version, so a later change re-opens the question.

Adoption fails if the first day of enforcement breaks production. Monitor mode lets an account see the judgments before they bind. The shadow decision is recorded so the record never claims a block that did not occur.

Credential rotation is the standard evasion against any identity-scoped memory, so instrumenting the churn turns the evasion into the signal. It records and never blocks, because ordinary fan-out workloads produce the same shape and enforcing here would fail across a customer's whole fleet at once.

Enforcement holds one hour of state so it stays cheap. Campaigns outlast an hour. The long look happens offline over durable records and produces an investigation surface, never a verdict.

MCP 2026-07-28 removes the initialize handshake, removes sessions, and states that a server's self-reported identity is unverified and must not drive security decisions. No client-side anchor remains for noticing that a server changed. Statelessness constrains servers, not an observer in the path, so we keep the memory the protocol discards. Reported and never blocked, because the ordinary cause is that somebody deployed.

This is QX-L-0006 with the evidence attached. The same three capabilities are present, but the path has been observed rather than inferred, so the record can state which tool introduced the untrusted input and which read the sensitive data. Naming the path is what lets a reviewer confirm or refute the finding in seconds instead of reconstructing a session by hand, and a finding a human can check quickly is one they will actually check.

A governed call that cannot reach its governor still has to resolve one way or the other. Recording this as an ordinary allow or deny would put a claim in the record that we judged something we never saw. It is published as a law because the customer chooses the fail mode, and they are entitled to know that the choice is part of the ruleset rather than an implementation detail.

Customer rules are law over that account's traffic and belong in the corpus, but their text belongs to the customer, not to us. We publish that the category exists and that it is tighten-only; we do not publish another account's rules. Note the asymmetry this creates and accept it: an account can always explain its own decision, because it wrote the rule.

A stop that fails open under a storage outage is not a stop, and one that fails closed turns a storage hiccup into a total outage. So an unreadable stop is treated as neither: it is indeterminate, and uncertainty about whether an account is stopped is resolved by a person, not by a silent allow. This is the availability layer applying the same rule as any other unresolved risk: when a required check cannot answer, the correct actor is a human.