Control what an AI agent sees, not just what it is allowed to do

Dmitry Buykin of Maersk argued that permissions are not the main way to keep an AI agent safe. In his view, control starts with what the agent is shown. He made the case on the AI Engineer podcast, speaking about coding agents on a large production system.

What was said

Buykin said he once believed that controlling an agent meant limiting what it was allowed to do. He changed his mind. "Control starts with what the model sees," he said.

His example was simple. When his team let the model pick its own inputs, it pulled in all of the data. It then made up a pricing check, he said, since price data was in front of it. "Whatever sits in its context becomes a reason to act."

His fix was to let the runtime, the software that runs the agent, decide what the model gets. For his task, that meant only three details of the order. He said the model then goes wrong less often.

For large amounts of data, the model hands over a handle instead, a label for data the runtime keeps. The runtime verifies it before anything is written.

He added a second layer. Changes are checked twice: once while the code is built, and again when the write happens. A journal keeps a retried write from being applied twice.

Why it matters

Our reading: this widens Buykin's case. He spoke about an agent's own working context inside his team's codebase. We extend it to a wider question, what agents see when they are the audience for outside systems. He did not make that link in these excerpts.

Imagine a buyer weighing a vendor's agent product. The demo stresses which actions the agent may take. The sharper question is what the product shows the agent first. If it hands over a whole customer record, it could repeat the pricing check Buykin described: acting on data nobody meant it to use.

So ask who chooses what the agent sees, the model or the runtime.

The other side

Buykin conceded that even a well-informed model can cause harm, so he put checks on the write step as well.

He also described a cost no control covered. "All those controls protect the system. Nothing protected my attention." The volume of changes outgrew what one person could read, and he said he was burning out.

The excerpts leave gaps. Buykin gave no figure for how much a narrower context cut errors, and they do not show how a team decides which facts are enough. Treat this as one team's well-argued practice, not a measured result.