{"slug": "why-ai-writes-need-risk-tiers-the-r0-r5-tool-risk-model", "title": "Why AI Writes Need Risk Tiers: The R0-R5 Tool Risk Model", "summary": "A developer has proposed a six-level tool risk tiering model (R0–R5) that assigns every AI agent operation a risk level and maps it to an execution policy, from automatic reads to blocked irreversible actions. The model is implemented in the open-source KeelBase project, where tools declare their tier via a riskLevel field surfaced through an MCP endpoint, and a runtime chain enforces permission checks, policy gates, human confirmation, and audit logging. The project's protocol conformance suite reports 34/34 tests passing, including rejection of tier escalation and confirmation bypass.", "body_md": "The previous piece, \"Runtime over Prompt\", argued that the security boundary belongs on the execution path — immediately before a tool call can produce a side effect.\n\nThis one goes a level deeper. Once the boundary sits on the execution path, the runtime has to answer a question it can't dodge: **should this tool be allowed to run at all?**\n\nAnd the operations enterprises actually hesitate over are rarely reads. Querying a customer is fine. Updating one? Emailing one? Deleting one?\n\nWhen an AI gets a read wrong, it \"saw it wrong\" — you fix it and move on. The blast radius is small.\n\nWhen an AI gets a write wrong, it \"broke it\" — a wrong order amount, an overwritten customer record, an email sent to the wrong person. Much of it is **irreversible or expensive to undo**.\n\nSo there's a gap between \"let it look\" and \"let it act\", and the gap is really this: **should every operation be governed by the same policy?**\n\nObviously not. Querying can be automatic. Changing a contract needs a human. Deleting data shouldn't be allowed at all.\n\nThat's what tool risk tiering is for: **give every AI operation a risk level, then let the level decide the execution policy** — instead of a blanket \"all automatic\" or \"all human-reviewed\".\n\nSix levels, low to high, each mapping to one execution policy:\n\n| Tier | Meaning | Example | Execution policy | \n|---|---|---|---|\n| R0 | Informational | Explanations, summary stats | Automatic | \n| R1 | Read | List customers | Automatic | \n| R2 | Low-risk write | Update a note | Policy decides (governance-configurable) | \n| R3 | Business-sensitive write | Create a follow-up task, change an order | **Human confirmation** | \n| R4 | High-impact action | Operations needing dual approval | **Dual approval** | \n| R5 | Irreversible / external action | Delete data, send email | **Blocked** | \n\nThree design decisions worth calling out:\n\nThe point of the tiering: it turns \"do we dare let the AI do this\" from a feeling into a rule. Nobody has to judge tool by tool; they set policy by tier.\n\nA tiering is paper until the runtime enforces it. The chain:\n\n**Tool declares its tier (R0-R5) → permission check (row-level scope: own / org) → policy gate (R5 blocked / R3-R4 confirmed / R0-R2 automatic) → human confirmation (executes only on approval) → write executes → side effect recorded (revocable) + audit chained**\n\nUsing the open-source KeelBase implementation as the example, the chain is verifiable.\n\nRepository: [https://github.com/rain6fish/KeelBase](https://github.com/rain6fish/KeelBase)\n\n`riskLevel`, and the MCP endpoint surfaces it in the tool declaration (`_meta.keelbase`) — visible to external clients before they call anything.` isError=true` plus the reason list. Tamper-evident and traceable.\nThe protocol conformance suite pins these semantics. Output from `Server-NestJS/scripts/verify-protocol-conformance.mjs`:\n\n```\n─ Tool risk tiers (protocol §4) ─\n  ✓ RISK_STRATEGY table matches the vectors\n  ✓ R1 (read) → auto / no confirmation\n  ✓ R3 (business-sensitive write) → confirmation\n  ✓ R4 (high-impact) → human_approval\n  ✓ R5 (irreversible/external) → block\n  ✓ Derivation: undeclared write tool → R3 confirmation\n  ✓ Derivation: undeclared read tool → R1 auto\n\n═══ Conformance: 34/34 passed (0s) ═══\n```\n\nTampering, tier escalation, and confirmation bypass all get rejected here.\n\nAI writing data isn't the problem. **Tiering it, confirming it, and being able to trace it** is what makes it shippable. Turn \"do we dare let the AI act\" into a rule you can execute, and it can move from assistant to doing real work.\n\nIf you're building agents, three questions worth asking about your own system:\n\nThe third is the one that matters. If the answer is \"the model refused\", the boundary is still in the prompt, not on the execution path.\n\nIf you find a way to bypass a tiering rule or a gate, open an issue — I'm more interested in the failure cases than the successes.", "url": "https://wpnews.pro/news/why-ai-writes-need-risk-tiers-the-r0-r5-tool-risk-model", "canonical_source": "https://dev.to/rain6fish/why-ai-writes-need-risk-tiers-the-r0-r5-tool-risk-model-105k", "published_at": "2026-09-20 00:25:28+00:00", "updated_at": "2026-09-20 00:54:34.028389+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "agent-protocols", "ai-tools", "developer-tools"], "entities": ["KeelBase", "MCP", "rain6fish", "GitHub"], "alternates": {"html": "https://wpnews.pro/news/why-ai-writes-need-risk-tiers-the-r0-r5-tool-risk-model", "markdown": "https://wpnews.pro/news/why-ai-writes-need-risk-tiers-the-r0-r5-tool-risk-model.md", "text": "https://wpnews.pro/news/why-ai-writes-need-risk-tiers-the-r0-r5-tool-risk-model.txt", "jsonld": "https://wpnews.pro/news/why-ai-writes-need-risk-tiers-the-r0-r5-tool-risk-model.jsonld"}}