A Tool That Can Delete Prod: Designing Safe Destructive Tools

July 24, 2026 · Claude Certified Architect (CCA) Prep (part 19)

▶ Watch on YouTube & subscribe to The Stack Underflow

Somewhere in your tool registry there is a function that, if called with the wrong arguments, does something you cannot undo — drop a table, delete a customer record, cancel a production deployment. The model that decides to call it is a language model, not a change-control board. It has no innate sense of blast radius. It picks tools the same way it picks the next word: by pattern-matching a description against a task. If that tool fires the way any other tool fires, your safety net is “the model probably won’t mess up” — and probably is not a security control.

The one-sentence version: A destructive tool needs the smallest scope that can do the job, plus a permission or human-approval gate in front of the irreversible step — trusting the model’s judgment is not a control, it’s an absence of one.

The question

This is Domain 2 — Tool Design & MCP Integration (18% of the exam) — practice question 6 of 10.

A tool can permanently delete production records. How do you expose it safely?

• A) Trust the model
• B) Least privilege + a permission/human-approval gate on the destructive action
• C) Hide it in the description
• D) Give it to every agent

Pause here and pick an answer before you keep scrolling.

The answer

The correct answer is B: least privilege + a permission or human-approval gate on the destructive action.

Two mechanisms are doing the work here, and the question is testing whether you know both are required — not either/or.

Least privilege means the credential the tool executes with can only do the destructive thing it was built for, at the smallest scope that satisfies the use case. A delete_record tool should hold a token scoped to delete rows in one table, not an admin key that happens to also be able to delete records as a side effect of broader access. If the token leaks, gets misused by a hallucinated call, or gets chained into an unexpected multi-step plan, the ceiling on the damage is fixed by the scope of the credential — not by hoping the model behaves.

A permission or human-approval gate means the irreversible action does not execute the instant the model decides to call it. Something outside the model’s own reasoning — a confirmation step, a human-in-the-loop approval, a policy engine — has to clear the call before it fires. This is the same idea as a production deploy needing a second approver: the person (or system) proposing the action is not the same authority that authorizes it.

                     ┌───────────────────────────────────┐
                     │      TRUST BOUNDARY (dashed)       │
                     │                                     │
   MODEL decides  ───┼──▶  delete_prod_record(id=42)      │
   to call the       │              │                      │
   destructive tool   │              ▼                      │
                     │   ┌─────────────────────────┐      │
                     │   │  PERMISSION / HUMAN GATE  │      │
                     │   │  "Confirm: delete row 42  │      │
                     │   │   from orders (prod)?"    │      │
                     │   └───────────┬───────────────┘      │
                     │               │ approved              │
                     │               ▼                       │
                     │   ┌─────────────────────────┐      │
                     │   │ LEAST-PRIVILEGE TOKEN     │      │
                     │   │ scope: delete on          │      │
                     │   │ `orders` table only       │      │
                     │   └───────────┬───────────────┘      │
                     └───────────────┼───────────────────────┘
                                     ▼
                        DELETE executes, audit-logged

Two failure paths this closes: (1) the model calls the tool with a wrong or attacker-influenced argument — the gate catches it before execution, not after; (2) the credential itself gets extracted or reused elsewhere — least privilege caps what that credential can do even outside the intended flow. Neither control alone is sufficient. A gate in front of an over-privileged credential still lets one bad approval nuke more than intended. A tightly scoped credential with no gate still lets a model-driven mistake execute instantly, no second look. You need both.

Why the other options fail

• A) Trust the model. Model judgment is probabilistic pattern completion, not policy enforcement. It has no way to be “held accountable” for a bad call, and a sufficiently unusual prompt, injected instruction, or edge-case argument can push it into calling the tool when it shouldn’t. Trusting the model is the default state of not having a control — it’s what happens before you design one, not a design choice.
• C) Hide it in the description. Making a tool’s description vague or omitting details does not make the model less likely to call it — if anything it makes correct usage less likely, since (as covered elsewhere in this series) the description is the only spec the model ever sees. Obscurity is not a permission system; the tool is either reachable and callable, or it isn’t. A vague description just adds a second failure mode — wrong calls — on top of the first.
• D) Give it to every agent. Broad distribution of a destructive capability multiplies the number of contexts in which a mistake, a prompt injection, or a bad multi-agent handoff can trigger it. Every additional agent that holds the tool is another attack surface and another place a scoping mistake can happen. Destructive tools should be scoped to the fewest agents that actually need them, which is the opposite of this option.

