Here’s an uncomfortable sentence to say out loud in a security review: our platform executes code that a language model wrote.
That’s not a bug report. It’s the product. An agent-native data platform lets agents build extraction scripts, generate transformations, and wire up pipelines, and then it runs what they built. That’s the whole point. But it means the threat model is different from a traditional data platform, where every line of code that touches production was written by an employee and reviewed by another one. Some of the code running in your deployment was written by a model, on a Tuesday, in response to a prompt.
I spent a long time in institutions where the question “who wrote this and who approved it” had to have an answer. So when I say the code might have been written by a model, I don’t say it casually. I say it because pretending otherwise is how you end up trusting things you shouldn’t. The honest posture is simpler: treat generated code the way you’d treat code from a stranger. Assume it might do something dumb, or something clever, and build the walls before it gets the chance.
The sandbox nobody has to turn on
For a while, the extraction scripts on my platform could run in an isolated sandbox if you flipped a switch. Almost nobody flips switches. The people who most need isolation are the ones who installed the platform in ten minutes, pointed an agent at it, and moved on with their day. If the default install isn’t isolated, the platform isn’t isolated. Whatever the docs say.
So now the sandbox is the default. Extraction code runs in its own container with no credentials in it. Not masked credentials, not scoped credentials. None. It has no network route to the platform’s databases, its object store, or its secret vault. The filesystem it sees is read-only except for scratch space that evaporates when the run ends. It doesn’t run as root, and the Linux capabilities a process could use to escalate are dropped before the script starts.
What can it do? It can fetch data from the source it was written for, and it can hand records back across an authenticated channel. That’s the job. A script that wants to poke around the platform’s internals finds there are no internals to poke. There’s nothing to steal in the box, and no road out of it.
The part I care about most is what this does to the trust question. I don’t have to audit every generated script for hostile behavior, and neither do you, because the interesting question is no longer “would this code misbehave” but “could it accomplish anything if it did.” Reviewing model output for subtle malice is a losing game. Making malice pointless is a winnable one.
Fail loudly, not politely
There’s a related habit I’ve been trying to kill: the quiet insecure fallback. A platform that silently accepts a plaintext connection to a database across the network is making a security decision on your behalf and not telling you.
So in production mode, the platform now refuses to start if its own database connection crosses the network unencrypted. Not a warning buried in a log file at line forty thousand. A refusal, at startup, with a message that says exactly what’s wrong. If you have a genuine reason to run plaintext, maybe a private network you trust, you can say so explicitly, and then it’s your decision on the record instead of a default nobody chose.
Failing at startup feels rude. It’s the opposite. The polite version, where everything comes up green and the encryption you assumed was there isn’t, is how deployments run exposed for two years before anyone notices. Rude and early beats polite and discovered-later, every time.
Let the security team watch
Any platform that runs agent-generated code should expect a security team to ask what it’s doing in there, and it should have a better answer than “ssh in and grep.”
The platform now exposes metrics that Prometheus can scrape, kept inside the deployment’s network rather than hung off the public edge. Production deployments emit structured JSON logs, one event per line, ready for whatever SIEM or log aggregator your organization already runs. This is table stakes for ordinary infrastructure, and agent infrastructure doesn’t get a pass because it’s new. If anything the bar is higher. When some of your code is generated, observability isn’t a nice-to-have; it’s how a human stays in the loop after the demo ends.
Know what’s in the box
Self-hosting means the supply chain is your problem, and mine. The container images are now pinned by digest, so the image you pull is the image that was built and scanned, not whatever a mutable tag happens to point at this week. And every release ships a software bill of materials for each image, so when the next big CVE lands you can answer “are we exposed?” by searching a file instead of by archaeology.
None of this is glamorous. It’s also exactly the thing a security reviewer checks first, and open source doesn’t exempt you from the question. It just means you get to answer it in public.
The constraint that made it interesting
The easy version of all this adds a Kubernetes requirement, a service mesh, and a page of prerequisites, and then wonders why nobody deploys it. The constraint I refused to give up is that the quick start stays a compose file and ten minutes. Sandboxing is another container in the same compose stack. Encryption enforcement is a startup check. The metrics endpoint is already inside the network you deployed. Secure-by-default only works if “default” still describes the thing people actually install.
Agents are going to write and run more of the code in data infrastructure, not less. I think that’s good; it’s why I built this platform. But the vendors asking you to run agent-generated code owe you more than a demo. They owe you walls. Ask where the generated code runs, what credentials sit inside that boundary, and what happens when the code does something nobody prompted. If the answer leans on the model behaving well, keep asking.
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.