When finding vulnerabilities gets cheap, where your software runs matters

Picture a bank’s security team pointing an off-the-shelf autonomous agent at its own internal developer environment and asking it to find weaknesses. It reads the dependency manifests. It checks each package against public advisories and issue trackers. It ranks what it finds, writes test code for the promising candidates and drafts notes a junior penetration tester could follow. It does all of that in an afternoon, for the price of some inference.

Nobody gets hacked in that story. The point is the economics. Work that used to need a skilled researcher and days of tooling now runs as a background task. Agents haven’t necessarily become brilliant security researchers. Probing has simply become cheap enough to do continuously, everywhere, without a person in the loop until something turns up.

For anyone shipping software, and especially anyone shipping a lot of AI-written software, that changes how much the shape of your stack matters.

The weight you didn’t choose

A typical agent deployment carries a surprising amount of code nobody on the team chose deliberately. A framework pulls in dozens of direct dependencies, each with its own tree. Add a database driver, an observability SDK, a storage client, a serialisation library, a session store, a hosted monitoring service and CI runners that execute generated code in shared environments. By the time the demo works you’ve imported hundreds of packages you’ve never read, written by people you’ve never met.

That’s not a complaint about open source, which I rely on like everyone else. It’s an observation about what attack surface means when the attacker is an agent that can read manifests, search vulnerability databases, write a proof of concept and try again, all in one session. And the more distinctive your dependency tree, the more precisely that agent can aim.

AI coding makes this worse in a quiet way. Agents add dependencies freely, because a package is usually the fastest route to a passing test. Unless something pushes back, the tree grows with every change.

Regulators are moving in the same direction. Software bill of materials requirements are already part of US federal procurement following the 2021 Executive Order on improving the nation’s cybersecurity (source: NIST SBOM guidance, 2021), and the EU Cyber Resilience Act (European Parliament, adopted 2024) brings similar expectations. You’ll increasingly be asked to show what’s in your software. A stack that can’t answer cleanly is a compliance problem as well as a security one.

Patch time is the number that matters

When a weakness turns up in something you depend on, a clock starts. The maintainer has to fix it and release. You have to notice, update, test and redeploy. If probing is cheap, the gap between a public advisory and someone scanning for it shrinks, and the part of the clock you control matters more than ever.

That’s why I care less about whether a stack can be attacked, because everything can, and more about two questions. How much surface is there? And how quickly can you find out about a problem and fix it yourself?

A smaller surface helps directly. Fewer packages, fewer versions, fewer exposed interfaces, less for an automated prober to work through. Owning the critical path helps too, because when the fix is yours to make you’re not waiting on someone else’s release schedule.

Isolation sets the size of the blast

You’ll never get the surface to zero, so the next question is what happens when something does get through.

If every service shares credentials, network access and storage, a compromised dependency in one place is a foothold everywhere. If each piece of software runs isolated, with only the access it was given for its job, a compromise stays small. It can’t wander into its neighbours or reach things it was never meant to see, and rolling back to a known-good state is quick.

Then there’s attribution. In a lot of agent stacks, everything acts through one shared service account. If a compromised package writes somewhere it shouldn’t, the record shows the service account, and you’re left doing archaeology across several logs that don’t agree on a timeline. When every agent and every deployed component has its own identity and its actions are recorded in one place, incident response becomes a question you can answer.

What to ask of anywhere you run AI-built software

If you’re choosing where AI-built software will run, supply-chain security deserves a place in the main questions rather than an appendix. These are the ones I’d ask.

• Can you produce a complete, machine-readable SBOM (CycloneDX or SPDX) for what’s actually deployed, today, without someone assembling it by hand?
• For a given action, can you tell which agent or component did it, rather than a shared service account?
• If a dependency is compromised, what can it reach? Show me the boundary.
• When a fix is needed in the platform itself, whose release schedule are we waiting on?
• Can it run fully isolated from outside networks if we need it to, and what stops working when it does?

A good test is a tabletop exercise. Assume a dependency has been compromised and work through how long it takes to establish what was affected, to produce a timeline of what happened, and to show a supervisor it’s contained. The answers vary enormously between setups. For high-risk systems, the EU AI Act also expects this kind of documented risk assessment (source: EU AI Act, Article 9, EUR-Lex), so the exercise earns its keep twice.

The trade-off, honestly

A smaller, more owned stack isn’t free. You give up some of the flexibility of swapping components in and out. You’re also trusting the team that built and maintains the owned parts, rather than the wider community that reads popular open-source code. Both are real costs and I don’t want to wave them away.

For software that touches regulated data, I still think the balance favours less surface, strong isolation and fast patching under your own control. The cost of an incident in that setting, in remediation, regulatory attention and lost trust, is high enough that a more defensible place to run is easy to justify. I’m less sure where the line falls for a small internal tool, and I suspect the honest answer there is “it depends what it can reach.”

This is the problem Voxeltron is for. It’s where software built with AI gets deployed, isolated, secured and kept running, on infrastructure you choose. We’re still building it and our pilot programme is open, so I’ll leave the detail for a conversation.

If supply-chain risk is on your list this year, we’d like to hear from you. For the wider case on everything around the code, see AI writes the first 20%. Shipping is the other 80%.