The concept behind it

This question sits at the intersection of two ideas that generalize well beyond “delete records.”

Reversibility is the variable that should drive tool design, not tool frequency. Most tool-safety intuition defaults to “make the common tools easy to call and the rare tools hard to call” — but that’s the wrong axis. A tool that’s called constantly and fully reversible (read a record, search a doc) can be low-friction. A tool that’s called rarely but irreversible (delete a record, send a wire transfer, revoke access) needs friction regardless of how often it fires, because the cost of one wrong call is unbounded relative to the cost of a confirmation prompt.

“Human-in-the-loop” is not one pattern — it’s a spectrum. A synchronous confirmation (“are you sure? y/n”) is the simplest form, but it doesn’t scale to high-volume or async workflows. Other points on the spectrum: a policy engine that auto-approves low-risk deletes (single row, soft-delete, non-prod) and escalates high-risk ones (bulk delete, production, no backup) to a human; a time-delayed execution window that lets a human veto before the action commits; or a two-key pattern where the model proposes and a separate, non-model system authorizes. The exam-relevant takeaway is not “always show a confirmation dialog” — it’s “the authority to execute an irreversible action must not rest solely with the same process that decided to attempt it.”

This is also why least privilege and gating are complementary rather than redundant. Least privilege is a static control — it bounds the damage of every call, gated or not, forever, without needing anyone to be paying attention. A gate is a dynamic control — it catches the specific call, in the moment, but only if someone or something is actually watching. Production security postures layer static and dynamic controls precisely because each covers the other’s blind spot: static controls fail open if the scope was set too broadly at design time; dynamic controls fail open if the approver rubber-stamps or the process has no approver configured. A tool that can delete production data needs both, not a choice between them.

FAQ

Does every destructive tool need a human in the loop, or can a policy engine approve automatically? A policy engine can approve automatically for well-bounded cases — a single soft-delete on a non-production record, for instance — as long as the policy itself was written and reviewed by a human, and the scope of what it can auto-approve is narrow and auditable. The requirement is that some authority outside the calling model’s own reasoning makes the final call. That authority can be a human clicking approve, or a deterministic policy engine enforcing explicit rules — it cannot be the same model deciding to call the tool.

Isn’t a permission gate just extra latency the user has to wait through? For low-risk, easily reversible actions, yes, and that’s exactly why you shouldn’t gate those. Gates belong on the subset of tools where the cost of a wrong call outweighs the cost of a pause. Reserve the friction for the calls where friction is cheap relative to what it prevents.

What’s the difference between least privilege here and least privilege in traditional application security? Same principle, new attacker model. In traditional security, you scope credentials against a human or service account that might be compromised. Here, you’re additionally scoping against a model that might be manipulated through its inputs — a prompt injection in a document the agent reads, for example — into calling a tool it has legitimate access to, with arguments it shouldn’t have chosen. The credential scope has to survive both a compromised caller and a manipulated but “legitimate” caller.

Where does this fit with tool error handling — does a blocked destructive call need a structured error too? Yes. When a gate denies a call, the tool should return a structured, non-throwing response the agent can reason about (denied, pending-approval, escalated) rather than crash the run — the same error-contract discipline covered in Your Tool Returns a 500 — Then What? applies whether the failure came from an upstream API or from your own permission layer.

Where this fits in the CCA series

This is question 6 of 10 in the Domain 2 practice set on tool design and MCP integration. If you haven’t already, start with the MCP explained on one diagram piece for the protocol fundamentals this domain builds on.

Related D2 questions in this set: Why Does Claude Pick the Wrong Tool? on selection failures, Your Tool Returns a 500 — Then What? on the error-contract pattern referenced above, and Same Tool, Three Agents: Inline Tool or MCP Server? on the reuse-vs-inline trade-off that also decides where a destructive tool’s gate and credential should live.

Not affiliated with, authorized, or endorsed by Anthropic. “Claude” and “Claude Certified Architect” are trademarks of Anthropic. These are original practice questions for study, not real exam content — verify current exam details on Anthropic’s official pages.

Browse the full tutorial catalog for the rest of the CCA prep series and the exam-logistics basics — Pearson VUE, $125, retakes, 60 questions in 120 minutes, a pass mark of 720/1000 across five domains — as of mid-2026.