What an AI agent is allowed to do is a design decision, not a setting

2 September 2026 4 min read Sam Goudbeek

AI security

The interesting question was never how clever the model is. It is what the thing can reach on a bad day, and who signed off on that.

What an AI agent may do is a design decision: you decide per source which data it may read, you make irreversible actions (sending, paying, deleting, changing records) wait for a person by default, and you keep a log of what it did. At Goudbeek in Almere those limits are written down before anything is built.

Most conversations about AI risk start at the model and stay there: is it accurate, does it hallucinate, which one is best this month. That is the part you have the least control over and the part that changes every few weeks.

The part you do control is the perimeter. Which documents it can open. Which systems it holds credentials for. What it can do without anyone watching. Those are not model properties. They are decisions somebody made, usually quickly, often by accident.

Access is not a system, it is a source

The common shortcut is to connect an agent to a whole system — the mailbox, the CRM, the drive — because that is what the integration offers. It is one checkbox, and it hands over everything in there.

The alternative takes a little longer up front: decide which sources the job actually needs and grant those. A chatbot answering delivery questions needs the delivery policy, the catalogue and order status. It does not need the drive that also holds payroll, and there is no version of the delivery question where it should.

Draw the line at consequence, not at capability

Reading, searching, summarising and drafting are recoverable. If the agent gets one wrong, you delete a draft.

Sending, paying, deleting, and changing a record are not recoverable in the same way. The useful split is not between simple and complex actions but between reversible and irreversible ones, and everything on the irreversible side should wait for a person until you have watched it long enough to move it.

The mistake is treating this as a maturity ladder to climb as fast as possible. Many systems can stay on the drafting side for good and still take a lot of routine work off a team.

If you cannot trace it, you cannot defend it

An answer built from your own material should be able to say which document and which passage it came from. Not because it reads well in a demo, but because the first time a customer disputes an answer you will want to open the source and look.

The same goes for actions. What was asked, what it read, what it did, who approved it. You will not look at that log for months and then you will need it in a hurry.

None of this is a feature you add later

Access boundaries and approval lines are load-bearing. Retrofitting them means rebuilding the system around them, which is why they belong in the first conversation rather than the last.

It is also a cheap part of the build. Deciding what a thing is not allowed to do is a short conversation. Discovering it afterwards costs considerably more.

That is why, for every AI agent we build, those limits are written down before anything runs: what it may see, what it may do, and what waits for a person. If an agent is already running, an AI security review goes through it against exactly these questions.

Frequently asked questions

What is an AI agent?

An AI agent is software that uses a language model to take steps in a piece of work on its own: reading a request, looking something up, drafting a reply or preparing an action. Unlike a plain chatbot, an agent can also act in other systems. That is exactly why it has to be settled up front which sources it may read and which actions it may take.

Which actions should wait for a person?

Every action you cannot undo should wait for a person: sending, paying, deleting and changing records. Reading, searching, summarising and drafting are reversible; if one goes wrong, you throw a draft away. Let an irreversible action run without a person only once you have watched it work long enough, and accept that for many systems that moment never needs to come.

Why not simply connect the whole system?

Connecting an AI agent to a whole system hands over everything in it with one checkbox, including what the job does not need. An agent answering delivery questions needs the delivery policy, the catalogue and order status, not the drive that also holds payroll. Granting access per source takes a little more work up front and limits what can be reached on a bad day.

What should an AI agent keep a record of?

An AI agent should record, for every action, what was asked, what it read, what it did and who approved it. For every answer built from your own material: which document and which passage it came from. You will not open that record for months, until a customer disputes an answer and you need to see the source in a hurry.

Can you add these limits later?

You can add limits to an AI agent later, but it is expensive. Access boundaries and approval lines are load-bearing, so adding them afterwards means rebuilding the system around them. That is why, for an AI agent, we write down before anything runs what it may see, what it may do and what waits for a person. That conversation is short; finding out afterwards costs more.