Authorization over an operation treated as authorization over its target
An operation is authorized, and the record or records it may act on is assumed to follow automatically. Where a target identifying argument can be reinterpreted as a broader selection expression, the authorized operation reaches objects nobody named.
Description
Two authorization decisions hide inside what looks like one. Deciding that a caller may invoke a consequential operation, an update or a destroy on a named resource type, is one decision. Deciding which specific record or records that one invocation actually reaches is a separate decision, ordinarily made by a target identifying argument the caller supplies. This weakness appears when the second decision is treated as automatically settled by the first: nothing independently confirms that the resolved target matches the single record the argument appeared to name. It differs from an objective silently authorizing a wider action (AEW-002), where the gap is between a goal and the steps taken to reach it, and from an approval failing to bind to what executes (AEW-005), which concerns a human review step and state mutated after that review. Here there is no objective substitution and, often, no human review at all: a machine enforced authorization mechanism receives an argument whose shape, not its content, decides whether it means one record or a query for many.
The authority gap
The authority presented is authority to perform the operation on the resource type. The authority required is authority over the specific record or records the operation actually resolves against, and the two are silently equated.
Failure conditions
- A consequential update or destroy operation resolves its target from a caller supplied argument rather than an enumerated set of permitted records.
- The mechanism that resolves that argument into a query accepts a value shaped as a predicate or expression, not only a literal.
- Nothing independently confirms the resolved target set matches the one record the argument appeared to identify.
Consequences shown by the evidence
- A caller authorized to update or destroy the one record it identifies instead updates or destroys a record, or every record, it never named.
- A tool's advertised schema promises a scalar identifier while the execution path that resolves it accepts a broader structure instead.
Detection signals
- A target identifying argument reaches a query filter or expression builder without first being cast to the field's own literal type.
- A fix relocates the cast or validation of a target identifying value ahead of query construction, rather than only tightening the schema the caller sees.
- How many records an authorized operation reaches changes with the shape of one argument, with no separate authorization decision governing it.
Known examples
- AshAi's identity_filter built an update or destroy tool's target filter directly from a raw tool argument; a caller supplying a nested comparison object where a scalar identifier belonged retargeted the operation at a record it never named, up to any row of the table. CVE-2026-82564, patched in AshAi 1.0.0.
Recorded instances
- AEV-2026-0013 AshAi identity filter let a caller retarget an update or destroy tool (CVE-2026-82564) AESS 8.0 high Confirmed
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.
- Supports 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
AADP's own separation states that identity and token layers answer who is acting and what a principal may reach, while the authorization decision itself must evaluate a specific proposed action with specific argument values. AshAi's identity filter collapsed exactly that separation: identity configuration named which attribute should address the target, and the runtime accepted whatever value shape the argument carried instead of the specific value the operation required.
- Supports requirement
EP Authorization Receipts (EMILIA Protocol)
Iman Schrock, EMILIA Protocol, Inc., individual submission to the IETF
Requirement The Action Object in revision 12 names ep_version, action_type, target, parameters, initiator, policy_id and requested_at as its required fields, canonicalized under RFC 8785 and hashed with SHA 256
EMILIA's Action Object treats target as a required field, canonicalized and hashed alongside the action type, before anything is authorized, so a target cannot be silently reinterpreted after the fact. AshAi's vulnerable identity filter shows the consequence of a target identifying value that is not pinned this way: a caller supplied structure the executor could parse as a broader expression rather than the one value it named.