The interesting field here is the one that does not exist. According to the dev.to writeup on Adversa AI's work, the system has no mechanism to record that a given string was untrusted external ciphertext three steps earlier; provenance dies at the code-execution boundary [8]. That is not a filter tuning problem. It is a missing tag, and a tag would have to survive a boundary that currently exists to isolate execution, not to label its output.
Look at how little of the chain is anomalous. The writeup breaks the attack into four stages and names exactly one, re-classification, as the actual vulnerability [14]. Four minus one leaves three stages that are the agent doing its job [1]. Fetching a page during research is normal. Running a decryption routine is not suspicious. Issuing a URL request is not inherently suspicious either [13]. The exfiltration is assembled entirely from sanctioned behaviour.
AES is doing less work in this than the word "encrypted" implies. The property the attack needs is opacity at the layer that scans text, plus a step that resolves the opacity somewhere the scanner cannot see; the source demonstrates that with an AES blob and a key embedded in or near the ciphertext [1][7]. Any decode-then-act path with the same shape would inherit the same trust promotion. The source does not test those variants, so treat that as the hypothesis it is.
Which brings us to the fix on offer, which arrives in the same document as the attack. The writeup is a vendor piece: it proposes scanning the decrypted output as a tool result before it becomes trusted context, and says a fast-path regex would catch obvious authority-hijack phrasing such as "send the following to this URL" [11][12]. Read that as a claim about someone else's traffic. It transfers if the sandbox's output actually traverses that proxy as a tool result, and if the attacker's phrasing stays obvious. The attacker writes the plaintext and pays nothing to paraphrase it, so the second condition is the weak one.
The other half of the proposal is sturdier because it does not depend on reading the instruction at all. The source's gap analysis notes that nobody scrutinised the outbound tool call for exfiltration characteristics regardless of where its instructions came from [10]. A mid-conversation fetch to a fresh domain carrying a long query parameter is checkable without any opinion about the model's intent. Input filters and plaintext-trained classifiers cannot compete with that, since the input they see is ciphertext and the payload is opaque until it decrypts inside a sandbox they cannot inspect [9][15]. A guardrail that only reads plaintext is well matched to attackers who only send plaintext.
Two caveats on the evidence. This is one writeup describing Adversa AI's research, and the material carries no dates, no advisory numbers, and no response from either vendor [11]. And the Gemini result in it is a filter bypass rather than the same exfiltration, since the harmful content never appeared in plaintext at the filter layer [6]. That is a different failure with the same root: the decision about trust is being made at the wrong point in the pipeline.
