← All articles
Agent security • Field note

Attackers are not after your model. They want the gateway.

The interesting part of Microsoft's report is not the exploits. It is where they landed: the plumbing between your agents and everything those agents are allowed to reach.

David Soden • 6 min read • 28 August 2026
Two heavy steel vault doors set into an old brick wall
The gateway is the room where all the keys are kept. That is what makes it worth breaking into.

What happened

Microsoft Security published an investigation into intrusions into three AI enterprise workloads: a model gateway, a document-processing pipeline, and a workflow orchestrator. Different companies, different software, same instinct from the attacker.

Nobody went after the model. They went after the layer underneath it. In the gateway case, two public vulnerabilities gave them command execution inside the process, and once there they simply took what was already sitting in memory and on disk: API keys, database connection strings, service tokens. They fingerprinted the host, opened a hosted database to pull more key material, left SSH keys for later, and started a cryptominer on hardware somebody else was paying for.

The document pipeline was quieter and worse. The intruders installed a hook in the running application so that any credential an administrator typed into the model configuration screen was captured from that point on. No miner, no shell, nothing loud. Just a permanent tap on the place where staff enter secrets.

Why this matters to your business

Every AI deployment eventually grows a piece of software that sits between the agents and everything else. It routes requests, holds the model accounts, remembers which system each flow is allowed to touch, and keeps the credentials to do it. That is a useful thing to have. It is also, by design, the single object in your estate that holds every key at once.

So the blast radius is not "one server". It is every model account you can be billed on, every database that piece of software could reach, and every document store it was indexing. Two of the three victims here were also paying, in compute, for someone else's mining operation while it happened.

Now the part worth taking to whoever runs your infrastructure. The flaws used in these intrusions were public and already fixed. This was not clever. It worked because the software in question was installed by a project team, has been quietly routing production traffic ever since, and does not appear on anyone's patching schedule. Ask who owns upgrades for the thing your AI agents run through. If the answer takes longer than a sentence, you have found the problem.

Two grey bullet security cameras mounted on a concrete wall
Traffic from a compromised gateway looks like gateway traffic. Watching the outside of the box is not enough.

Why this is a CX-Builder use case

None of this is an argument against running AI infrastructure. It is an argument for knowing exactly where yours lives and what it can reach.

CX-Builder runs on your own hardware, inside your own network, which changes the question from "what can we see of the vendor's stack" to "what have we allowed our own box to do". Credentials live in the platform's own store and attach to individual nodes, so a returns flow carries the token for the order system and nothing else. A compromise of one flow is not a compromise of every account you have.

Be honest about the trade, though. Self-hosting does not make the patching problem go away, it makes it yours. What you get is the ability to put the thing behind your own network policy, restrict what it is allowed to call out to, and see its behaviour with the tooling you already run. What you owe in return is an upgrade cadence somebody actually owns.

An engineer connecting network cables at the back of a server rack
Self-hosted means the patch schedule is yours. That is the cost of the control.

What this looks like if you build it

Practically, it is a handful of choices made once. Deploy into a network segment with an egress allowlist, so the container can reach your model endpoints and the systems your flows need, and nothing else. Scope each credential to one connector rather than issuing one account with rights to everything. Put an approval step in front of any flow that writes to a customer record, so an unexpected action needs a person before it lands.

Then treat it like production software, because it is. Pin the version, watch the release notes, and schedule upgrades instead of doing them when something breaks. Keep an eye on what the box calls out to; a machine that suddenly starts talking to an address nobody recognises is the earliest signal you will get.

The takeaway

This week, name the software that sits between your AI agents and your production systems, and name the person who patches it. Then list the credentials it holds and ask whether any single flow needs all of them. Most of the damage in these cases came from one process holding every key, and that is a decision you can reverse in an afternoon.

All articles Install CX-Builder View on GitHub