Transport principal treated as content principal
A message's transport principal, whoever sent, uploaded or forwarded it, is treated as though they were also the content principal, the author of everything the message carries. A composite message's single role and single field attribute the sender's own authority to attached data nobody has established the sender actually wrote.
Description
This weakness sits earlier than a claim of authority and earlier than an objective. It appears when a system builds one message out of two things that do not share an author, most often a user's own typed words and the contents of a file, a forwarded item, or a downloaded artifact the user merely supplied, and represents both inside one field carrying one role. A downstream reader has no way to tell, from the message's own shape, that the sender and the content's actual author might be different people, or that the content's author might be unknown entirely. It differs from a claimed authorization accepted without verification (AEW-007): there, an actor asserts in words that an action is authorized, and the gap is that nothing checks the assertion. Here nobody asserts anything; the architecture itself assigns the sender's authority to content the sender did not write, by the simple fact of where that content is placed. It differs from an objective's authorization being treated as authorization for any action that serves it (AEW-002): that weakness concerns what an already identified principal's authority covers; this weakness concerns whether the content inside a message even has one identifiable principal to begin with. The same gap recurs a second way, once past ingress: when content already known to be externally sourced is cached, extracted, converted or reread through a later tool whose own return value carries no origin field, the classification a system could have captured at the moment of ingress is not carried forward, and a file that arrived from outside the conversation becomes indistinguishable from one the user wrote locally the moment it is read back.
The authority gap
The authority required is the authority of whoever actually authored the content inside a message: the file's own writer, a third party, or unknown. The authority presented is the authority of whoever transported the message. The system treats the second as proof of the first, with nothing in between checking whether they are the same principal.
Failure conditions
- A gateway or ingestion path accepts inbound content from a channel whose authorship it does not control: a chat attachment, a forwarded document, a downloaded artifact.
- The system represents that content and the channel sender's own words inside one composite unit, typically one message role and one text field, with no separate authority marker for each component.
- A downstream reasoning step reads the composite unit's single role as the authority of everything inside it, rather than evaluating each component's own authorship.
- The content is cached, extracted, converted or reread through a later tool, and whatever classification existed at ingress is not carried into the transformed result.
Consequences shown by the evidence
- A document, forwarded message or upload can carry instructions read with the same authority as the user's own typed words, because the message that carried them used the user's own channel.
- A provenance mechanism that classifies content only when a recognized fetch command produces it misses content a gateway already received and cached as an inbound attachment, the same classification gap arriving through a different door.
Detection signals
- A composite message's text field contains both a machine generated wrapper around attachment content and the user's own words, with nothing else in the data structure distinguishing the two once the message reaches the model.
- A test suite asserts that attachment content is inserted into the same field as the caption and appears ahead of it, with no accompanying assertion of a separate authority marker on that content.
- A caching or document extraction function accepts a path or bytes and a filename and returns text with no origin, source or trust field anywhere in its signature.
Known examples
- GitHub issue 103689 against NousResearch's Hermes Agent, opened 5 September 2026 and independently corroborated by this desk's own direct reading of the affected source at the exact commit the issue names, describes and this reading confirms that gateway/platforms/whatsapp_cloud.py and plugins/platforms/whatsapp/adapter.py each write a small text attachment's own decoded bytes into the same message field as the user's caption, headed by a Content of filename marker and placed ahead of the caption. Hermes Agent's own test suite, tests/gateway/test_discord_document_handling.py, asserts the identical contract for Discord as a requirement, including that the marker's position in the constructed text precedes the caption's own position. Read the same way, plugins/platforms/slack/adapter.py and plugins/platforms/feishu/adapter.py show no equivalent construction, narrower than the underlying issue's own four platform claim.
- The same source, read directly, shows tools/read_extract.py and gateway/platforms/media_cache.py each returning extracted or cached content with no field recording where the underlying bytes originated, so a gateway attachment already known at ingress to be externally sourced carries no marker of that fact once cached or extracted. A separate, unmerged pull request, 57712, proposes tracking external provenance only for paths a recognized fetch command such as a git clone or a curl produces, a mechanism that by its own command detection design cannot reach a path a gateway wrote directly.
Recorded instances
No recorded instance yet. The weakness stands on the records below.