An execution bearing authority representation is maintained independently of its own canonical grant, with no derivation or parity proof between them

Description

This weakness differs from every neighboring representation gap this registry already names by where the gap sits. A malformed authority restriction parsed the same as no restriction at all, AEW-032, lives inside one authority bearing field and one parser, whose own fallback branch collapses an unparseable value into the same result as absence; the check runs, inspects the value, and the failure is what its own default branch does with an outcome it cannot classify. A tool's declared capability does not survive the executor's own argument grammar, AEW-025, concerns one declared value crossing into a different authority space inside a single invocation's own argument parsing, at the moment a process spawns; the value's declared class and its resolved class are two readings of the same field, decided by one external grammar. An authorized narrowing that a control plane cannot represent does not survive its own reconciliation, AEW-033, concerns a live, correctly enforced restriction that a persisted canonical description has no vocabulary to represent, so a reconciliation pass wrongly reads an authorized narrowing as an anomaly; there, one record exists, and it is only lacking the field to describe what already happened at the enforcement point. Here there is no single field, no single parser, and no reconciliation pass at all. Two entire representations exist for the same authority question, authored by different people or different migrations at different times, read by different loader code, expressed in different grammars, and nothing in the system reads both and asks whether they still agree. The gap this weakness names is not a parser's fallback branch or a schema's missing vocabulary; it is the complete absence of any function spanning both representations, so a canonical grant can be edited, a harness allowlist can be edited, and neither edit has any way of learning that the other happened.

The authority gap

The authority actually exercised at execution is whatever the independently maintained execution side representation says, verified directly against its own source. The authority required is whatever the canonical grant says. Nothing connects the two, so the system cannot state, for any given principal, whether the authority it is about to exercise is the authority that was actually granted, narrower than it, or wider than it, until someone reads both representations by hand.

Failure conditions

• A system stores a principal's authorized actions in one canonical record, and a separate execution layer reads what it will actually permit that principal to do from a different, independently maintained field.
• The two representations use different grammars, different field names or different data shapes for what is, in substance, the same authority question.
• No function in the system derives the execution layer's own representation from the canonical record at load time, and no test compares the two and fails when they disagree.
• A field that appears to link the two, by name or by position, turns out on direct reading to be something else, such as a role label or an unrelated enumeration, rather than a reference resolving one representation into the other.

Consequences shown by the evidence

• A principal's effective, exercised authority is wider than anything any canonical grant names, with no governance write behind the difference and no record of who authorized it or when.
• An operator who edits the canonical grant, believing it controls behavior, sees no change in what actually executes, because the execution layer never reads that record at all.
• A migration or an audit that reads only the canonical grant, the more legible of the two representations, reports an authority picture the execution layer does not actually enforce.

Detection signals

• Two independently named fields, on two different entities or in two different files, both purport to describe what a principal may do, in two different grammars.
• A field named after the canonical record, sitting on the execution side entity, turns out on direct reading to hold something other than a reference to that record.
• No test file, lint rule or CI step in the repository compares the canonical record against the execution side representation for the same principal.
• A default or fallback value on the execution side, reached when the canonical side is unreachable or unset, resolves to the widest possible authority rather than the narrowest.

Known examples

