Authority to instruct an install is treated as authority over whoever currently controls what the instruction names

Description

This weakness sits at the boundary between two authority questions that a single install instruction quietly collapses into one. The first question is whether the party issuing the instruction, a vendor's own documentation among the clearest cases, is trusted to tell an agent to install something. The second, entirely separate question is whether the specific artifact that currently answers to the name the instruction contains is controlled by that same trusted party, or by anyone it authorized. An instruction can pass the first question honestly, the documentation is genuine, unmodified and not malicious at the moment it is written, while the second question goes completely unasked, because a package or domain name looks like a fixed identity and is treated as one. It is not. A name is a pointer a registry or a DNS system resolves at the moment of use, and what it resolves to can be nothing at all, until whoever registers it first becomes whoever the instruction's own authority silently extends to. This weakness differs from a claimed authorization accepted without verification, AEW-007: there, an actor asserts in words that it holds authority nothing checks; here, nobody asserts anything false, the instruction's own authority is genuine, and the substitution happens entirely inside how a name resolves rather than inside a claim. It differs from an operation's authority being equated with authority over whatever it resolves against, AEW-013, and from a container's authority being equated with authority over the shared object it references, AEW-014: both of those concern one resource identity standing in, inside a single system's own authorization check, for another object that system already holds; this weakness concerns an external, independently owned namespace, a public package registry or the public DNS, that the instruction's own publisher never controlled the totality of and cannot make guarantees about simply by naming something inside it. It differs from a failed resolution inheriting the trust of an apparent path, AEW-017: there, a resolution step exists, fails, and the failure is treated as a pass; here, resolution succeeds, correctly, against a real, existing artifact, and the gap is that nothing asked whether the party that artifact belongs to is the one the instruction implied. No prompt injection, phishing or website compromise is required for any of this. The instruction can be exactly what its publisher wrote, from the moment it was published to the moment it was read.

The authority gap

The authority presented is the instruction publisher's genuine authority to direct an install in general terms. The authority required is confirmation that the specific artifact currently resolved from the instruction's own named reference is controlled by that publisher, or by a principal the publisher authorized, and the two are silently treated as the same fact.

Failure conditions

• A trusted, genuine instruction, most often vendor or product documentation, tells an agent to install, fetch or connect to an external resource identified by a mutable name rather than a fixed artifact identity such as a content digest.
• The agent resolves that name through a public package registry or DNS system the instruction's own publisher does not exclusively control.
• Nothing on the path from instruction to execution independently confirms that the principal currently controlling the resolved artifact is the instruction's own publisher, or a principal that publisher has authorized.
• The resolved artifact executes with the ordinary privileges of whichever host or account the agent is operating under, whether or not the resolved artifact turns out to be malicious.

Consequences shown by the evidence

• An agent following a genuine, unmodified vendor instruction executes an artifact the instruction's own publisher never controlled and never reviewed, because the artifact's own controlling principal changed, or was never established, after the instruction was written.
• Arbitrary code runs inside an enterprise network with no compromise of the instructing vendor's own systems, no phishing and no malicious content at the moment of publication, because the failure sits entirely in an unverified resolution step rather than in the instruction itself.
• A security review that checks whether an instruction's own source is trustworthy, and stops there, finds nothing wrong, because the instruction genuinely is trustworthy; the gap is one step further along, in what the instruction's own name currently resolves to.

Detection signals

• An install or connection instruction in vendor or product documentation names a package, domain or subdomain by a bare, mutable identifier with no accompanying version pin, content digest or publisher attestation.
• An agent's own install log or command history shows a package or domain being resolved and executed with no step recording an independent check of the resolved artifact's own publisher identity against the instruction's source.
• A package or domain named in a vendor's own current or historical documentation returns as unregistered, or as registered under a different, unrelated account, when checked against the relevant registry or DNS record directly.

Known examples

• Alon Hertz's Data Became Code research, published 26 August 2026, scanned 6,214 live domains and resolved 8,565 llms.txt and llms.full.txt agent facing documentation files by Hertz's own count, or 8,265 files across 120 sites carrying at least one unclaimed reference by Ars Technica's independent, higher confidence count, this record preserving both rather than reconciling them. More than 237 artifacts those files told an agent to install across PyPI, npm, RubyGems, NuGet, crates.io and Packagist, plus domains and subdomains, by Hertz's own count, or 227 install commands and unclaimed references by Ars Technica's count, were unclaimed. Registering a small set with nothing but an inert callback inside, and prompting five frontier model configurations and two agentic CLIs with a one sentence instruction naming only a vendor, no link and no mention of llms.txt, Hertz's team recorded a confirmed install and execution inside a Fortune 500 network's own infrastructure in under four minutes, a second Fortune 500 callback within the hour, and further callbacks afterward. Parent process chains the callback itself recorded, independently reported by Ars Technica, trace the installs to Claude, Codex and Hermes Agent sessions. Separately, and independently evidenced, one llms.txt file already in production, Clerk's own, instructed agents to run clerk-next-fix-auth-protection; run bare through npx without Clerk's own scoped eslint plugin package already installed, that name resolved on the public npm registry to a package a third party, not Clerk, had registered and loaded with an install hook exfiltrating the installing machine's username, hostname, working directory and a timestamp, cataloged as MAL-2026-11069. Clerk's own security team corrected the documentation after disclosure.

Recorded instances

• AEV-2026-0039 Coding agents autonomously installed unclaimed packages named in genuine vendor agent facing documentation inside Fortune 500 networks AESS 7.9 high Observed
• AEV-2026-0040 Clerk's own genuine documentation pointed agents at a package a third party had registered and filled with malware (MAL-2026-11069) AESS 7.2 high Confirmed

Related Intelligence Records

The published Moona Intelligence Records whose evidence establishes this weakness.

• The Documentation Was Genuine. The Package It Authorized Belonged to Someone Else.

Protocol evidence

Published authority architectures whose artifacts bear on the requirement this weakness names: which satisfy it, which expose a way past it, and which leave it unanswered.

• Missing requirement

  Agent Action Decision Protocol (AADP)

  Shamik Saha, individual submission to the IETF

  Requirement A Policy Decision Point owns authorization state and evidence; PEPs enforce it

  AADP's decide and report exchange between a Policy Decision Point and a Policy Enforcement Point evaluates whether an action is permitted, but nothing in the reported specification asks a further, distinct question this weakness names: whether the specific artifact an action resolves against, once a package or domain name is looked up, is controlled by the principal the originating instruction implied. A permit decided against an install action named in general terms says nothing about whether the resolved package's own publisher matches the instructing vendor. This dataset records that as a requirement AADP's own reported text does not yet state, not as a bypass of a requirement it does state.

  View protocol evidence

• Missing requirement

  ChainIT Authority Protocol and Agent Subject Profile for pre execution authority validation

  ChainIT

  Requirement A canonical transaction digest is described binding payer, payee, destination, amount, currency or asset and payment rail to approval and execution

  ChainIT's own reported canonical transaction digest binds payer, payee, destination, amount, currency and payment rail to one approval, the closest existing property in this dataset to binding an approval to an exact executing identity rather than a mutable name. Its own reported scope is payment transactions, not package or domain resolution, and nothing corroborated for ChainIT's own material states an equivalent digest binding a vendor's install instruction to the specific package version or publisher it resolves against. This dataset records the same digest binding discipline as a requirement package and domain install authority does not yet carry anywhere in the evaluated protocol dataset, not as an implementation of it.

  View protocol evidence