The AI should never do what you can't

I once watched a demo where a chatbot deleted a record with one sentence. No confirm box. No second look. The room clapped. I did not clap. I wanted to know who would have to explain that to the person whose record it was.

That is the part most copilot demos skip. They show you the AI doing something fast. They do not show you what stops it from doing something wrong. When I built an AI copilot for a goal tracking tool, I set one rule before I wrote a line of code: the AI never gets a door that the person using it does not also have.

Why give an AI its own door

It is tempting to build a shortcut for the AI. Write one function that goes straight to the data, skip the checks the screens already have, and ship it fast. I get why teams do this. It feels quicker.

But a shortcut like that gives you two ways into your data: the slow, checked way through the screens, and the fast, unchecked way through the AI. Every time you add a new rule about who can see or change what, you have to remember to add it in both places. Most teams remember the first one and forget the second.

So I did not build a second path. Every action the copilot can take runs through the exact same backend function the buttons already call. One gate, not two. When I fix a rule, I fix it once, and the screens and the AI both pick it up at the same time.

Checked twice: at offer time and at call time

The check happens in two places, and each one catches a different mistake.

The first check runs before the model even sees a list of things it could do. If you cannot edit a budget yourself, the tool for editing a budget never shows up in the model's list of options. It cannot ask to do something it was never told it could do.

The second check runs when a tool is actually called. Even if a tool somehow showed up by mistake, the backend checks permissions again before anything happens, using the same rule the screen uses. If that check fails, the model gets told no in plain words, the same way it would get any other answer. The chat keeps going. Nothing breaks.

Two checks is more work than one. It is worth it because the first check only proves what the model can see, and the second proves what it can actually do, and those are not the same promise.

Every write is a proposal, not an action

Here is the part that surprised the first people who tried it. The copilot never just does something to your data. Ask it to update a goal or change a status, and it builds a card showing exactly what will change. You read it. You say yes or you say no.

That card gets checked by the same shape of data as the form you would fill in by hand. So the AI cannot sneak through a change the manual form would have rejected. One set of rules covers both paths.

This slows the AI down by one click. That click is the point. A person who sees the change before it lands can catch a mistake that a person who only sees the result cannot.

Deletes need you to type it out

A button gets clicked without anyone reading what it says. Everyone has done this at least once. So for anything that deletes data, a button is not enough. You have to type out a word to confirm it, the same way some tools make you type a project name before they let you remove it.

This has nothing to do with trusting the AI less than a person. It is about the fact that a delete usually cannot be undone, and undo is the safety net most software actually has. A click can be a reflex. A typed word cannot.

Sub agents that can only look, not touch

Not every job the copilot does needs write access. Looking things up, asking a clarifying question, drafting a paragraph, working through a bit of analysis: none of that needs to touch your data at all. So those jobs go to smaller helper agents that can only read.

This keeps the damage small if something goes wrong. A helper that only writes a summary cannot also be tricked, by some clever wording in a prompt, into sneaking in a write it was never given. It simply does not hold that tool.

What this caught before launch

I built a test that compares what the AI is allowed to offer against what a person with the same role is allowed to click. The two lists should always match exactly. The first time I ran it, it found two real authorization bugs.

That is the real payoff of building it this way. The rules around the AI did not just make the AI safer.

Writing them honestly forced me to check the rest of the system too, and that check found something a shortcut would have hidden.

What this cost me

I will not pretend this was free. Two checks instead of one means more code, and more tests for that code. A shared shape of data across the form, the backend and the AI tool takes longer to set up than three separate ones would have. Every new feature means touching three places that all expect the same shape, and getting one of them wrong shows up as a bug that takes longer to track down.

I would still build it this way again. That work just does not stop once a feature ships.