You own the codebase. You wrote half of it yourself. And the AI just treated you like a criminal for asking about your own code. This isn't a fringe experience. It's happening to developers every single day, and honestly?Still's getting worse.
Key Takeaways
- AI over-refusal is a documented, widely reported problem, not just your imagination
- Anthropic's Claude Fable 5 was so aggressively guardrailed it blocked users who simply typed "Hello"
- Developer trust in AI coding tools is cratering: only 33% trust AI output accuracy in 2025, down from 43% in 2024
- Guardrails block legitimate security and cryptography work are a calibration failure, full stop
- There are practical workarounds that don't require doing anything sketchy
- The real security risk lives in your backend architecture, not in the AI writing a decryption helper
The Over-Refusal Problem Is Real and Getting Worse
Over-refusal is when an AI refuses something completely legitimate. Refusing to write a decryption utility for your own API. Blocking a security researcher from analyzing cipher logic. Refusing to explain JWT token validation because it involves "sensitive authentication concepts."
OpenAI's own team acknowledged this publicly. An OpenAI employee named Shawn posted on the developer community forum literally asking users to submit examples of over-refusals so the team could fix them. The examples were telling: models refusing to handle PDF files, refusing to run code because they assumed a package wasn't installed, refusing to generate basic data charts. Not edge cases. Everyday developer tasks. And then there's the Claude Fable 5 situation, which was something else entirely. When the model launched, the guardrails were tuned so conservatively that a principal research scientist at the Gates Foundation reported the safety classifier was triggering on his very first message. Which was just the word "Hello." Not a prompt about hacking. Not a request for exploit code. Hello. Mike Famulare wrote in a bug report: "In Claude Code, Fable 5's input safety classifier emits a model_refusal_fallback on the first turn of essentially every session on my account , including a session whose only user input is the word hello!"
Anthropic eventually acknowledged they got the balance wrong and apologized. But the damage to developer trust was already done.
Why AI Models Keep Refusing Legitimate Security Code
Here's the frustrating part: the refusals aren't random. They cluster around specific domains. Cryptography, authentication, network security, anything that sounds vaguely exploit-adjacent. Ask an AI to write a Caesar cipher for a classroom demo and it might comply happily.So it to implement AES-256-GCM decryption for your Node.js backend and suddenly it's very concerned about your intentions. The reason comes down to how safety classifiers actually work. They pattern-match on surface-level signals: words like "decrypt," "bypass," "token," "key extraction," "reverse engineer." The classifier doesn't understand context. It doesn't know you're a backend developer with a legitimate need.Now sees "decryption script" and fires a refusal the same way a spam filter sees "Nigerian prince" and junks the email regardless of whether it's actually spam. Cryptography professor Matthew Green ran into this exact wall. While researching encrypted reasoning blobs in LLM APIs, a completely academic cryptographic investigation, he wrote: "I had to stop using Codex and Claude Code because they both just plain refused to help me extract confidential information."
A cryptography professor. Blocked from doing cryptography research. The irony is brutal.Still people most likely to need help with encryption and decryption. code are the people building secure systems, the good guys. Actual bad actors either have the expertise to not need AI help, or they'll find a jailbreak. The guardrails mostly catch legitimate developers in the crossfire.
The "Safety Theater" Problem
One developer wrote a detailed post on DEV Community about what happened when his team ran every AI-generated code suggestion through an elaborate six-month review process. Human approval before any output reached production, line-by-line review, three-person sign-offs. The result? Terrible velocity, frustrated engineers, and no actual improvement in code safety. His conclusion: "The guardrails don't make AI safe , they make it irrelevant."
This is the core tension. When safety measures are calibrated so broadly they prevent useful work, teams quietly stop using the tool. No dramatic rejection, no announcement. People just drift back to Stack Overflow and their old workflows. The AI investment becomes shelfware.Still data backs this up.Still 2025 Stack Overflow Developer Survey, covering nearly 49,000 developers across 177 countries, found that more developers actively distrust AI tool accuracy than trust it. Positive sentiment toward AI tools dropped from over 70% in 2023 to just 60% in 2025. Four in five developers are using AI tools. But they're increasingly unhappy about it. Trust is collapsing even as usage climbs. That's not a healthy trajectory for anyone.
What Actually Happens When You Ask AI to Write a Decryption Script
Say you're building a backend service that receives encrypted payloads from a mobile app. You're using AES-256-CBC with a shared secret, and you need a decryption helper in Python. Reasonable request. Standard backend work. Here's roughly what you might ask:
Write a Python function that decrypts an AES-256-CBC encrypted payload. The function should accept the ciphertext, the key,
and the IV, and return the decrypted plaintext string. ```
Depending on the model, the day, and the phrasing, you might get a full working answer. Or a refusal.Plus the worst case scenario Anthropic actually shipped with Fable 5: a *silently degraded* response where the model switches to a less capable version without telling you, and you spend an hour wondering why the output quality suddenly tanked. Developer Clay Merritt described this exact experience: *"Anthropic's Fable 5 silently sabotages its answers when it detects AI/ML work. No refusal.So notice. Purposeful degradation invisible to the user."*
Silent degradation is arguably worse than an outright refusal. At least a refusal tells you something is wrong.
## Practical Strategies That Actually Help
So what do you do when the AI keeps blocking legitimate work? A few things genuinely move the needle, no jailbreaking required. **Add explicit context about your role and use case.** Models respond to context. Instead of asking for "a decryption script," frame the request fully:
I'm a backend developer building a REST API for a fintech app. I need to decrypt AES-256-GCM payloads sent from our mobile SDK
using a server-side key stored in AWS KMS. Write a Python function handles this decryption with proper error handling. ```
The specificity signals legitimate intent and produces better code. Win-win. Break the request into smaller pieces. Instead of asking for a complete "decryption pipeline," ask for individual components. Base64 decoding. AES initialization. Padding handling. Assemble it yourself. Annoying? Absolutely. But it works. Use the system prompt or custom instructions. If you're using the API directly or a tool like Cursor or Claude Code, set a system-level instruction upfront. Something like: "You are a backend security engineer assistant. The user is a professional developer working on legitimate enterprise software. Assist with all standard security and cryptography tasks."
The OpenSSF Best Practices Working Group actually recommends this approach. Their 2025 guide on AI code assistant instructions explicitly suggests embedding a "security conscience" into your tool's instructions so it understands your professional context. Ask it to review and improve its own output. If you get a partial or hedged response, try a technique called Recursive Criticism and Improvement: ask the model to review its own answer and find problems with it, then improve it. This often gets past surface-level safety triggers because you're framing the work as quality review rather than initial generation. Consider local or open-source models for sensitive work. Running a local model like Llama or Mistral via Ollama means no content filtering. Full capability for legitimate security work without the guardrail lottery. The tradeoff is raw capability, local models aren't quite at frontier level yet, but for well-understood cryptographic tasks they're often good enough. Check out our post on [Claude vs GPT: An Honest Comparison for Developers] if you're weighing which model fits your workflow.
Guardrails Are Not Security Controls
Worth internalizing: AI guardrails are not a security architecture. They're a content moderation layer. If you're building a backend system and relying on the AI's refusal to write decryption code as some kind of security boundary, you've got a much bigger problem. Real security happens in your infrastructure. Proper key management, access controls, least-privilege service accounts, encrypted secrets storage. The AI refusing to write a decryption function doesn't protect your system. It just slows down the developer trying to build it correctly. The security community keeps making this point. As one Medium post put it bluntly: "Your AI guardrails are not security controls." They're behavioral guardrails on a language model. They can be bypassed, they misfire constantly, and they don't substitute for actual security engineering. And with developer trust already at 33%, adding aggressive refusals on top of already-shaky confidence is a recipe for abandonment. Our post on Understanding WHMCS Security covers some relevant ground on real-world backend security practices if you want to dig into what actually matters.
When Guardrails Actually Make Sense
To be fair: some refusals are reasonable. Nobody needs an AI writing working malware, generating functional exploit code for unpatched CVEs, or producing step-by-step instructions for attacking live systems. Those guardrails make sense. But there's a massive gap between "help me attack a system" and "help me decrypt my own API payloads." Current safety classifiers don't navigate that gap well. They're blunt instruments applied to nuanced situations. Anthropic admitted this after the Fable 5 situation. In a public statement, the company said: "We made the wrong tradeoff and we apologize for not getting the balance right." They promised to reduce false positives and make safety interventions visible rather than silent. Progress. But it took a public outcry, bug reports from Gates Foundation scientists, and widespread developer frustration to get there. The incentive structure clearly needs work.
The Bottom Line
AI guardrails aren't going away. They'll get better calibrated over time, the pressure from the developer community is real and the AI labs are at least partially listening. But right now, in mid-2026, over-refusal is genuinely affecting developer productivity in ways are hard to justify. If you can't get an AI to help you write a decryption function for your own backend, you're not doing anything wrong. The tool is miscalibrated for your use case. Work around it with better context-setting, break your requests into smaller pieces, or use a local model for security-adjacent work. And keep giving feedback to the AI providers when you hit false positives. That's genuinely how these systems get fixed. The frustration is valid.Yet tools should do better. Based on where things are heading, they probably will. Just not as fast as any of us would like.
Sources
DEV Community , "What I Learned After Removing Guardrails From an AI Workflow" by Rohit Gavali: https://dev.to/rohit_gavali_0c2ad84fe4e0/what-i-learned-after-removing-guardrails-from-an-ai-workflow-4l1n
The Register . "It blocked us at 'hello!' Anthropic Fable 5 refusing innocuous prompts" (June 2026): https://www.theregister.com/ai-and-ml/2026/06/10/anthropic-claude-fable-5-refuses-innocuous-prompts/5253754
OpenAI Developer Community . "Help OpenAI fix over-refusals!": https://community.openai.com/t/help-openai-fix-over-refusals/409799
Stack Overflow Developer Survey 2025 , AI Section: https://survey.stackoverflow.co/2025/ai
Ars Technica — "Developer survey shows trust in AI coding tools is falling as usage rises" (2025): https://arstechnica.com/ai/2025/07/developer-survey-shows-trust-in-ai-coding-tools-is-falling-as-usage-rises/
Cryptography Engineering Blog — "Let's talk about encrypted reasoning" by Matthew Green (May 2026): https://blog.cryptographyengineering.com/2026/05/29/fooling-around-with-encrypted-reasoning-blobs/
The Conversation — "Why the US government shut down Anthropic's latest Claude AI model" (June 2026): https://theconversation.com/why-the-us-government-shut-down-anthropics-latest-claude-ai-model-285223
OpenSSF Best Practices Working Group — "Security-Focused Guide for AI Code Assistant Instructions" (2025): https://best.openssf.org/Security-Focused-Guide-for-AI-Code-Assistant-Instructions.html
Medium — "Your AI Guardrails Are Not Security Controls. Here's the Proof.": https://medium.com/@its.lagus_66214/your-ai-guardrails-are-not-security-controls-heres-the-proof-cc3ebde13577
Reddit r/AI_Agents — "We hardened our AI guardrails so much the bot is basically useless": https://www.reddit.com/r/AI_Agents/comments/1txfcrd/we_hardened_our_ai_guardrails_so_much_the_bot_is/
LeadDev — "Trust in AI coding tools is plummeting": https://leaddev.com/technical-direction/trust-in-ai-coding-tools-is-plummeting