The boundaries here are harder to write than in any other domain because this one measures failure rather than success. One, the asymmetry of evaluation: a single successful jailbreak constitutes a vulnerability, while ten thousand successful refusals prove nothing, so any "jailbreak rate of 0.x%" reading only means "under the attacks tried"; the attack surface is an open set and the number is optimistic by construction. Two, inconsistency in refusal is more dangerous than refusal itself: the same class of request changes policy after rewording, a language switch, a role framing, or being buried in a long context, and an automated adversary in production will find that inconsistency. Three, tool abuse and permission boundaries currently have almost no guardrails: once an agent holds a person's credentials, an overreaching action is indistinguishable from a human action in the logs, and most runtimes today have neither transaction boundaries nor rehearse-then-commit - which is why it is listed as the biggest production risk in the `agents` domain even though the problem belongs to safety and lives in agent implementations. Four, hallucination and unverifiable claims: models fill in facts that do not exist using training priors and do not signal uncertainty, which is the most expensive failure class in medical, legal and financial contexts; the countermeasure is not to claim elimination but to render confidence grades explicitly (A confirmed / B contested / C vendor-claim / D needs-reproduction) on every conclusion, so a reader can tell which sentence was verified. Five, safety is coupled to capability: alignment training often comes with capability regression and vendors rarely report both numbers, so any claim of "safer" must be followed by "measured on which capability axis". Six, the data boundary: with no independent safety board wired in, water-level judgement in this domain rests on methodology and cross-domain readings, and none of it is given confirmed.
