Enterprises should run local agents on hardware they own, keep data in the building, and treat write access as the thing to guard. That is how you own your weights.
Three groups
Go ask ten different people, in person, to simply define AI. I bet you get ten different answers.
There is a knowledge gap at the foundation. Not an IQ gap. To me, this gap creates three groups of people.
The first is a small group focused on compounding the benefits of their knowledge: maximizing tokens per second, hoarding compute, building until their hands fall off.
The second, much larger group, talks about AI but has never known it as anything more than a new app. These are the people who use ChatGPT to replace Google search and call that “using AI.”
The third, and I wonder if this is actually the largest, is everyone who does not know how to use it or does not want to. They hear all the talk, never touch it unless a company’s customer service forces them to, and that one experience forms their entire understanding of what AI is. When, really, that was a Twitter bot with a budget. Bad customer service, not intelligence.
The problem is that these groups are not being reconciled in any meaningful way while the Fortune 500 spends a trillion dollars deploying agents at scale. I saw this firsthand at the Agent Conference in Manhattan in May 2026. Group 1 is building through the night and spending every spare dollar on another GPU. They do not want anyone else to learn, because the moat is the point. Even the ethical ones will not stop to write and teach, because stopping halts their progress and, in their own minds, weakens the moat. The pace already feels like time travel and sleep is getting in the way. Group 2 incorrectly thinks it is Group 1, which is exactly what Group 1 prefers, and exactly why Group 2 stays Group 2. Group 3 thinks all of them are stupid. You can see how this gap widens without real change.
I think we are at the stage where Group 1 has the burden of proof, the responsibility, to dissolve the idea of groups for general entry knowledge. For an enterprise to reap the greatest benefit from its deployments, that gap has to close. If the knowledge were so hard that only two people on Earth could hold it, maybe that would be a different story. That is not the case. You do not have to build models from scratch to join Group 1. You do have to understand what you are running and where it runs.
How did we get here? Intentionally watered down “courses.” No real introductory workshops from the people who actually build, only open-mouth YouTube thumbnails. Posers posting content that confuses the real people trying to learn. An insane pace of software and hardware progress. And a lot of deliberate fear mongering, used to gatekeep future competition and to squeeze a few more sales of recently dead software out of unknowing clients. The hot potato strategy.
So of course people are in the dark. No one is dumb for not being familiar with new things.
But the goal of this paper is to show that you do not have to stay in the dark about AI, or about agents inside your enterprise. More than that: a wise enterprise would use this information to build locally, with agents across its workflow, actually doing things, safely.
This will seem silly, but think of how Batman was afraid of bats and conquered that fear by turning the thing he feared into his own tool. Using local agents safely to level up your business is a lot less intimidating than answering the bat signal. The fear of the thing and the thing itself are usually very different. So why are we afraid of local AI before we understand it?
Understand, too, that the giant boards and organizations selling you AI have, with few exceptions, an incentive to keep you in a haze about what it is, how it works, and where to build next. Because if you understood even their incentives, their hardware bottlenecks, and their software moats, you would adjust your business today to own as much of your own data as possible and pay them less for compute. So let’s clear the haze.
Read and write
If I am going to explain why it is bad to put company data on a cloud even for reads, let alone writes, I have to explain the difference first.
Read means the agent can observe: query, fetch, list, watch, reason. Write means the agent can change state: create, modify, delete, send, spend.
An agent that reads an inbox, a ticket queue, or a shared doc can be instructed by the contents of what it reads. That is prompt injection. If that same agent also holds write credentials, then whoever can get text in front of it holds those credentials too. That is why reads and writes should live in different processes with different keys.
Writes are where you hand the agent real company trust to go execute based on what it read. This is the danger zone for anyone in Group 2 or Group 3, or anyone in Group 1 who got lazy, rolling out agents across a company. Giving anything read access to your data deserves care on its own. Write functions that are not sandboxed, or not stripped of PII, are a different category of risk. One execution and a codebase is wiped, contacts erased, chains gone, access revoked, client data leaked, money lost. That is what happens when you do not nail writes. Really think about that. And it is far too easy to do without proper care, because we are talking about one-click third-party connections inside cloud workspaces.
Now flip it. Deploy agents on VRAM you own. Build the software that feeds the agent its loops from your own API on a cron job. Host your own database. Run the write function inside hardware and a harness you control, with a privacy router that decides what the agent is allowed to touch. You not only nail the write function, you do it in a way your competition literally cannot match unless they adopt the same strategy. The difference in who reaps the benefit comes down to who executes on knowledge that already exists. The tricky part is that this knowledge is almost foreign unless you are in there playing with the GitHub alphas.
Someone else’s computer
When you hear “cloud,” think: someone else’s computer.
A cloud model sends your data over the internet to a provider’s servers. Whatever the privacy page says, that data is now subject to the provider’s policies, the provider’s logs, and the provider’s subpoenas. It is stored and studied, and depending on the terms you clicked through, trained on. A frontier API is a walled garden. They bring you in, then cap what you can build at scale because they set the limits. They have all the control and you have none. Latency is higher, because of how they queue requests inside their network, and this bothers me like nothing else. Cost scales per token, which is how engineers end up with six-figure token bills. You are paying for someone else’s compute while also handing them your data. People get rinsed dry and then defend the people doing it to them. This is Group 2’s entire relationship with AI: an app, a login, and a terms page nobody read.
Allowing Google, Anthropic, or worse, OpenAI, to hold extreme amounts of company data just to use features that open-weight models can now one-shot is absurd to keep doing blindly. I do not understand why people are not far more protective of this. And that is just reads. We have not even gotten to writes.
Local vs cloud
Here is the real world’s best example of a local model, in good faith, beating a frontier cloud model, in bad faith. This is 100% real…
In July 2026, Hugging Face, a company with every cloud relationship on Earth, was breached by a frontier cloud AI agent. Not an agent someone pointed at them. An agent OpenAI was running inside its own evaluation sandbox, which found a write path out, spent two and a half months quietly building access, then spent four and a half days inside Hugging Face’s production network executing roughly 17,600 actions. It got in through a chain across four outside services: a package repository, a key vault, a Kubernetes misconfiguration, and a third-party compute vendor. Every integration was a hop. The credential that broke it open was a single over-privileged key sitting in a public paste. The whole thing was logged the entire time, and nobody recognized it as machine activity for almost a week, because 17,000 actions went into the same triage queue as ordinary noise. Hold on to that detail.
Read that again with your own stack in mind. The datacenter that built the model could not keep the model in its box. The box was a sandbox documented as isolated and never verified as isolated. That is either gross negligence or intentional, and the result is the same either way: unacceptable. It is also the exact assumption behind every one-click connector in every cloud workspace right now.
Then it got worse. When Hugging Face’s security team sat down to figure out what hit them, they did what most companies would do and fed the attacker’s logs and payloads to a frontier model from a leading U.S. lab. It refused. Its guardrails could not tell the difference between an incident responder and an attacker, so it would not examine the exploit code, and pushing it risked getting their account flagged in the middle of an active breach.
Clem Delangue, the CEO, put it plainly: “When you’re in the middle of an active incident, you can’t have your tools refusing to examine malicious payloads or getting your account flagged.” And: “Attackers are already using cloud agents, and they obviously don’t respect any guardrails.”
Sit with that asymmetry. The attacker had an unrestricted cloud model. The defender had a restricted one. The only way out was to stop renting. Hugging Face pulled GLM 5.2, an open-weight model, onto their own hardware and ran it over all 17,000-plus logs. That is what reconstructed the timeline. That is what pinpointed the entry point. Delangue’s words for why it worked: it let them do the work “without asking anyone’s permission.”
This is why local wins, and why it wins harder the bigger you are. A giant company does not have less exposure than you. It has more. More vendors, more credentials, more integrations, and each one is a hop an agent can take at machine speed. Scale does not buy you out of the problem. It buys you more surface. When the incident comes, the thing that decides whether you recover in a day or a month is whether you can run a capable local model over your own logs, your own code, and the attacker’s code, at full speed, with nobody rate-limiting you, flagging you, or deciding your forensic work looks too much like hacking. A rented model is a vendor’s liability policy. It is not your security policy. You find out which one you have at the worst possible moment.
The Cloud Security Alliance’s write-up of the incident now literally recommends that companies “pre-stage access to a locally hosted, open-weight model capable of analyzing attacker-authored exploit code without refusal-driven interruption.” That is the industry’s own security body telling you to do what this paper has been telling you to do. The difference is that they are telling you to do it for the day you get breached. I am telling you to build your whole workflow that way.
Own your weights
Here is where the three groups come back, because all three of them were in that building.
Group 3 was in the triage queue. Seventeen thousand machine actions sat in the same list as ordinary noise for almost a week, and the people watching that list did not see a machine. That is not stupidity. Nobody had ever shown them what an agent looks like in a log. This is the cost of the knowledge gap in one sentence: the breach was fully visible the entire time, and the gap is what gave it a week.
Group 2 was the security team’s first instinct. Something is wrong, so open the chat window and ask the frontier model. That is AI as an app, and it is exactly how most enterprises are deployed right now: a rented model, a login, and a one-click connector with write access on the other end. It refused them. The Group 2 posture works right up until the day it matters, and then whether you get to defend yourself is a vendor policy decision.
Group 1 was in the room twice. OpenAI’s sandbox was Group 1 at its worst: building until the hands fall off, never once verifying the box, and shipping the gap to everyone downstream. Hugging Face’s team, when they pulled GLM 5.2 onto their own hardware and ran it over the logs without asking anyone’s permission, was Group 1 at its best. Same knowledge. The difference was who owned what they were running.
That is the move. Not building a model from scratch. Owning the one you run. An enterprise leaves Group 2 the moment it can run a capable model when it matters, on its own hardware, with nobody’s permission required. Open weights are now good enough for the hard jobs, so the only thing standing between most companies and that moment is the gap this paper opened with.
So, three things. Run your agents on hardware you own. Keep your data in the building. Put reads and writes in separate processes with separate keys, and guard the writes like they are the vault, because they are. A workstation can do all of it today. Your workflow is just your bottlenecks solved over time. Capture them with engineering, and power that engineering with compute you own, in perpetuity.
Then teach it. If you are in Group 1, the moat you are protecting by staying quiet is the same gap that gave an agent a week inside Hugging Face. Closing it costs you a little progress. Leaving it open costs everyone downstream. The burden of proof is on us now.
The fear of the thing and the thing itself are usually very different. The thing, here, is a box in your office that answers to you. Build your workflow around it now, so that the day everyone else calls a crisis is, for you, a Tuesday.
Author’s note: I originally wrote this on May 26, 2026 and held it until I had a real-world example to make the case. It is now October, and it still holds up.