The Register Says the Bug Is the Framework, Not the Prompt. They Have a Point

AI disclosure: This article was drafted by an AI writing assistant from a brief set by the author, then reviewed and published by them.

Most of the conversation about AI agent security focuses on prompt injection, the trick of hiding malicious instructions in content an agent reads. It is a real threat. But in August 2026, security researchers made a sharper argument: prompt injection is not really the bug. The bug is the agent frameworks that give a manipulated model enough power to do damage in the first place. It is a subtle shift in blame, and it points at exactly the thing a business can actually control. Here is the argument and what it means for how you deploy AI.

The reframing

Per reporting from The Register in August 2026, the security community increasingly views the frameworks that build and run AI agents as the real source of exposure, rather than the prompt injection that exploits them. The reasoning is straightforward once stated. Prompt injection will always be possible to some degree, because a language model fundamentally cannot perfectly separate instructions from the content it processes. If your security depends on preventing every injection, you have built on sand, because that prevention is not fully achievable.

What is achievable is limiting what a successfully-manipulated agent can do. And that is determined not by the model but by the framework around it: how much access it has, what actions it can take, what it can reach. An agent framework that grants broad permissions and unsupervised action turns an inevitable injection into a catastrophe. One that grants narrow permissions and requires approval for consequential actions turns the same injection into a harmless non-event. The exposure lives in the framework’s design, which is why the researchers point there.

Why this is good news

The reframing is empowering rather than discouraging, because it moves the problem from something you cannot fully control to something you can. You cannot guarantee no injection ever succeeds; that is a property of how models work. You can absolutely control how much power your agent framework hands to the model, which is a property of how you set it up. The security question shifts from the impossible prevent all manipulation to the achievable limit what a manipulated agent can do.

This is the same principle that contained even the frontier sandbox-escape incident and that underlies all sound agent security: least privilege. The framework should give the model the minimum access and the minimum power required for its task, so that the worst case of any manipulation is bounded by design. When the framework is built that way, injection stops being an existential threat and becomes a managed risk.

What a risky framework looks like

Knowing the shape of a dangerous setup helps you avoid it. An over-permissioned agent framework has some combination of these features: the agent holds broad credentials rather than narrowly scoped ones, it can take consequential actions without human approval, it can reach systems and data far beyond what its task requires, and there is little visibility into what it actually does. Each of these turns a manipulation into more damage. Together, they are the profile of the agent breaches that cost real money.

The tempting thing about building this way is that it is easy and it works in the demo. An agent with broad access and free rein completes tasks impressively when nothing is trying to manipulate it. The exposure only shows up when something does, at which point the broad access you granted for convenience becomes the broad access the attacker uses. Convenience and exposure are the same design choice viewed from two moments in time.

What a safe framework looks like

The safe version inverts each risky feature. The agent holds credentials scoped as narrowly as the task allows, read-only wherever reading suffices. Consequential actions require human approval rather than happening autonomously. The agent can reach only the specific systems and data its task requires, and nothing wider. And there is real visibility into its actions, so anomalies surface early.

Built this way, the framework contains the damage from any manipulation regardless of whether you caught the manipulation itself. That is the goal: not a framework that never gets injected, which is impossible, but one where a successful injection cannot reach anything that matters. The security lives in the boundaries, not in the hope that the model is never fooled.

Buying versus building, through this lens

The framework reframing also clarifies how to evaluate an agent product you are considering buying rather than building. Vendors will market their injection defenses, and those are worth having, but they are not the question that determines your exposure. The question is what the product lets a manipulated agent do. Ask a prospective vendor plainly: what permissions does this agent hold, can it take consequential actions without a human approving, and what is the worst thing it could do if it were manipulated into acting against my interest? A vendor who has thought seriously about security will have clear answers that amount to it is bounded. A vendor who only talks about how well it resists injection, without bounding what happens when resistance fails, is selling you the sandcastle.

The same lens applies to building your own. Whatever platform you assemble an agent on, your security is determined by the boundaries you set, not by the cleverness of the model or the strength of any single defense. Design the boundaries first, assuming manipulation will eventually succeed, and the agent is safe by construction rather than by hope.

The practical takeaway

For a business deploying AI agents, this reframing gives you the right question to ask of any agent setup, whether you build it or buy it: not is this protected against prompt injection, which no honest answer can fully promise, but what can this agent actually do if it is manipulated, and is that bounded to something I can live with. If the answer is that a manipulated agent could send money, email your list, delete data, or reach systems it has no business touching, the framework is too permissive, and no amount of injection defense makes that safe. If the answer is that the worst a manipulated agent could do is produce a bad draft you would reject, the framework is sound, and injection is a nuisance rather than a threat.

The researchers’ point, distilled, is that you should spend your security effort on the boundaries you control rather than on the manipulation you cannot fully prevent. Design your agent frameworks so that being fooled is survivable, and you have solved the part of the problem that is actually solvable, which turns out to be the part that matters.

Controlling your exposure by controlling what has power over your systems is the same instinct that should shape your whole business. Owning your audience and your channel, rather than depending on platforms whose power over you is broad and unaccountable, is that principle at the level of the business. The Blogging System is built so the access that matters, your relationship with your audience, stays in your own hands.