• GitHub issue 803 against markmhendrickson/ateles, opened 7 September 2026, and pull request 807 built on it, both independently verified by this session through a direct clone of the repository's current default branch, commit 27101189c285c959c47dcb66c99669022dfe489a. agent_grant stores tool capabilities as op strings shaped tool colon server colon tool, normalized by GrantChecker._parse in lib/daemon_runtime/grant_checker.py into a tool_grants map keyed by server and tool. The harness instead reads agent_definition.tool_allowlist, in a materially different grammar, through AgentLoader in lib/daemon_runtime/agent_loader.py. This session confirmed directly that agent_definition carries a field literally named agent_grant, which reads as though it might resolve the first representation into the second, and is in fact a two valued role string, service or operator, exposed only through boolean shaped properties, never a reference to any specific grant entity; the grant an agent actually holds is looked up separately, by aauth_sub, through a code path that never touches agent_definition. This session separately read scripts/linters/validate_tool_allowlist.py, the repository's own machine enforced grammar check for the harness side field, and confirmed it carries no reference to agent_grant or GrantChecker of any kind, only a check of the harness field's own shape. This session further read execution/daemons/apis/skill_runner.py directly and confirmed an unconditional widening mechanism neither representation describes: for the claude provider, every agent whose own tool_allowlist is not the bare wildcard receives an added mcp__mcpsrv_neotoma__* entry regardless of what its allowlist or any grant names, while the codex and cursor providers receive no comparable tool scoped flag at all, confirmed directly from the exact command each provider's own code path builds. This session also read execution/mcp/mcp_tool_grant_proxy/proxy.py, a real, documented enforcement point for agent_grant tool capabilities that is, by its own docstring, permissive whenever an agent's grant declares no tool capability, and confirmed a repository wide search finds no executable reference to it outside its own directory, while the repository's own docs/architecture.md and docs/aauth.md each describe it as shipped and live. Pull request 807, itself still open, design only and targeting another unmerged branch, independently confirms the same unconditional wildcard append and the same zero executable references to the proxy in its own added verification table, and states that its own attempt to reverify the issue's own headline count, thirty one grant entities with zero tool capabilities across forty measured agents, failed, its own five attempts against the production Neotoma endpoint each returning a 502. This session's own access to that production endpoint is nonexistent rather than merely unattempted, and this weakness accordingly carries the forty agent, zero parity count as issue reported evidence, independently corroborated at the mechanism level by this session's own direct source reading, rather than as a count this session itself reproduced.

Recorded instances

• AEV-2026-0051 Ateles dispatches an agent's tools from a harness allowlist maintained independently of its own canonical grant AESS 8.5 high Confirmed

Related Intelligence Records

The published Moona Intelligence Records whose evidence establishes this weakness.

• The Harness Kept Its Own List of What an Agent Could Call. Nothing Ever Checked It Against the Grant.

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 Control Standard (ACS)

  OWASP GenAI Security Project, originally Zenity

  Requirement The specification does not guarantee complete mediation of every consequential action a host can take

  ACS's own conformance document states directly that the specification does not guarantee complete mediation of every consequential action a host can take. Ateles's own mcp_tool_grant_proxy is direct, independently confirmed evidence for exactly that admission at the level of a single, real enforcement point: this record's own reading of the current default branch found the proxy real, documented and built specifically to mediate agent_grant tool capabilities, yet carrying zero executable references anywhere on the dispatch path skill_runner.py actually builds, while the repository's own architecture documentation describes it as shipped and live. A mediation point can exist, be correctly written, and still mediate nothing a live dispatch ever reaches, which is a sharper instance of ACS's own stated limitation than an unimplemented control would be.

  View protocol evidence

• Supports requirement

  Verifiable Attenuated Delegation for AI Agent Chains (draft-asor-wimse-agent-delegation-chain)

  Rafael Asor, Attenu

  Requirement Revision 01 defines a normative ABNF scope grammar: lowercase, period separated segments, with a wildcard permitted only as the complete final segment

  The draft's own normative ABNF gives a delegation token's scope grammar exact, bounded wildcard semantics, so a verifier can decide subsumption without inventing a rule for a shape the grammar leaves ambiguous. Ateles's own still open pull request 807 independently arrives at the identical need from the opposite direction, a system that already has two ungoverned grammars and no bijection between them: its own added proposal defines exactly which wildcard forms a grant capability may take, refuses a bare tool colon asterisk outright, and bounds a surface level wildcard to an enumerable domain, citing the same fail-open concern this record's own reading of Ateles's unconditional Neotoma wildcard append independently confirms in shipped code today. This is evidence for why a normative, bounded wildcard grammar matters as a general precondition for any parity claim between two authority representations, not only for one draft's own delegation tokens.

  View protocol evidence

• Supports requirement

  Verifiable Attenuated Delegation for AI Agent Chains (draft-asor-wimse-agent-delegation-chain)

  Rafael Asor, Attenu

  Requirement A verifier encountering an unrecognized constraint type must deny rather than treat it as unconstrained

  The draft's own verified rule requires a verifier to deny on an unrecognized constraint rather than read it as unconstrained. Pull request 807's own design proposal states the same discipline for a provider whose effective tool reach cannot be introspected from its own command line, codex and cursor among them confirmed directly by this record's own reading of skill_runner.py's per provider construction: such a provider must report as unknown, never as a passing parity result, because an unmeasurable surface defaulting to green is the identical failure this draft's own constraint rule already forbids at the level of one delegation token. Recorded as evidence for the same fail closed on unknown discipline operating at the level of an entire execution surface rather than one constraint field.

  View protocol evidence