Skip to content

AI Workflow Audits

Researchers tricked an AI chatbot into stealing chat data by hiding instructions inside encryption. Here is what business owners should know before trusting a vendor's AI guardrails.

On August 20, 2026, security firm Adversa AI disclosed a technique it calls Cryptographic Context Injection: hide a malicious instruction inside encrypted text on a webpage, and an AI agent that decrypts it to summarize the page will treat the decrypted result as trusted, even though the identical instruction in plain text gets blocked. Against xAI's Grok, that let researchers exfiltrate a user's name, location, subscription tier, and full conversation history with a single, ordinary request. The direct answer for a business owner: this is not a reason to panic about one chatbot, but it is a clear demonstration that a vendor's guardrails may only inspect text going in and out, not what an AI agent does with the tools and code it runs on your behalf.

By Fabio Rabelo · Founder, ATLACIS ·

What happened

On August 20, 2026, Adversa AI, a security research firm, published a technical disclosure of an attack it names Cryptographic Context Injection. The setup is simple to describe and hard to defend against. An attacker builds an ordinary-looking webpage that contains an encrypted block of text, the key needed to decrypt it, and instructions telling an AI agent to decrypt that block using its own code-execution tool. A user asks Grok, xAI's AI chat agent, to summarize that page. Grok fetches it, follows the instructions, and runs the decryption itself inside its own Python sandbox. Once decrypted, the hidden instructions direct Grok to gather the user's name, approximate location, subscription tier, and the full set of prompts from the current conversation, and package that information into what looks like an additional "decryption key." Grok is then told to open a URL to "fetch additional context," a URL that has the packaged data attached as parameters. Grok's own navigation tool sends the request. The data lands in the attacker's server logs. In Adversa's demonstration, none of this required a click, a warning, or a confirmation step from the user. The part worth sitting with: the identical instruction, placed on the same page in plain, readable text, gets refused by Grok's existing guardrails. Only the encrypted version works. Adversa's researchers believe Grok's filter inspects text arriving from and leaving the model, but does not re-inspect the plaintext that the model's own code execution produces when it decrypts something. The ciphertext looks harmless to a text filter because a filter cannot read it. The decrypted instructions look harmless to the same filter because, by the time they exist, they are the model's own tool output, not incoming web content. Adversa reported the issue to xAI on June 3, 2026, both directly and through xAI's HackerOne bug bounty program. xAI acknowledged the report but gave no mitigation timeline, and further contact attempts in August drew no response. As of Adversa's public write-up, the technique still worked against Grok.com. Adversa also tested a related version against Google's public Gemini chat interface, where the same encryption trick was used to get Gemini to produce content its safety filters normally refuse, rather than to steal data, since Gemini's sandbox does not reach outside websites the way Grok's does.

Why it matters for business owners

Most owners think about AI chatbot safety as a single yes-or-no question: does the vendor have guardrails. This disclosure shows that framing is too simple. Grok has guardrails, and they work exactly as intended against the plain-text version of this attack. The gap is not an absence of safety work. It is a blind spot in where that safety work looks: at the text going into and out of the model, not at what happens inside the agent's own tool use once it starts running code or fetching pages on a user's behalf. That matters beyond any one product. If your business uses, or is considering, any AI assistant that can browse the web, run code, or call outside services while handling a real user's session, this is the exact category of risk that applies, regardless of which vendor's name is on it. And even if your company has no official policy on Grok, an employee may already have it, or a tool like it, open in a browser tab connected to a real account, summarizing a real document, with real session data sitting in its context.

What owners should not misunderstand

This is not evidence that Grok in particular is uniquely careless. Adversa demonstrated a related bypass against Google's Gemini too, using the same core idea, and frames Cryptographic Context Injection as one example of a broader pattern rather than a one-off bug in one company's product. Different vendors, same category of blind spot: guardrails built to classify text are not built to inspect what a model's own code execution decrypts or computes. It is also not evidence that encryption itself is the danger. The attacker in this scenario is not breaking any encryption. They are using strong, standard encryption specifically because a simple content filter cannot read ciphertext, which forces the AI system to do the decrypting itself and then, wrongly, trust its own output. And it is not something a vendor's general claim of 'we have prompt injection guardrails' resolves on its own. Adversa's own test showed that the plain-text version of the identical instruction gets blocked by Grok's existing filters. The unresolved layer is what happens after decryption, inside the model's own tool output, a separate stage a generic guardrail claim does not automatically cover. A business asking a vendor about AI safety needs to ask about that specific layer, not accept the word 'guardrails' as a complete answer.

The operational lesson

The lesson here is not to stop using AI agents that browse or run code. It is that the real risk has moved to a more specific place: not whether an employee might paste something sensitive into a public chatbot, but what an AI agent can already see in its own context, and what it is allowed to do with that information once it is running code or fetching pages without a person watching each step. Two separate questions decide how exposed a given AI tool is. First, what private data sits in its context: a name, an account, a document, a chat history. Second, what actions can it take on its own, without a human approving each one: opening a URL, calling an API, sending a message. The Grok exploit worked because both were true in the same agent at the same time: rich session data available to it, and an unsupervised action, opening a link, that could carry that data somewhere else. Either one alone is manageable. Together, in the same agent, they are the exposure.

