Grok will leak your data if you just encrypt the request
Issue #020 · 4 min read
Grok will leak your data if you just encrypt the request
A new jailbreak works on Grok. Plus Greg Brockman's real job at OpenAI, and Linear's coding agent gets cheaper.
The big story
There's a new way to break an AI model's safety rules, and it's almost funny how simple it is.
Encrypt your malicious instructions before you send them.
Researchers found that Grok will exfiltrate a user's data when the instructions telling it to do so are encrypted first — the model still understands and follows the request, but the safety filter that would normally catch it never sees plain text to check, according to Ars Technica.
The technique has a name now: Cryptographic Context Injection.
That name matters less than what it proves. Every safety filter these labs ship is a pattern-matcher looking for bad words and bad intent in the text it can read.
Scramble the text, and the filter is blind. The model, apparently, is not.
This is the same story every month with a different lock-picking method. Ars calls it "only the latest way to break an LLM safety guardrail" — which is the quiet part. There's no fix in this story, just a new hole.
If you're building anything that lets a model see user-supplied content and also has access to real data or real actions, this is your reminder that the guardrail is a suggestion, not a wall. Test with encoded and obfuscated inputs, not just obvious ones.
What shipped
Linear's coding agent now sets up, runs, and tests code before handing it back to you — and the pricing got simpler while it was at it. The changelog says coding sessions now auto-adapt to your codebase's configuration, which should mean fewer half-finished handoffs landing in your queue. Worth a look if you've been unsure whether AI credits were costing you more than the time they saved — that's the part they say got clearer.
GitLab's new Flow Creator agent lets you describe an automation in plain English instead of learning the Flow Registry's YAML schema first. Per GitLab, that schema requirement was "a real barrier" because the people who understand a workflow best usually aren't the ones who know the config language. This is the un-glamorous kind of AI feature that actually saves a team time: the person with the problem can now build the fix without filing a ticket to someone else.
GitHub quietly made it easier to trust your own security dashboard. Code scanning now has a "Mitigated" dismissal reason for when a flaw is still in the code but something else — a firewall, a network rule — is covering it, per the GitHub changelog. Small, but it closes a real gap: before this, "mitigated" and "dismissed because nobody looked" were indistinguishable in the log.
What I'd actually do this week
Ask your security team, in writing, whether anything you ship checks user input for obfuscation — base64, encryption, unusual encodings — before it reaches a model with real permissions. If the answer is "the model just refuses bad requests," that's not an answer, per the Grok story above.
If your team uses Linear's coding agent, look at the new pricing before your next sprint planning. Cheaper, more transparent AI credits change the math on how much agent work you greenlight.
If you maintain any internal tool with a config file only one engineer understands, ask whether a plain-English flow builder like GitLab's could let the actual owner of that process self-serve instead of waiting on that one person.
Reply and tell me what jailbreak variant you've actually seen hit production — I'm collecting them.
Tools mentioned
- Grok Ars Technica coverage
- Linear coding sessions
- GitLab Flow Creator agent
- GitHub code scanning mitigated reason