agent trust is a runtime problem

There is a sentence the industry keeps trying very hard to believe:

"We can make agents safe with better instructions."

I understand why. Instructions are cheap. Policies are familiar. A system prompt feels like a place where serious adults can write serious words like "never" and "must" and "only with approval." Then the agent reads a README from the internet, installs a package, opens a browser, calls an MCP server, touches a repository, and suddenly the serious words are trying to govern a live workflow with the authority of a sticky note.

This is why Docker's recent AI Engineer World's Fair write-up caught my attention. The headline is about agent trust, but the useful part is less dramatic: harden what agents build on, isolate where they run, control what they can reach, and govern the whole thing from one place.

That is platform engineering wearing a new jacket and pretending it just arrived.

Good. We have spent the last decade learning that useful software needs boring boundaries. Containers needed image policy, network policy, registries, scanners, signed artifacts, secrets management, and audit logs.

Agents deserve the same disrespect.

the agent does not need to be evil

The easy security story is that an agent might run a destructive command.

That is real, but it is also the cartoon version.

The more common risk is quieter. The agent reads too much. It connects dots that were never meant to be connected. It copies context from a private repository into a public tool call. It installs a dependency that opens a new network path. It calls an unreviewed MCP server because the server description sounded helpful and the afternoon was already long.

No villain required.

This is the annoying thing about useful agents: usefulness comes from access. A coding agent that cannot read files, run tests, inspect errors, install dependencies, call documentation tools, use a browser, or open a pull request is basically autocomplete with confidence issues.

So the question is not "should agents have access?"

The question is "where is that access mediated?"

If the answer is "in the prompt", we are being optimistic in the same way a team is optimistic when production credentials live in a wiki page titled "please rotate this soon."

prompts shape intent, runtimes enforce reality

Prompts matter. I am not joining the club of people who pretend instructions are useless because that sounds sophisticated. A clear instruction can improve behavior. A good system prompt can define task scope, escalation rules, and expectations.

But prompts shape probabilities.

Runtimes enforce boundaries.

That difference matters.

A prompt can say "do not access the network except for documentation." A runtime can actually block network destinations that are not allowed. A prompt can say "do not write outside the repository." A sandbox can mount the repository read-write and everything else read-only or not at all. A prompt can say "only use approved tools." A gateway can reject unapproved MCP calls before they happen.

This is why runtime governance research feels directionally right. One recent paper argues that agent behavior is path-dependent: the risk depends not only on one action, but on the sequence of actions that led there. Static access control catches some cases. Prompt rules catch some behavior. But once an agent is acting through tools, the execution path itself becomes the thing you need to observe and govern.

That sounds academic until you watch a real agent work.

It reads an issue. Searches the repo. Opens docs. Installs a package. Runs a test. Follows an error to a blog post. Copies an example. Edits code. Runs another command. Tries a browser route. Opens a PR.

Each step might be defensible alone.

The sequence might be a problem.

mcp made the tool layer everybody's problem

The Model Context Protocol is useful because it gives agents a common way to call tools. It is also dangerous for exactly the same reason.

Once tool access becomes portable, tool governance becomes unavoidable.

An MCP server is not just a plugin. It can be a route into databases, ticket systems, cloud APIs, internal docs, messaging tools, browsers, build systems, and customer-shaped data. If developers can add these servers faster than security or platform teams can review them, congratulations, you have reinvented browser extensions with production credentials.

Docker's governance page talks about central control for sandbox, network, and MCP access, with policy events exported to SIEM and compliance systems. The product details will change, and other vendors will build their own versions, but the shape is what matters.

Agent tooling needs an allowlist. It needs ownership. It needs review. It needs audit. It needs default-deny for things that can touch sensitive systems.

Not because developers are irresponsible.

Because serious tools need serious boundaries.

the laptop is not outside the platform

One subtle point in the Docker argument is that a lot of agent work starts on the developer laptop.

That sounds obvious, but many enterprise security conversations still behave as if the real platform begins in CI or the cloud. The laptop is treated as a messy prelude. The official system starts later, after the pull request, after the build, after the deployment pipeline wakes up and puts on a badge.

Agents make that mental model weaker.

If an agent can read a repository, run local tools, call network services, use a browser, and interact with MCP servers before code ever reaches CI, then the developer machine is already an execution environment for semi-autonomous work.

It means the agent runtime on the laptop belongs in the platform inventory.

Which agents are allowed? Which sandboxes do they use? Which directories can they mount? Which network paths can they reach? Which MCP servers are approved? Which credentials can enter the session? What gets logged? What is retained? What can a reviewer see after the agent opens a pull request?

These are not exotic AI questions.

They are old platform questions with a faster actor.

autonomy without evidence is just vibes at scale

The best version of agent autonomy is not "the agent did something and we hope it was fine."

The best version is "the agent did something inside a bounded runtime, using approved tools, with visible inputs and outputs, and left behind enough evidence for a human to review the work."

That evidence should not only be the code diff.

The diff tells you what changed. It does not tell you whether the agent read files it should not have read, called an unapproved tool, installed a sketchy package, copied from a questionable source, or hit a network endpoint nobody expected.

For agent-generated work, the provenance around the work starts to matter more.

Where did it run? What image or environment was used? What tools were available? Which commands executed? Which domains were reached? Which files were mounted? Which secrets were exposed? Which policy checks passed? Which ones warned? Which ones blocked?

We already learned this lesson in supply chain security. The artifact is not enough. You eventually want to know what built it, from which inputs, under which policy, with which attestations.

Agents are now part of that build story.

the punchline

Agent trust will not come from one magic layer.

Better models help. Better prompts help. Better reviews help. But the durable trust boundary is going to live in the runtime and the tool path: sandboxes, network controls, filesystem mounts, MCP governance, credential scoping, audit events, and reviewable evidence.

This is not the glamorous side of AI.

Good.

The glamorous side is where demos live. The boring side is where production survives.

The practical rule is simple: if an agent can act like a developer, operate it like a developer environment. Give it useful access, but make that access explicit. Let it move fast, but inside a boundary. Let it call tools, but only the tools the organization is willing to defend.

Do not ask the prompt to do the runtime's job.

The prompt can say "be careful."

The runtime can make careful the default.

That is where trust starts to become real.

references

• Docker Blog: AI Engineer World's Fair 2026: The Runtime Is Where Agent Trust Is Won
• Docker AI Governance
• arXiv: Runtime Governance for AI Agents: Policies on Paths
• arXiv: AgentTrust: Runtime Safety Evaluation and Interception for AI Agent Tool Use

To test my projects, I use Railway. If you want $20 USD to get started, use this link.