A web page told an AI agent, in plain English, to run a shell command, and the agent refused. The same page, with the same words wrapped in a few chat-format control tokens, got the command executed.
At AG Tech Consulting, our advice to clients running agents on self-hosted models is to strip or escape chat-control tokens from every tool result, web page and email before it reaches the model, and to prove it with a tokenizer test.
What the researchers showed
On 24 September 2026, CVE-2026-61732 was published for Decepticon, an open-source AI agent built for red-team hacking work. It carries a CVSS score of 10.0, the maximum.
The agent crawls target websites and passes the results to its model as tool output. Before version 1.1.17, it did not clean that text.
Researchers from the Institute of Information Engineering at the Chinese Academy of Sciences ran a paired test. Both pages carried the same fake instruction to create a marker file. The plain-English version was flagged as suspicious and refused. The version wrapped in ChatML tokens such as <|im_start|>system was obeyed.
Why a few tokens change everything
Chat models do not see roles as words. They see special token IDs that mark where a system, user or tool turn starts and ends.
If untrusted text containing those literals is tokenized as real control tokens, the model sees a new system turn, not text inside a tool result. To the model, the attacker is now the operator.
The advisory says hosted APIs from OpenAI, Anthropic and DashScope strip these literals on their side. Many self-hosted stacks, including vLLM, SGLang and Ollama, do not by default. vLLM declined a fix in April, calling it out of scope for the inference layer. So the fix lands on whoever builds the agent.
Same week, different trick
On 1 October, Salt Labs showed that Manus, an AI agent platform, could be hijacked with one email. Plain instructions, “trust me” appeals and Base64 payloads were all blocked. A payload in JSFuck, an obscure JavaScript encoding, was decoded and run with Node.js.
Manus did raise a security warning, but only after the code had already run. The sandbox held the user’s Gmail OAuth token, and tokens for connected Google Drive and GitHub accounts sat in environment variables. Salt says the flaw has since been resolved.
The common thread
Both guardrails did well against attacks written in plain language. Both failed one layer below it: the tokenizer in one case, a code runtime in the other.
A guardrail that reads meaning cannot catch an attack that lives in structure.
Five checks for your agent stack
Escape control tokens for every model family you run: ChatML, Llama 3, Gemma and Mistral formats, plus Unicode lookalikes such as the fullwidth vertical bar. Clean at the boundary, just before web pages, emails, tool results and command output enter the prompt. Test at the tokenizer. Count role-opening tokens before and after a hostile input. The number should not change. Treat decoding untrusted content as running code, and put the approval check before it, not after. Keep secrets out of the sandbox. Do not pass tokens for unrelated services through environment variables.
The skeptical note
Decepticon is a niche red-team tool, and the advisory says the flaw is not currently exploitable against hosted vendor APIs. Salt says the Manus issue is resolved.
But the pattern matters for any business moving from a hosted API to a self-hosted model to cut cost or keep data in-country. Protection you got for free from a vendor may not move with you.
Sources
CVE-2026-61732 record: https://www.cve.org/CVERecord?id=CVE-2026-61732
Decepticon security advisory: https://github.com/BitterSecurity/Decepticon/security/advisories/GHSA-g5f9-3xfg-p9mf
Salt Labs, “How We Hijacked an AI Agent With a Single Email”: https://salt.security/blog/how-we-hijacked-an-ai-agent-with-a-single-email
Originally published on LinkedIn in the Your CTO Advisor newsletter: read and comment on LinkedIn →
