Intelligence
Join the waitlist
AEW-018

Authority over a destination treated as authority over the source that fills it

A transfer or import operation confines where it is permitted to write, and that confinement is treated as though it also settled where the operation is permitted to read from. The source stays reachable to anything a caller can name that satisfies a content check.

Status: publishedExecution AuthorityEnvironment Boundaries

Description

A resource transfer, a copy, an import, an upload accepted from a caller named location, has two ends, and each end raises its own authority question. Is the operation permitted to write here. Is the operation permitted to read from there. This weakness appears when a system answers the first question correctly, with a real, working check that confines the destination to an authorized scope, and never asks the second question at all, or asks only whether the source's contents satisfy a format or content shaped test rather than whether its location lies within any authority the caller holds. A destination confined this way is a genuine, working control, not a decoy; the gap is that its presence is mistaken, in the system's own design, for having addressed the operation as a whole. It differs from reachability substituting for authority in the absence of any check (AEW-008), where nothing on the path constrains the reachable target at all: here a check exists, runs and works, on one side of the same operation, which is exactly what makes the missing check on the other side easy to overlook. It differs from an operation's authority being silently 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 which concern one resource identity standing in for another inside a single sided operation; this weakness concerns two distinct resource identities inside one two sided operation, where getting one side's authority question right supplies no evidence at all about the other. It also differs from a failed resolution inheriting the trust of an apparent path (AEW-017), where a check exists, fails, and its failure is then treated as a pass; here there is no failure to convert, because the source side check was never written in the first place.

The authority gap

The authority required covers both ends of a transfer: where the operation may write, and separately, where it may read from. The authority presented, once the destination is confined, is treated as though it settled both questions, and the source is left reachable to anything the caller can name that satisfies a content check.

Failure conditions

  • An operation copies, imports or otherwise transfers a resource from a caller named source location into a location the system does confine to an authorized scope.
  • The system checks that the destination resolves inside the authorized scope before writing, and the check works.
  • The system applies no comparable check to the source: the only gate, if any, is that the source's contents satisfy a format or content shaped test, not that its location lies within any authority the caller holds.

Consequences shown by the evidence

  • A caller reads or imports arbitrary server side directories or files into a location the system treats as trusted, because the location the operation copies from was never checked against any authorized scope.
  • Content that passed only a shape or format check is treated as legitimately sourced once it lands, with the operation itself carrying no record of where it actually came from.

Detection signals

  • A fix for an incident adds a source side confinement check that mirrors one that already existed only on the destination side of the same operation.
  • A resource identifying argument is validated for its content shape but never checked against an allowed location.
  • The two arguments of one transfer operation, source and destination, receive visibly different levels of scrutiny inside the same function.

Known examples

  • AgentScope's LocalWorkspace.add_skill method resolves the destination directory a copied skill writes into with os.path.realpath and rejects the write if it does not resolve inside the agent's skills directory, a real, working check confirmed by direct reading of the source. The same method takes a caller supplied skill_path naming where the skill is copied from, normalizes it only by expanding a user home shorthand and making it absolute, validates it only by checking for a SKILL.md file with name and description frontmatter, and passes it unchanged as the source argument to shutil.copytree, with no check that skill_path resolves anywhere inside any authorized scope. GHSA-gpf9-4466-gc5g and CVE-2026-85685, CVSS 4.0 base score 8.7, High severity, CWE-22, describe the resulting arbitrary directory copy in AgentScope through version 2.0.7.post1. The underlying flaw was reported privately on 12 June 2026 and opened as public GitHub issue 2069 on 13 July 2026; the CVE published 4 September 2026, with no maintainer response, no linked fix and no patched release found in anything this weakness's evidence could establish.

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 The draft separates agent identity and standing access from authorization of one concrete action

    As described in material supplied to this session, AADP argues that its own decision addresses whether a specific proposed action, with specific argument values, may proceed, distinct from identity and standing access. AgentScope's add_skill vulnerability shows a resource identifying argument, skill_path, that is exactly the kind of specific argument value AADP's own described decision would need to evaluate, and nothing in the material available to this session, for either revision of the draft, states that evaluating a proposed action's argument values includes checking that a resource identifying value resolves inside an authorized location rather than only checking its content or format. This session did not read either revision's own text directly. Recorded as a missing requirement rather than a supported one because the available description states a decision over action and argument values in general terms, not a location confinement requirement for a transfer's source specifically.

    View protocol evidence