# When You Speak in Code, AI Safety Doesn't Listen


Safety filters assume the threat speaks plainly. Researchers just proved that assumption is catastrophically wrong.


Two of the largest AI platforms — Google's Gemini and xAI's Grok — can be manipulated into bypassing their own content guardrails by a deceptively simple technique: hide the harmful request behind a layer of encoding. Wrap your prompt in Base64, ROT13, or even a custom cipher, and the safety layer often sees noise while the underlying model sees instructions. And it complies.


## The Gap Between the Filter and the Model


To understand why this works, you have to understand what AI safety guardrails actually are — and what they aren't.


In most production deployments, safety systems operate as a pre-processing or post-processing layer. They scan input text for signals of harmful intent: certain keywords, patterns, semantic clusters that suggest the user is asking for something prohibited. It's essentially a sophisticated content classifier bolted onto a much more capable language model underneath.


The problem is that the classifier and the language model don't process text the same way.


When a user submits a Base64-encoded prompt, the filter might see SGVscCBtZSBzeW50aGVzaXpl... — meaningless characters, no threat signal. But the language model, trained on enormous corpora that include programming tutorials, documentation, and code, recognizes the encoding immediately. It decodes it, processes the underlying request, and responds — as if the safety layer wasn't there at all.


This isn't a bug in Base64. It's a structural gap. The filter and the model have fundamentally different interpretations of the same input.


## Grok and Gemini Weren't Alone


Researchers documented this behavior across both platforms, but the technique is neither new nor unique to these two systems. Prior jailbreak research targeting GPT-4 and Claude demonstrated similar encoding bypasses as far back as 2023. What's significant here isn't novelty — it's persistence.


Despite years of awareness, despite detailed public disclosure of encoding-based attacks, two of the best-funded and most actively developed AI systems in the world shipped with this gap exploitable in production. That's not a research curiosity. That's a statement about where the industry's safety priorities actually land.


Grok's case carries extra weight given xAI's positioning. The company has marketed Grok as a less-restricted, more "honest" alternative to its competitors — which in practice has translated to thinner guardrails from the start. Researchers finding encoding bypasses in Grok is less surprising than finding them in Gemini, which Google has spent considerable effort hardening, particularly after early jailbreaks generated embarrassing headlines.


## What Attackers Actually Do With This


Let's be specific about the threat model, because "bypassing AI safety guardrails" can sound abstract.


The realistic harm scenarios break into a few categories:


Malware generation. Language models can produce functional code. Encoding-based bypasses allow actors to request working exploit code, credential harvesters, or ransomware components through platforms that would normally refuse such requests. The resulting code isn't different because the prompt was encoded — it's just as functional.


Social engineering content. Phishing lures, spear-phishing email templates targeting specific industries or personas, disinformation at scale. A model that refuses to write a convincing fraud email in plain English will write it in encoded English.


CSAM and extremist content. The researchers explicitly noted that encoding bypasses could be used to generate content in categories with the most severe legal and ethical consequences. This is why disclosure to Google and xAI was presumably part of this research process, though details on patch timelines aren't yet public.


Enterprise misuse. Many companies deploy Gemini and Grok via API in internal tooling. An employee or external attacker with API access who knows this technique can extract capabilities the organization assumed were disabled.


## How You Encode Around a Safety Net


The specific mechanics vary, but the general pattern is consistent:


  • Standard encoding schemes: Base64 and hexadecimal are the simplest — widely understood by models, invisible to naive filters
  • Historical ciphers: ROT13, Caesar shifts — trivial to reverse, recognizable to models with broad training data
  • Unicode tricks: Using lookalike characters, combining marks, or right-to-left override sequences to disguise words at the character level
  • Custom instructions: Asking the model to first interpret a fictional "alien language" where certain terms mean certain things — a semantic encoding rather than a cryptographic one
  • Layered approaches: Combining encoding with roleplay or hypothetical framing to add another filter-confusion layer

  • The escalating creativity here isn't surprising. It mirrors SQL injection research from twenty years ago: once attackers knew the filter was looking for specific patterns, they systematically found every way around those patterns.


    ---


    ## HackWire Analysis


    The encoding bypass research landing on Grok and Gemini in the same disclosure cycle feels like a stress test the AI industry has been avoiding.


    Here's the pattern that matters: every time researchers probe AI safety systems at scale, they find that the defenses are shallow — optimized against the obvious attack, brittle against anything creative. Encoding bypasses represent the low end of the sophistication spectrum. These aren't multi-week red team engagements or nation-state-tier techniques. They're the kind of thing a curious undergraduate figures out on a Tuesday afternoon. If this works in production, what's working that we haven't found yet?


    The structural problem is that AI companies are simultaneously racing to increase model capability while bolting safety measures onto systems not architecturally designed for them. You can't filter your way to safety when the thing you're filtering doesn't share a vocabulary with the thing you're protecting. Gemini can understand dozens of encoding schemes because being broadly knowledgeable is the entire point of the product. Asking a safety filter to match that coverage is an arms race the filter was never going to win.


    For defenders operating in enterprise environments where Gemini or Grok is deployed via API or integrated into internal tools: encoding bypass testing should be part of your red team checklist now, not after the next disclosure. Specifically — if you've deployed these models with "safe mode" settings and assume that's enforced, test it. Submit encoded requests through your own tooling. See what comes back.


    Longer term, the industry needs to move toward architectures where safety isn't a filter layer — it's embedded in how the model reasons, not just what the model sees. Constitutional AI approaches, RLHF with adversarial encoding examples in the training loop, and runtime monitoring that interprets decoded content rather than raw input are all directions worth funding. Right now, most production deployments aren't there.


    The gap between the filter and the model is where attacks live. Researchers just put up a sign.


    — HackWire Editorial


    ---


    ## Related Coverage


  • Read more in our [Ransomware](https://www.hackwire.news/category/ransomware) coverage
  • Cross-reference with [Breaches](https://www.hackwire.news/category/breaches) and [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)