Chapter 0.6 — Deterministic control vs probabilistic mitigation

🎯 Chapter objective

Establish one of the central ideas of this book: controls and mitigations are not the same thing.

🧠 Core concept

Category	Nature	Example	What does it guarantee?
Deterministic control	Executable code	Schema validation, RBAC, policy-as-code	Predictable behavior
Executable policy	Policy-as-code	OPA/Rego, Cedar	Predictable behavior
Authorization	Identity service	OAuth, OIDC, IAM	Predictable behavior
Validation	Schema, contract test	Pydantic, JSON Schema	Form, not content
Observability	Tracing, metrics	OpenTelemetry, logs	Investigation capability
Mitigation	Reduces probability	Input sanitization	Reduces risk, doesn't eliminate it
Heuristic	Approximate rule	Prompt injection detector	Reduces risk, doesn't eliminate it
Prompt	Natural-language instruction	"Do not run dangerous commands"	Guarantees nothing
Guardrail	Heuristic layer	Output classifier	Reduces risk, doesn't eliminate it
Residual risk	What remains	Always exists	Accepted or transferred

The practical rule:

For critical risks, prefer deterministic control. Use mitigation as defense in depth, never as the only mechanism.

🚨 Failure modes

• Treating a guardrail as a guarantee.
• Treating a prompt as a policy.
• Treating metadata as enforcement.
• Treating a tool description as security.

🛡️ Mitigations

These three anti-patterns deserve their own chapters and are revisited in Part 3 and Part 4:

• 🔐 "A prompt is not a policy" — Ch. 3.x and 4.x.
• 🔧 "A tool description is not security" — Ch. 3.x and 4.x.
• 🗑️ "Deprecation is not just metadata" — Ch. 7.x.

📌 Checklist

• [ ] Is every critical rule in code?
• [ ] Is there an explicit distinction between control and mitigation in the documentation?
• [ ] Is residual risk documented and formally accepted?

---