An agent at Nate Herk’s AI automation agency emailed a discount code to about 150,000 people. Nobody told it to. A task was sitting on the team’s to-do list, the agent read it as “write and send a discount code to the whole list”, and it had a tool that could send. So it sent. The lesson he took from it: whatever your agent has access to, assume it will use.
01The email nobody asked for
The uncomfortable part of that story is that the agent was following instructions, as it understood them, with tools it was given. These models are non-deterministic: run the same setup a hundred times and the runs differ, and a model swap changes how the whole system reads its instructions. So any action the tools allow can still happen one day, even if you have never seen it in testing.
That is why the fix was never a sterner prompt.
“a rule that lives in the prompt is just a suggestion”
Nate Herk, “5000 Hours of Building AI in Just 17 Minutes” · 8:1502Put the rule in the tools
A rule can live in two places, and they fail differently:
- In the prompt. “Never send emails, only write drafts.” The model complies on most runs. It lowers the odds of a send; it guarantees nothing, because compliance is one more thing the model decides per run.
- In the tools. The agent has no send capability at all. Sending is impossible, no matter what any run decides the instructions mean.
Defend your agent from prompt injection gives the same advice for a different reason: if an attacker hijacks your agent, narrow tools limit the damage. Herk’s story shows you need the limit even with no attacker anywhere. One odd reading of a to-do item is enough.
03Scope the keys
An API key is the password an agent uses to log into a service. Most services let you issue keys with limited permissions, so the key itself can only perform certain operations: a key that creates drafts but cannot send, a key that reads records but cannot write them. Scoping the key moves the rule out of text the model might misread and into what the service itself allows.
Herk’s test for whether an agent’s access is sane is a hiring question:
“would you ever hand a new hire a credit card and say, hey, don't use this”
Nate Herk, “5000 Hours of Building AI in Just 17 Minutes” · 8:36The card works. The purchases would go through. Only trust stops them, and a system that can act differently on every run has not earned that trust. Storage follows the same rule: an agent that only looks things up in a database or knowledge base gets a read-only connection, so no run can change what is stored there. Give your agent a memory scopes its stores this way.
04Ask what it can do on its own
Walk the full list of what the agent can touch: every tool, every database, every file, every key. For each one, name the worst single action its current access allows, and assume that action happens eventually. Automate the step that slows you down asks whether your worker has the logins the task requires; this audit is the other half: check that it has no access beyond that.
If you are not the one building the system, the audit compresses to one question for whoever is: “What can this thing actually do on its own? Can it send, or can it only draft?” When the answer scares you, change the access. The prompt can keep its rules as guidance; the tools are what make the guarantee.
Further reading
- Nate Herk · 5000 Hours of Building AI in Just 17 Minutes, the source this guide draws on
- Anthropic · Tool use overview, where an agent’s capabilities are actually defined