What security headaches has AI introduced in your projects lately? (2026 edition)

[P-r-e-m-i-u-m]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Code quality

Discussion Details

Yo folks,
Been grinding with AI coding tools heavy this year (Cursor, Claude, Copilot, whatever) and man... the speed is insane, but the security side is giving me serious anxiety 😩
Security was already a top pain for most teams, but AI has thrown a whole new bag of problems on top:

AI spits out code with OWASP Top 10 vulnerabilities like it's nothing (heard some reports saying ~45% of generated code has serious flaws, especially in Java). "Vibe coding" sounds cool until you realize half your codebase is now insecure as hell.
Secrets leaking left and right — AI suggesting code that hardcodes stuff or exposes creds in logs/workflows.
Data privacy nightmare: When you paste chunks of your code or sensitive data into these tools, where does it actually go? Training data? Compliance audits? In regulated industries this is becoming a total headache.
GitHub Actions side is still messy too — dependency tags getting hijacked, secrets inheritance being too loose, reusable workflows blasting creds everywhere. GitHub dropped some 2026 roadmap stuff about scoped secrets and dependency locking, but until that's fully here, we're all playing with fire.

Personally, I've caught AI-generated code introducing SQL injection risks and bad auth patterns that I almost merged. Also had to start being super strict about what I feed into the AI because of privacy concerns (GDPR, client data, etc.).
So real talk — what's the biggest security mess AI has caused in your projects this year?

Random vulnerabilities sneaking into prod?
Compliance/audit panic because "the AI wrote it"?
Shadow AI tools devs are using without telling security?
Or GitHub Actions specific drama (secrets, supply chain stuff)?

Drop your war stories, what you're doing to fix it, or tools/workflows that actually help. Let's share some practical tips instead of just complaining 😂
Would love to hear from both devs and security folks here. @github

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[tvibe7817-arch]

everyone — the "vibe coding" vs security reality check is so real.
The biggest headache I've seen isn't just the bugs in the code, it's the context contamination. I had a teammate paste a whole .env file into a web-based LLM just to debug a config issue. He didn't realize that data is gone forever, potentially training their models. Compliance team went nuclear when they found out.
On the Actions side: AI loves suggesting complex curl | bash one-liners to "fix" dependencies. That is literal malware delivery in waiting.
The fix? Treat AI like a junior dev who wants to sudo rm -rf to fix a bug. Review every single character, run gitleaks on every PR, and for god's sake, configure your pre-commit hooks to scream if it detects an API key format.

[Lucky3mc]

That .env file story is painful and way too common. Treating AI like a junior dev who doesn't understand context is the right mental model. Most teams default to Snyk(snyk.io) for catching this stuff. Solid dependency scanning, huge database, good GitHub integration. But Snyk alone misses the pattern-based issues AI loves to generate the SQL injection, the bad auth logic, the hardcoded secrets in old commits. And at scale, the noise and pricing become real problems. What made a difference for me was pairing a dependency scanner with
something that runs multiple engines in parallel. I use Debuggix 9 engines (Semgrep, Bandit, Gitleaks, Trivy, and 5 others) in one scan (debuggix.space). Single-engine tools have blind spots. When three engines flag the same injection pattern, you know it's real. When only one flags it, you know to deprioritize. Also catches secrets in git history, which Snyk's standard scanning doesn't cover. AI agents pull in old config patterns all the time. Free tier is 10 scans a month. Worth running alongside Snyk to catch what the single-engine approach leaves behind.

[mallasiddharthreddy]

The one that gets me is when an agent makes a call using a shared API key and something goes wrong, there is no way to prove what it was authorized to do. Researching this problem right now, if anyone has dealt with it: https://kya-survey.vercel.app/

[armorer-labs]

The shared API key case is the one I would prioritize, because it turns an agent failure into an attribution failure.

The pattern that helps is to stop treating the key as the proof of authority. A shared service credential should be only the transport credential; every agent/tool action still needs a separate decision record:

• human or service principal that initiated the task
• agent/run/turn id
• normalized tool name and normalized argument hash
• resource and side-effect class: read, write, external message, spend, deploy, delete
• policy version and decision: allow, deny, require approval
• approval id if a human approved it
• output/action digest so the final effect can be tied back to the decision

For higher-risk tools, issue short-lived scoped credentials per action or per tool call rather than letting the agent reuse the broad key directly. Even if the downstream system still sees one service account, your control plane can answer: who requested this, what was it allowed to do, why was it allowed, and what actually happened.

The headache AI added for us is not just vulnerable code generation; it is agents turning one broad credential into many hard-to-reconstruct side effects.

[mallasiddharthreddy]

this is a really good breakdown honestly. the attribution failure framing is spot on, the key proves the account but nothing proves the agent. we are looking at the other side of this problem, basically giving APIs a way to verify who the agent actually is at the gateway level instead of just trusting whatever credential shows up. sounds like you are coming at it from the runtime side which is super interesting. would love to compare notes sometime if you are up for it

[Ar9av]

two concrete headaches we kept hitting: (1) AI suggests code that hardcodes credentials, and (2) agents pass real secret values as arguments to shell tools even when you think they're "just reading files". we built immunity-agent to address both, secret cloaking prevents real values from ever appearing in tool calls, and the Warden hook layer blocks dangerous commands at the process level. open source, works with Claude Code / Cursor / Codex / Windsurf

[Keesan12]

Biggest headache for us hasn't been "AI wrote vulnerable code" in the abstract. It's agents moving sensitive data across boundaries in places normal reviews miss: secrets passed as shell args, pasted into logs, broad credentials reused across runs, and tools that were safe for humans but unsafe when called 40 times by an autonomous loop.

The controls that actually helped:

• ephemeral, scoped creds per run instead of shared service accounts
• secret redaction at the tool boundary, not just in app logs
• a denylist or approval gate for high-risk commands and outbound actions
• a run receipt that records files/data touched, external actions attempted, checks run, and the explicit stop reason

Without that last piece, compliance turns into archaeology after the fact. With it, you can at least answer "what did the agent try to do, with what authority, and why did it stop?"