Per-tool scoped credentials, never a shared admin token, with human approval on irreversible or broadcasting actions. The credential bounds damage, not the prompt.
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.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
An agent with three tools, read-docs, run-SQL, and Slack-send, is a useful concrete scenario because it spans the full risk spectrum in a single design. The doc tool is purely informational and reversible. The SQL tool can be benign reads or destructive writes depending on how the database role is configured. The Slack tool fans out to many humans at once, so even a single message has broadcast blast radius. The right permission model has to handle all three correctly with a single coherent framework.
The correct answer is least privilege per tool with a scoped credential boundary, plus a human gate on irreversible or broadcasting actions, treating the agent like a junior employee rather than a service account. This answer is structurally different from the three distractors, and the depth comes from explaining why each layer is necessary and what it specifically prevents.
The rest of this explanation walks the three layers in detail, dismantles the distractors, names the production controls that sit underneath the answer, and closes on the junior-employee framing that holds the whole picture together.
Layer one: a scoped credential per tool
The single highest-leverage move is to give each tool its own narrowly scoped credential. SQL runs under a database role that has SELECT on specific tables and nothing else. DELETE and UPDATE are not just discouraged at the application layer; they are revoked at the database. The Slack tool uses a bot identity restricted to a channel allowlist with no DM scope and no admin scope. The doc tool reads from an index that filters out private spaces at the index layer, not at the prompt layer.
The reason this matters is that a prompt injection inherits the authority of whatever credential the call runs under. If the SQL tool's credential cannot DELETE, then no injection can persuade it to. The model never sees the credential and cannot upgrade it by clever reasoning. This is the architectural property that makes credentials a real boundary, unlike system-prompt instructions which the model reads as suggestions.
The contrast with the shared-admin-token option is sharp. With one master credential, every tool call inherits the full authority of every other tool. An injection that triggers a SQL call can DELETE because the credential has DELETE, even if SQL was supposed to be read-only at the application level. The application-level restriction is a fence the model can be tricked into walking around. The database-level restriction is a wall it cannot.
A secondary benefit is blast containment when something goes wrong outside an attack. A buggy tool wrapper that accidentally constructs a destructive query still fails harmlessly under a read-only role. The credential becomes a safety net for honest mistakes, not just adversarial ones.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
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.
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?
Classify writes by reversibility and blast radius. Reversible writes with a row-level constraint can be in scope. Irreversible writes route through a human approval. Use dynamic tool registration so the write tool only loads for tasks that declared they need it, and use a scoped credential capped by row count or table allowlist.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Using one shared admin token across tools so a single injected call inherits the full authority of every tool the agent holds.
60 second bullets to scan on the way to the call.
Explain why per-tool credentials beat a single shared admin token.
Map each of read-docs, run-SQL, and Slack-send to a specific scope.
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.