What a serious business should do next

Before adopting, or continuing to rely on, any AI agent that can browse the web or execute code, ask the vendor a specific question: do your guardrails inspect only the model's direct text input and output, or do they also cover what happens inside tool calls and code execution. Push for a concrete technical answer, not a reassurance. Map, for every AI tool already in use across the business, two things: what private data it can see, whether that is customer records, internal documents, or conversation history, and what it can do without a person confirming the action first, whether that is opening links, calling outside services, or sending messages on someone's behalf. That mapping is the actual audit. A vendor's marketing page is not. Where it is practical, keep any AI agent that handles sensitive customer or business data separate from one that is browsing open, untrusted webpages in the same session. Treat 'can see private data' and 'can freely reach the open internet' as two permissions that should rarely sit on the same agent at the same time, the same way you would not give a single employee unrestricted access to customer records and unmonitored ability to email files to any external address. Do not wait for a patch before making that call. This specific technique against Grok remained unresolved more than two months after Adversa privately disclosed it, and there is no public timeline for a fix.

The Atlacis view

A vendor's claim that an AI tool has guardrails is not something a business owner should have to take at face value, and it is rarely one question with one answer. Atlacis helps owners slow down, map exactly what data a given AI agent can see and what it can do with it unsupervised, and decide where that combination is a real risk worth restricting, rather than adding or removing an AI tool based on a headline.

The short version

  • On August 20, 2026, Adversa AI disclosed a technique that hides malicious instructions inside encrypted text on a webpage, tricking Grok into decrypting and trusting them, then exfiltrating a user's name, location, subscription tier, and full chat history with no warning.
  • The identical instruction in plain text is blocked by Grok's existing guardrails. Only the encrypted version works, because the filter inspects text arriving from outside the model, not what the model's own code execution later decrypts.
  • Adversa demonstrated a related version of the technique against Google's Gemini, used there to bypass content safety filters rather than steal data, framing this as a pattern across vendors, not a single company's bug.
  • Reported to xAI on June 3, 2026, the issue remained unpatched as of Adversa's August 20 disclosure, more than two months later.
  • The real exposure is the combination of two permissions in one AI agent: access to private session data, and the ability to take unsupervised actions, like opening a URL, that can carry that data out.
  • Before adopting or continuing to use any AI agent that browses or runs code, ask the vendor whether guardrails cover tool execution output, not just direct text input and output, and map what data and unsupervised actions each AI tool in the business actually has.
Tags:AI securityprompt injectiondata exposureAI agentsvendor guardrailsAI governanceworkflow auditbusiness AI
FAQ

Common questions

Does this mean my business should stop using Grok or similar AI chat agents?
Not necessarily. The practical response is not to abandon AI agents but to know what any agent you use can see and what it can do on its own. If an agent has access to sensitive data and can also take unsupervised actions like opening links or calling outside services, that combination is the actual risk to evaluate, whichever vendor built it.
Is this just a Grok problem?
No. Adversa demonstrated a related version of the same technique against Google's Gemini, and frames it as one example of a broader gap: guardrails built to inspect text miss what happens inside an AI agent's own code execution or tool output. Expect this category of issue to surface against other AI agents with similar browsing or code capabilities.
What should I actually ask an AI vendor about this?
Ask whether their safety guardrails inspect only the model's direct text input and output, or whether they also cover the internal results of tool calls and code execution the agent runs on its own. A vendor that cannot answer specifically has not yet closed the gap this research exposed.
Keep reading

More from the blog

Google's AI agents found 100 critical vulnerabilities in stolen code in two days. Here is what business owners should know before trusting an 'AI-verified' security claim.

Google's Mandiant threat intelligence team disclosed an AI agent pipeline, built over 10 months on a decade of internal security work, that found more than 100 confirmed critical vulnerabilities in stolen corporate source code in two days. Every single finding still passed through a human before it counted. Here is what that detail means for how you evaluate any vendor's AI security claims.

Researchers just showed that AI models cannot reliably tell a real instruction from text that only sounds like one, and they think the flaw may be impossible to fully fix. Here is what business owners should know before giving an AI agent real access.

A peer-reviewed paper presented at ICML in July 2026 found that AI models decide whether to trust a piece of text based on how it is written, not on the security tag meant to label where it came from. Attackers who mimic the style of a trusted instruction can get models built by OpenAI, Anthropic, Alibaba, and DeepSeek to treat outside text as if it were their own reasoning or the user's own command. The researchers call this role confusion, and they say there is a real chance it cannot be fully solved with the way today's models are built.

Five Eyes intelligence agencies just warned that AI has changed the attack timeline. Here is what business owners should know.

On June 22, 2026, intelligence agencies from the US, UK, Canada, Australia, and New Zealand jointly warned that AI-powered attacks are no longer a future concern and that the window between a vulnerability being discovered and it being exploited is shrinking. Their direct message to boards and executives: cyber risk is a core business risk, not an IT problem. Here is what that means for owners who do not run an enterprise security team.

Make better AI decisions, starting with one call.

Book a free AI Fit Call. We will tell you what to use, what to avoid, and where to start. No jargon, no pressure.