Your AI Agent Is a New Hire

I keep watching people give AI agents broad permissions and hope for the best. Someone hands the agent an API token, a deploy key, write access to a production cluster, whatever it needs to actually do work. Then they're surprised when the agent confidently does something destructive that no human reviewer would have approved. The agent did exactly what it was asked. Nothing scoped what it was asked to.

I think about agents the way I think about a new hire with no judgment and infinite confidence. A new hire on day one doesn't get production access. They get a sandbox, a code review process, and someone watching what they merge. Not because anyone thinks they're malicious. Because confidence isn't competence, and the cost of letting them learn in production is too high. The difference is that a new hire eventually develops a sense for when something feels off, and the agent never does.

So the same boring permission scoping that has been right about humans for forty years is the first thing I apply. An agent that needs to read logs gets exactly that, scoped to its own namespace, with no write access and nothing it could use to reach further into the system. Most of the cleanup work I've seen on agent permissions is undoing over-grants that happened in the first week, when nobody knew what the agent would actually need so they gave it everything. By the time the agent does something it shouldn't, the permission is buried in a config file nobody is paying attention to.

Then there's the question of what the agent does autonomously versus what it confirms first. I make that call at the system level, not in the prompt. Reversible, low-blast-radius operations the agent handles on its own, while anything large or irreversible requires explicit confirmation before it executes, ideally with a dry-run preview that shows exactly what would change. A model that can't tell the difference between deleting one file and deleting a database is the model I don't want negotiating its own permissions in the moment.

Even when the agent is allowed to act, I have it touch one thing first, check the result, and only proceed if the canary holds. People skip this step because they picture the agent running once and stopping, the way a script does. But an agent works through a sequence of actions on live systems and keeps going on its own judgment, which is what a human running a deployment does. So it gets the same staged rollout I'd give any human-driven change, and the circuit breaker that would page a person gets wired to halt the agent automatically, because the agent will not know to stop on its own.

What I see missed most is that the rules about what the agent can do should be policy, not prompt. Prompts are advice. Policy is law. If the rule is "never delete production data," that belongs in a policy engine that physically blocks the call, not in the system prompt that tells the agent to be careful. I've seen too many attempts to constrain agents with stern instructions in natural language. It works most of the time. Most of the time isn't good enough when the failure mode is data loss.

None of these mechanics are new. The only new thing is that people forget to apply them because the agent doesn't look like a process. It looks like a clever tool. But once an AI agent has API access and the authority to change real state, it is a process with the judgment of a new hire and the speed of an automated job. The model speaks with the same certainty whether it's about to do the right thing or wreck the weekend, and that certainty tells me nothing. I don't trust the output. I trust the system around the output.