Give an agent a task that needs data it doesn’t have, and it writes the code to go get it. This isn’t a connector you pulled off a shelf or a data feed a teammate checked in last year. The agent wrote it from your prompt and ran it against a live source a few minutes later, then wrote another one for the next task. Here’s what’s new: the code didn’t exist until you asked, and nobody read it before it ran.
So here’s the real question, and it has nothing to do with whether the code is correct. Where does it run?
In-process means the platform is the blast radius
On most setups it runs in the same process as the engine, which means it sees the same filesystem and network and inherits the same environment the engine has. Your database password is sitting right there in the environment. The object store is a hostname away. Need the secrets service? It answers on the internal network, no questions asked. Code that was supposed to hit one API and hand back some rows is now loose inside your infrastructure with every key you own.
And it doesn’t take malice to go wrong. Maybe a dependency it pulled in has a bad day, or the parser chokes on something a source you don’t control fed back. Doesn’t matter which one. Whatever breaks, breaks with the run of the whole process, and that process can reach everything. So you’re putting your database and your secrets behind code nobody audited, and you’re doing it several times a day.
A container with nothing inside
The fix is boring. Don’t run the code where your secrets live. Give it a separate container with nothing in it but the job.
Start with the image. It should carry no credentials and no keys of any kind, nothing baked in and nothing mounted at runtime. Let the feed dig through the whole container if it wants. There’s nothing in there worth taking.
The network is where you really shut it down. The runner gets the public internet and your platform’s own API, and that’s the entire list. The database, and everything else worth protecting, sits on a network the runner can’t see. A feed can go hunting for postgres:5432 until it gives up, and there’s just no route to it.
Then lock the container itself down. Run it as a non-root user, make the root filesystem read-only, drop every Linux capability, and block privilege escalation. The only writable space is a small in-memory scratch area, wiped after each run, so nothing a feed leaves behind survives into the next one.
If you won’t go that far, at least keep the platform’s secrets out of the feed’s environment and install its packages into a throwaway environment you discard after the run. That costs nothing, and it shuts the two doors a feed most often uses to reach past its job.
Be honest about the boundary
One caveat, because overselling security is worse than saying nothing. A separate container still shares the host kernel. That’s operating-system isolation, and it’s the right boundary when you self-host code you chose to run. It is not a virtual machine, and a kernel-level escape would cross it. If you’re running truly untrusted code from strangers, OS isolation is only your floor. Reach for gVisor or a microVM. A normal container usually drops into either one with no rewrite. Match the boundary to the threat you actually have.
The point
You can review the ones you have time for, and pin the dependencies, and hope the model wrote something sane. None of it scales, because the agent writes feeds faster than anyone can read them. So take trust off the table. Run the code where it can do its job and reach nothing else, and a feed that goes wrong returns no records and touches nothing.
The code you didn’t audit is already running. The one thing still in your hands is where it runs. A separate container is the difference between a misbehaving feed costing you a retry and costing you everything. Decide it on purpose.
Todd Fearn is the founder of Datris.ai, an open-source, agent-native data platform built on the Model Context Protocol, and he runs IData Corporation, a data engineering consultancy for financial services firms. He has spent about thirty years building production data infrastructure inside institutions like Goldman Sachs, Bridgewater Associates, Deutsche Bank, and Freddie Mac.