Why an AI agent shouldn't get prod access on day one
An agent that decides and acts on its own sounds like a dream. Until it deletes the wrong row in a client's database.
The first agent I shipped to production ran fine for three weeks. In week four it got an email titled "URGENT: cancel all orders" — and dutifully started cancelling. The email was from a spammer. Since then I have a rule: no agent touches production until it has served its probation.
The problem isn't the model, it's the permissions
When something breaks, the first instinct is "the model is dumb." It almost never is. The model did exactly what it was allowed to do: it held a write-scoped key and it used it. The question isn't "how do I make the model smarter," it's "why did it have that key at all."
An AI agent isn't a coworker you can tell "you know better than that." It's a process with a set of tools. Give it DELETE and sooner or later it will call DELETE.
How I actually roll agents out
- Read-only first. The agent sees data, proposes an action, a human executes it. Boring — but you see where it's wrong with zero blast radius.
- Then sandbox writes. A separate copy of the database. Let it break things there all it wants.
- Then writes behind confirmation. The agent prepares an action, a human clicks "yes." This stage lasts weeks, not hours.
- Only then autonomous writes — and even then with limits: no more than N ops per minute, never touch tables on the stop-list.
The most dangerous word in a brief is "fully." "The agent fully automates refunds" almost always means "nobody thought about malicious input."
Least privilege isn't paranoia
In security this is day-one stuff: give a process exactly the access its task needs and not a drop more. With agents people somehow forget — they hand over an admin service account because "it's faster." Faster until the first incident.
// Bad: one key for everything
const db = connect(ADMIN_URL);
// Better: a dedicated role per tool
const readOrders = connect(RO_URL); // SELECT only
const writeTickets = connect(TICKETS_RW_URL); // INSERT/UPDATE on one table
// the agent physically can't delete an order — there's no such toolNotice: this isn't about a prompt saying "please don't delete orders." A prompt is a request. Permissions are a wall. The agent can hallucinate all it likes — if the tool has no DELETE, nothing gets deleted.
A good agent isn't one you trust. It's one that can't do harm even when it's wrong.
So when someone asks "can we put an autonomous agent straight into production?" — sure. In a couple of weeks, once I've seen the logs and know where it trips. Those two weeks are cheaper than one call with a client whose orders vanished.
Want this in your own project?
Let's look at your process and where it's safe to automate.