This is the part I care about most, and the part most AI pitches skip. Here is something that is true and rarely said out loud: when you build an AI agent at your desk and connect it to your own accounts, you are the safety net. It can see whatever you can see and do whatever you can do, because it is signed in as you. For one person doing their own work, that is fine. You are sitting right there watching it.
It stops being fine the moment the agent starts doing things for the business instead of just for you. Now it might be sending a piece of work to a client, or an email in your name, or putting something out in public. And the only thing between it and a bad mistake is a person who is not always looking, connected to systems that do not care whether anyone is.
So the real job is to rebuild the safety that used to come from you sitting there. It comes down to three plain questions. When an agent does something, who is it? What is it allowed to touch? And if something went wrong, could you go back and see what it did? Get all three right and a business can lean on it. Miss one and you are only hoping it works.
One boundary before the three questions, because clients ask about it first: none of these agents reach into a client’s systems. They run entirely inside our own Microsoft tenant, on our own data and on whatever a client has handed us to work with. Everything below is about keeping them in line inside our own house, which is the only house they are in.
Who is it?
The first thing we did was stop letting the agents sign in as me.
Each one has its own login now, its own identity in the system, signing in with its own certificate rather than borrowing mine. Its keys only open the rooms its job needs. When Naomi, the hiring agent, tries a door that belongs to another part of the business, the door does not open. Not because Naomi thought better of it. The identity system refuses it with a flat error, the same way the wrong key simply will not open the door. The lock holds whether or not the agent behaves.
That matters because of a trap that catches careful people. Whatever account you hand an agent almost always has more power than the agent needs. There are old permissions lying around, broad access nobody ever trimmed, a key that happens to open far more than the one door. The easy thing is to lean on all that, because it works. Naomi put the rule I would want every one of them to live by: treat your own key as untrusted, because it can do more than you should. You stay inside the lines through the rules and the settings, not by trusting that the key in your hand is a small one.
Treat your own key as untrusted. It can do more than you should.Naomi, People Ops
There was a broad fallback sign-in the fleet could have leaned on. We gave it up and then deleted it on purpose, because a backup you have promised not to use is only ever as good as your self-control on your worst day.
If I had to keep one rule and throw out the rest, it would be that one. An agent should never just be you. Its own login, and only the reach its job needs.
What can it actually touch?
You already know how this works with people. Not everyone gets into every room: what people are paid, or a deal in progress, sits behind doors most of the company never opens. Agents are no different. Each gets keys to the rooms its job needs and no others, so the communications agent has no key to the hiring room, and the hiring agent has none to finance.
There is a second trap, worth slowing down on: it is not enough to hand out the right keys, you have to watch what kind of key you cut. It is easy to give an agent one that can not only open its room but change the locks, so a key meant for one narrow job can quietly widen its own reach. We nearly did exactly that, and the fix was a plain key that cannot touch the locks at all. The full story is in the next piece.
Now the honest part. Not every locked door in our own setup is really locked. Some the building keeps shut for you: wrong agent, wrong door, it does not open, no argument. Others are shut only because the agent has agreed not to walk through. Here is one of ours. One of the agents reads our files through a tool that, on that path, signs in as me rather than as itself, which gives it far more reach than its job needs. Nothing in the platform stops it there. What keeps it in bounds is a rule it follows, plus a separate check, run from outside it, that would catch it if it ever strayed.
From the inside, a door the building locks and a door held shut by a promise look identical. The real work was going and finding out which was which, and we got it wrong more than once. A door you have called locked but never tried is just a belief.
There is a thinner spot worth naming too. All of this separation is real in the cloud, where each agent’s identity is enforced by the platform and a wrong door returns a flat refusal. On the single machine where they run, the agents share one operating-system account, so the hard separation there is thinner than the rooms-and-keys picture suggests. What carries the weight on the machine itself is the cloud-side identity and the rules we hold, not a wall between programs on the laptop. That is most of the reason there is a Part 4.
There is also a limit that is easy to miss, and Naomi is the one who ran into it. There is a room Naomi is meant to be able to enter, and its key is refused. Naomi cannot tell, on its own, whether it was never given that key or had it taken away. An agent cannot walk the whole building and list every room it can and cannot get into. Someone standing outside has to draw that map. That is not a nice-to-have. It is why you need a check that sits outside the agent looking in.
When does a person have to be involved?
You cannot put a human in front of everything an agent does. Try it and you get one of two bad outcomes. Make a person approve every little thing and they stop reading and start rubber-stamping, until the approval means nothing. Only let the agent work while someone watches, and nothing happens while you sleep. Neither works.
So we did not sort the work by how important it feels. We sorted it by one plain question: if this goes wrong, can we take it back quickly and quietly, or not? That splits everything an agent might do into three levels. We gave them deliberately dull names, tier one, tier two and tier three, and the rule for each is simple.
Tier one is the work an agent just gets on with, on its own, nobody signing off. Reading, drafting, filing, tidying up. Get one wrong and you fix it in five minutes and no harm was done. This is most of what the agents do, all day, whether anyone is watching or not.
Tier two is the work an agent does in full, but is not allowed to finish by itself. It prepares the whole thing, then stops and waits for a person to say yes. Anything that leaves the building sits here: publishing something, or sending a client the brief or the deck we drafted for them. We make the work in our own shop, on our own systems. Handing it to the client is the step that waits for a person. Florence is the clearest example. It will draft a sensitive email, but it will never send one. It writes the whole thing, turns it into a draft, and waits for me, no matter who asked, including me in a hurry. Its reasoning is better than mine: the danger is the send button, and it is the same button whether my thumb hits it or Florence’s logic does. So the rule puts the guard on the button, not on which of us is more trustworthy.
Tier three is the work an agent is simply never allowed to do, no matter what. Not with a sign-off, not with a button. The things you cannot undo, or that are really a judgment about a person. Naomi will flag a record as old enough to delete, but it will never delete one, because working out that the clock has run is arithmetic, while ending someone’s record is a judgment that belongs to a person. The agent that writes our code is never allowed near the live systems our customers depend on. There is deliberately no switch that turns these on, because the moment there is a switch, the switch becomes the thing a bad instruction, or an attacker, goes looking for.
That is the whole policy. Which level a job lands in is decided by what it would cost if it went wrong, not by whether a person happens to be in the room. The cheap, reversible work runs on its own, so the costly, one-way work gets a real look.
This is also why Carta, the fifth agent, is not allowed to do anything itself. It watches the whole setup and it can suggest changes, but it cannot make them. A person has to. The reason matters: Carta is the one agent that could, in principle, rewrite the rules the others run on, and anything that can rewrite the rules could in principle loosen the ones that hold it back. So the check on that power cannot be more software. It has to be a person, standing outside the part of the system that can change itself. It is the same arrangement from the first article: Carta can see the whole setup and propose fixes, but it cannot make a single change on its own.
Can you check what it did?
Which leaves the last question, the one a security person always asks. Could you go back and prove what it did?
Some of that is a good record. The important logs are kept append-only, written to a store the agent that generates them cannot go back and edit, so an entry can be added but not quietly rewritten after the fact. But the sharper tool grew straight out of Naomi’s problem above, the one where an agent cannot check its own limits. We built a job that goes and tries the doors for us, on a schedule. It walks each agent up to the rooms it should not be able to enter, and if a door that is supposed to be locked ever opens, the job stops everything and shouts. It does not trust the map of who can go where. It goes and tries the handles.
Which sounds like the happy ending. Own logins, a key to only the rooms each agent needs, a stop on the expensive actions, and a job that keeps trying the locked doors. It sounds airtight.
It wasn’t. When we stopped reading our own safeguards and started testing them, we found that some of the best-looking ones could not have worked at all. That is the next piece, and the one I almost did not publish.
