What is the right permission model for an agent with read-docs, run-SQL, and Slack-send tools?

MCQ·Medium·4.0 · 0·~1 min·Relevant atAnthropic

Attempt it

An agent with read-docs, run-SQL, and Slack-send is dangerous if you set up permissions naively. The wrong move is to give it one master credential that covers everything, because anything that goes wrong (model confusion, prompt injection, a buggy step) immediately reaches every tool at once. The right model has three layers. First, **each tool gets its own scoped credential**. The doc tool gets a read-only token for public spaces. The SQL tool gets a database role with SELECT only, no DELETE or UPDATE. The Slack tool gets a bot token tied to one specific channel, not direct messages or company-wide broadcast. Second, irreversible or high-impact actions go through a human approval gate. Posting to Slack reaches many humans at once, so you might pause for confirmation before fan-out. Anything that mutates production data definitely pauses. Third, the mental model is a junior employee, not a service account. You do not hand a new hire the keys to everything on day one. You give them the access the current job needs and add more as trust is earned. The other options fail in predictable ways. A shared admin token concentrates risk. A strict prompt cannot stop an injection. Loose dev access leaks to production every time.

The right model is **least privilege per tool with a scoped credential boundary**, plus a human gate on irreversible or broadcasting actions. Concretely: the SQL tool gets a read-only database role that physically cannot DELETE or UPDATE. The Slack tool gets a bot-only token restricted to specific non-DM channels. The doc-read tool is scoped to public spaces only. None of these credentials share authority with any other, so a successful prompt injection can only weaponise the one tool it touches, not the union of everything. Irreversible actions (sending a Slack message that fans out to a channel, mutating prod data if you ever add that tool) route through HITL approval. Reversible reads do not need a gate. This puts friction where the stakes justify it and nowhere else. The other options each fail a specific way. A shared admin token means one compromised call inherits everything. A careful system prompt is not a security boundary, because the model reads attacker-influenceable text. Loose dev access tightened later is the classic prototype to production drift that produces the next incident. The mental model is a junior employee, not a service account. You scope grants per task, you log every action, and you never give the agent privilege it does not currently need.

Quick reference

TL;DR

Per-tool scoped credentials, never a shared admin token, with human approval on irreversible or broadcasting actions. The credential bounds damage, not the prompt.

Memory aid

Easy to grasp

Imagine an intern on day one. You do not hand them the master key to the office, the company credit card, and the all hands email account at the same time. You hand them a key to the supply closet for the supply task, a read-only badge for the records task, and you ask before they email the whole company. An agent is the same. You decide what it can do by what you hand it, not by hoping it will be careful. Read tools get a read-only key. Database tools get a key that cannot delete anything. Slack tools get a key for one channel, not all of them. The big, scary, hard to undo actions are gated behind a human checking first.

Key concepts

Least Privilege Tool Permissions Human in the Loop

Detailed answer & concept explanation

~7 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.

Quick scan · 2–4 min

Everything important, quickly.

Lead with the framing that the credential is the security boundary, not the prompt. Map each of the three tools to a specific scoped credential. Explain why Slack-send earns a human gate and SELECT-only does not. Cover audit logs, egress allowlists, and short-lived rotated credentials as additional layers. Close on the junior-employee versus service-account mental model.

Real-world examples

Real products, models, and research that use this idea.

Anthropic's Claude computer use and Claude Code both ship with restricted execution environments and gate destructive actions behind explicit user confirmation rather than trusting the model to refuse.
Model Context Protocol servers expose tools with declared scopes, so a host can register only the specific MCP tools a task needs and revoke the rest between requests.
GitHub Copilot agent mode scopes shell and file-write tools to the active workspace and surfaces diffs or command approvals before any irreversible edit lands.
Production deployments at AWS and GCP commonly use IAM roles per Lambda or per service so an agent action runs under a scoped role rather than a shared admin key.

Interviewer follow-ups

What an interviewer would ask next. Try answering before peeking at the approach.

QSuppose the agent legitimately needs to write to the database for some tasks. How do you scope that without giving it always-on write authority?

QAn injection succeeds and tells the agent to email a customer list to an external address. With the perimeter you described, what stops it?

QHow would you decide between dynamic per-task tool registration and a static minimal tool set declared at agent start?

Don't say this

Red flags and common mistakes that signal junior thinking. Click to expand.

Most common mistake

Using one shared admin token across tools so a single injected call inherits the full authority of every tool the agent holds.

60-second cheat sheet

The night-before-the-interview bullets. Scan these on the way to the call.

References

Primary sources. Skim if you want the original framing.