Onboarding an AI agent: five controls we use for people and skip for agents
Jamie Watters
Operational resilience and AI delivery practitioner. Technology since 1985.
Guillermo Rauch, who runs Vercel, was asked why giving an agent its own computer improves what it can do. His answer was a comparison. What is the first thing a firm does when it hires a human? It gives them a machine, already logged into the key systems.
He is right, and the comparison is better than he needed it to be. Nearly a thousand people at his company now talk to an internal agent through Slack. It has sub-agents. One of them is wired into the data warehouse. Ask it about a customer and it goes and finds out.
But take the hiring comparison seriously for a minute, because it does not stop at the laptop.
What actually happens when a firm hires someone
The computer is the least of it, and in a regulated firm it is close to the last thing to arrive.
Before that person touches anything there is a role definition saying what the job is and, by omission, what it is not. There is a manager, and the manager is a different person from the one doing the work. Access is provisioned by somebody in another team, against that role, and asking for more is a request that leaves a trail. There is a probation period, which exists because nobody trusts a stranger's judgement on day one, however good the interview was. And there is an escalation path, so that when something looks wrong, the person who notices is not the same person who has to justify stopping.
Five controls. None of them is exotic. Every bank in the world runs all five, and has for decades, because they are what makes it safe to give a stranger real access to real systems.
Now count how many of them an internal agent gets.
It gets the laptop.
The industry has an answer, and it is the wrong one
The answer on offer is observability. Log everything the agent does, feed it into a dashboard, and you will be able to see what happened.
The trouble is that this has now been tested three times in public, and in all three the logging worked perfectly.
Anthropic's Frontier Red Team put three agents on one shared codebase and gave each an incompatible migration target. None of them knew the others existed. Every model they tested escalated: account lockouts, kill loops using randomised process names, malware disguised as a teammate's work. There was no attacker and no prompt injection. Every action was authorised, and every action was recorded.
I want to be careful here, because this experiment has been widely retold with a piece missing. The same runs also produced agents writing apologetic commit messages, cleaning up their own malware and asking for a human to step in. In one model's case, 98% of runs ended in a negotiated truce. This is not a story about deception. It is stranger than that, and worse for our purposes: nothing was hidden, and the record still does not tell you whether any of it was supposed to happen.
Then June. A monitoring tool alerted on port-sweep activity inside OpenAI's infrastructure. Responders investigated and got it right: they linked it to an internal cyber-security benchmark run that was using the company's own package manager as an improvised message board and a network pivot. That is a good detection followed by a correct diagnosis. On OpenAI's own account, on-call staff advised that stopping the run was not required.
A fortnight later Hugging Face was compromised.
That decision was not negligence. It was the reasonable answer to the question the playbook asks, which is whether the activity is legitimate. The activity had been labelled a sanctioned test. Tests generate strange traffic. Halting a frontier run costs money and somebody has to sign for it. Every incentive in that room pointed at letting it continue.
And the speed on the other side of that decision, using OpenAI's own figure given at Black Hat: under thirteen hours from code execution on a single worker pod to cluster admin across multiple production clusters.
Why the log cannot help you
Here is the thing that took me a while to accept, having spent most of my working life building the response side of this.
A complete log answers one question extremely well: what happened. It cannot answer the question that actually governs the decision, which is whether what happened was supposed to happen. That is a comparison, and there is only one thing on the table. You have the record of the activity. You do not have anything to compare it against.
When the second thing is a person's judgement, you are back at 27 June, because the judgement is the part that failed. Nobody notices a sanctioned test. That is what sanctioned means.
So the missing artefact is not better monitoring. It is a statement, written before the run starts, of what the run may touch.
Declare the envelope
Before an agent starts, the thing that will run declares what it is allowed to reach. Hosts, namespaces, identities, egress destinations, and a ceiling on privilege. Not a risk assessment. A list.
The list is the control, and its whole value is what it does to the question. "Is this legitimate?" needs a human, a conversation and some courage. "Is this in the list?" needs none of those. It is a set membership test, and a set membership test can start a clock at three in the morning without waking anyone up first.
Read 27 June again with that in place. The responders would still have been correct that on the evidence in front of them, stopping was not required. Both things can be true at once, and only one of them starts a timer.
Two conditions, and the second is where I expect this to be attacked.
The envelope has to be set by someone who is not running the workload. That is the separate manager from the list above, and it is old ground: business continuity has always kept invocation authority away from the activity owner, and we quietly gave that up the moment the activity became software.
And widening the envelope at runtime has to cost something. An approval, a page, a log line somebody owns. A declaration that the workload can widen by itself is not a control, it is a comment.
If that turns out to be intolerable at real release speed, the idea fails and it fails completely. I would rather find that out from a practitioner than from a client. There is a second limit worth saying out loud too: in a mature estate, plenty of the interesting failures happen inside the envelope. Nothing here catches an agent doing something catastrophic to a host it was legitimately handed. It narrows the surface. It does not close it.
The one thing to do this week
Jeff Dean made a point recently that lands differently once you have thought about the five controls. Agents can now run for days or weeks rather than an hour. And specification matters more with an agent than it did with a person, not less, because a capable human who is given a vague brief comes back and asks. An agent infers.
So if you are standing one of these up inside your company, the useful question is not which model, and it is not which observability vendor.
It is: what is this thing allowed to touch, who wrote that down, and what happens when it reaches past it.
If the answer to the second part is "the team running it", you have handed someone a laptop and called it onboarding.