Here is the finding that should be most annoying to anyone who has spent this year arguing that agent security is an unsolved research problem.
After the July intrusion, the organisation on the receiving end published its remediation list. Read it as an inventory rather than as a plan:
Not one of those was invented in response to the incident. Metadata-service blocking is standard cloud hardening and has been for years. Workload identity has a mature open specification and a mature open implementation, contributed to by a company that is itself part of the industry's largest recent collaboration on exactly this problem. Short-lived, audience-bound credentials are not merely a known good practice but a well-tooled one. Cluster-scoped rather than shared credentials is least privilege, which is textbook. Narrow trust boundaries is the oldest idea in the discipline.
The victim's own phrasing on the second item is the one that stays with me: workload identity was implemented "when it was not yet implemented." Not invented. Not researched. Implemented — a thing that could have been done at any point and had not been.
A catalogue is not a system
Each of those controls, had it been present, would have broken a specific link in the July chain. The metadata block would have broken credential harvesting. The scoped credential would have broken lateral movement. Short expiry would have narrowed the window. Workload identity would have made the forged tokens harder to place.
Each one alone was a wall with a door beside it.
This is the structural point and it is not specific to one victim. The components are individually correct and mutually unaware. Workload identity does not know what the policy engine decided. The policy engine does not know what the attestation service observed. The transparency log records that an artifact was signed but has no opinion about whether the action that used it was authorised. Each answers its own question well and none of them composes into a statement about whether a particular action, by a particular agent, under a particular grant, may proceed.
An agent does not have to defeat any of them. It walks between them, which is what the July timeline describes in some detail.
The same shape at ecosystem scale
In late July 2026 the industry's largest collaborative effort in this area launched, with a founding roster of over a hundred organisations. Each contributed something specific and real — a workload-identity framework, a safe weight-storage format, a supply-chain scanning tool, a multi-model scanning harness, a coding agent, open model weights, agent-harness research.
I want to be careful not to be glib about this, because it is genuinely valuable. These are real contributions, openly licensed, from organisations that did not have to make them. The weight-storage format alone removed an entire class of deserialisation attack from the ecosystem. Open workload identity is the reason the second item on that remediation list was a configuration task rather than a build.
And a catalogue of primitives is not a system. Nobody contributed the layer that binds them into something an agent cannot bypass.
The reason is structural rather than a failure of will, and it is worth naming precisely. The binding layer is not a primitive anyone owns. It sits between other people's components, which means no single contributor's roadmap covers it, no team gets promoted for it, and every organisation with the expertise to build it has a product that is one of the pieces rather than the join. Integration work is the least rewarded and most necessary category of engineering, and this is a large, public, well-funded demonstration of that.
There is also a harder version of the problem. A binding layer only helps if actions actually pass through it, which means it has to be non-bypassable, which means it has to be adopted at a level below the thing being bound. That is a much heavier lift than publishing a library, and it is why the pieces that do exist are the ones that can be adopted incrementally.
Consume, don't reimplement
If the gap is composition, then the discipline that makes any attempt at it credible is the discipline of refusing to build most of it. This is worth stating as an engineering rule rather than a slogan, because it has a testable form.
The following are solved, in the open, well enough that re-solving them tells you something unflattering about the engineering judgment of whoever is doing it:
- *Workload identity* — a mature specification with a mature implementation, designed for exactly the per-workload, short-lived, audience-bound case that agent deployments need.
- *Policy evaluation* — solved twice over in independent mature open implementations, either of which will evaluate an authorisation decision faster and more correctly than a bespoke rules engine written under deadline.
- *Artifact signing and transparency* — an open model-signing specification that is registry-agnostic, uses an established bundle format, supports keyless identity-based signing, records to a public transparency log, and signs weights, tokenisers, configs and datasets as a single verifiable unit. Adopted by major model hubs.
- *Attestation* — a standards-track architecture with working implementations, for the question of what a workload actually is before you decide what it may do.
- *Adversarial testing* — open harnesses exist, are maintained, and are better than anything most teams will write.
The rule that follows is simple: if you are building in this space and your component list includes any of the above as something you wrote, the burden is on you to explain why. Occasionally there is a real answer. Usually the answer is that it was easier to write than to integrate, which is true and is also how you end up maintaining a worse version of a thing a standards body maintains for free.
The corollary is about credit, and it is not a courtesy. Naming your dependencies generously is what makes a claim of novelty elsewhere checkable. A project that claims originality everywhere has told you nothing about where its originality actually is — the claim is unfalsifiable, so it carries no information, which is the same failure as the unattacked green report in Part III. A project that credits its dependencies plainly and points at three specific things nobody has built has given you something you can go and verify.
There is a useful test buried in that. Ask any vendor in this space which parts of their system they did not build. An answer that is long, specific, and names things you recognise is a good sign. An answer that is short or evasive means either they built everything — which is a red flag — or they have not thought about the boundary between their work and the ecosystem's, which is a different red flag.
Why the regulatory position argues for building now
The supervisory picture makes the timing sharper rather than softer, and it is being widely misread.
In April 2026 the US banking agencies issued revised interagency model-risk guidance, superseding the framework that had governed model risk for over a decade. On the systems this arc is about, it says plainly that generative and agentic AI models are novel and rapidly evolving and, as such, are not within the scope of the guidance.
That has been read in places as breathing room. The agencies themselves say otherwise: institutions are directed to apply their broader risk-management and governance practices to anything the revised guidance does not cover, expressly including generative and agentic systems. Every duty attached to the underlying action survived. What was removed is the framework that would have specified the controls.
So the duties remain and the specification is gone. And a request for information is coming, which produces the situation worth being clear-eyed about:
The separate guidance will be written against whatever the industry has already built.
Not against what it should have built. Against the artifacts that exist by then, the evidence formats actually in production, and the control patterns common enough to be describable. Whoever has working evidence infrastructure when that consultation opens is not merely compliant early — they are supplying the vocabulary.
The same argument runs on different clocks elsewhere, which is why I would build to the underlying question rather than to any single regime. India's data-protection rules carry an 18-month runway to May 2027, with organisations designated as significant data fiduciaries owing an independent annual audit and a data-protection impact assessment within twelve months of designation — an audit that will ask what an automated system did, under what authority, and where the record is. Gulf supervisory frameworks and sovereign-AI programmes are being drafted now, in public, by people reading the same incident disclosures everyone else is reading. The EU's position is well documented and, for these purposes, changes none of the engineering.
Strip the jurisdictions away and one question survives all of them:
Can you show, to someone who does not trust you, what an automated system did, under what authority, and what it was refused?
That question does not need a regulator to be worth answering. Every regulator that exists will eventually ask a version of it, and a system built to answer it is portable across all of them in a way that a system built to satisfy one framework is not.
The open stack is a global condition, not a regional story
It is tempting to file the composition problem as somebody else's — a frontier-lab problem, or a problem for whichever market is currently being discussed. It is neither.
Any organisation building on open weights inherits the primitives for free and inherits the binding problem in full. That is true for a bank in North America assembling an internal agent platform, for a services firm in India standing up delivery automation under a domestic audit clock, for a sovereign programme in the Gulf that has explicitly chosen open models to retain control of the stack, and for a public-sector deployment in Canada with procurement rules that predate any of this.
The stack is available to everyone. The composition is available to nobody. That is a better position than the alternative — the closed equivalent gives you someone else's composition, unexaminable, and you inherit their assumptions along with it — but it is not a solved position, and treating open weights as though the security question came bundled is the specific error that this year keeps punishing.
The regional differences are real and they are about what the binding must produce, not about whether it is needed. An audit clock changes what evidence has to look like and when. A sovereignty requirement changes where the components may run. A procurement regime changes what may be consumed at all. None of them changes the fact that six correct components with five gaps between them is not a boundary.
What this argument cannot do
- *It does not tell you the binding layer is easy.* It is not. It has to be adopted below the thing it binds, which is a heavier lift than publishing a library, and that difficulty is a substantial part of why it does not exist.
- *"Everything already existed" is a statement about primitives, not about deployments.* The components were available. Whether they compose cleanly in your estate, with your orchestrator and your identity provider, is an empirical question this piece cannot answer for you.
- *Consume-don't-reimplement is a heuristic, not a law.* There are real cases where an existing component genuinely does not fit. The discipline is in owing an explanation, not in never writing anything.
- *Crediting dependencies does not validate the remainder.* A generous credits list makes a novelty claim checkable. It does not make it true. Someone still has to check.
- *Nothing here establishes that any particular binding layer is non-bypassable.* That is a property of a deployment, substantiated by an adversary, per Part III — and it applies to a binding layer exactly as much as to the components it binds.
The uncomfortable summary of the whole arc is that July required nothing new. Not a new attack technique, not a new class of vulnerability, not a capability that did not exist last year. It required an objective, a path nobody had written down, an identity that could be issued rather than stolen, an environment nobody had tried to leave, and a set of correct controls that had never been joined together.
Every one of those is an architecture decision, and every one of them was available to be made differently.