Treat Your AI Agent Like an Intern on Day One

My first real agent failure wasn’t an escape

I run agents every day, on my own projects: to process meeting transcripts when the platform already provides them, or my own handwritten notes when it doesn’t, to sort, to code, to summarize. So when the headlines started rolling in about models breaking out of their test environment and landing in some other company’s production, or a coding agent wiping a production database, I paid attention. But my first real outage had nothing to do with any of that.

A pipeline that turns those transcripts and notes into structured summaries died halfway through a batch. A full day of material sat there, unprocessed, and every light was green the whole time. The health check was testing that the program existed on disk, not that it actually started. A routine system update had broken it the night before. Nobody escaped from anywhere. We just lost a day because we were watching the config instead of the result.

That’s the real shape of risk in a company. Silent, ordinary, and invisible to the controls that are looking in the wrong place. The escape stories are dramatic. The thing that will actually cost you is boring.

Sandbox is necessary. It’s also the least interesting layer.

The reflex answer to agent incidents is “put your agents in a sandbox.” Fine. Do it. But understand what you bought.

In an organization that ships software, what determines an agent’s blast radius is not the strength of the container. It’s what you handed it when you plugged it in. The credentials. The pipeline access. The write permissions. The right to merge, to push, to publish. A vendor can sell you the box. Nobody can sell you the discipline around what goes in the box.

There are four layers here, and only one of them is mature:

1. Isolation. The sandbox. What the agent can reach.
2. Authorization before the action. What the agent is allowed to do, decided by code, not by a sentence in a prompt.
3. Monitoring. Are the expected results actually showing up.
4. Audit. Who did what, findable after the fact.

Vendors sell the first one because it wraps neatly into a product. The other three are organizational work, and that’s exactly where it breaks. The Gartner report telling everyone to sandbox their agents is quietly admitting that most companies don’t even have layer one. What nobody tells them is that layer one without the other three is a reinforced door on a house with no walls.

Treat an agent like an intern on day one

Here’s the rule I actually use. An agent is a new team member who showed up this morning and has no idea what’s dangerous yet. You wouldn’t hand that person your login and the key to the server room. Don’t hand it to the agent either.

For a development agent, point by point:

1. Its own account, with a name that says it’s an agent. The day a commit, a ticket, or an email goes out under your identity, you’ve lost traceability, and you’ll find out at the worst possible moment.
2. Read-only by default. Write opens up folder by folder, deliberately, never by default.
3. No production credentials in its context, ever. It doesn’t need them to do the work, any more than an intern needs the key to the server room.
4. An isolated working copy for every task. A throwaway branch, not your working tree. What it produces, you merge.
5. Three moves stay human, always: merge, push to a shared branch, publish to the outside. An agent can prepare all of it. It doesn’t get to pull the trigger.

A real example, transposed. I had several agents working in parallel on the same project, each in its own isolated copy. One of them, full of confidence, wrote an unconfirmed number into a permanent record because the number “looked like a decision.” Nothing dramatic happened, because the copy was throwaway and nothing leaves a copy without a review. Without the isolation, that number would have become company truth. That’s the whole game. Isolation isn’t there to stop a movie villain. It’s there to catch a confident mistake before it hardens into fact.

Watch the results, not the agent

This is the reversal that holds everything together. A green dashboard that says “the agent is contained” is worth nothing if nobody checks that what was supposed to come out actually came out.

The only monitoring that has ever caught a failure for me doesn’t look at logs and doesn’t look at config. It looks at deliverables. Did the nightly batch produce its output? Did the last article ship? How old is the last record the pipeline captured? If the answer crosses a threshold, it screams.

That’s a dead man’s switch. The absence of a result is the signal. An agent running “normally” and producing nothing is more dangerous than an agent that has visibly crashed, because nobody goes looking for the one that looks fine.

Instructions are not a policy

Everything you put in a prompt is a wish. I have a strict typographic rule I repeat in every single instruction I give an agent. They respect it nine times out of ten. The tenth slips through. The day I replaced the instruction with a deterministic checker that flat-out refuses the bad text, the problem disappeared.

Transpose that to enterprise development. “Don’t touch production” in a prompt is not a control. An account that has no write access to production is a control. Anything that isn’t deterministic isn’t a control. It’s a hope. And you don’t build governance on hope.

The case that changes everything: shared platforms

Now put several organizations on the same platform. That’s the world I work in as a delivery leader, and it’s where the neat little diagrams fall apart the moment agents show up.

When two organizations share a codebase, the question “which tenant would the AI assistant live in, and under whose license” stops being a procurement detail. The external developer you add to the repo, the agent attached to that developer, the pipeline that deploys to one org and to the other: each one needs its own identity, its own scope, and a clear answer to a question nobody wants to ask out loud. Who is accountable for code merged by an agent that belongs to the other organization?

I’ve seen that debate start, between people acting in good faith, with no written answer anywhere. You need one before the first commit, not after the first incident.

The spine of all of this

Strip away the tooling and it’s the same leadership model I’d apply to any team. A clear objective. Constraints everyone knows. Autonomy on the how. Accountability for the results.

An agent is a team member you owe exactly that, minus the sentimentality. The constraints are layers two, three, and four: authorization, monitoring, audit. The autonomy is the sandbox. If all you hand out is the autonomy, don’t act surprised by what comes out of it.