AI coding tools are great at producing code that works, and "works" and "secure" are not the same thing. Research has repeatedly found that a substantial share of AI-generated code contains security weaknesses, and the reason is structural: models learn from public code that includes insecure patterns, they optimize for a working result, and they do not know your threat model. For mobile apps the effect shows up as hardcoded secrets, weak access rules, and insecure storage. The takeaway is not to avoid AI, but to treat its output as a draft to review. Here is why the vulnerabilities appear and how to ship AI code safely.
Short answer
Yes, AI-generated code commonly contains security vulnerabilities. Studies have repeatedly found that a significant portion of code produced by AI assistants includes weaknesses, because models are trained on public code that contains insecure patterns, they optimize for code that works rather than code that is secure, and they lack the context of your specific threat model. Per OWASP, the result is familiar issues like hardcoded secrets, injection flaws, weak cryptography, and missing access checks. The fix is not to avoid AI but to treat its output as a draft: review it, do not trust insecure defaults, and verify the result, since the model produced something functional, not something audited.
What you should know
- AI code often has vulnerabilities: a significant share contains weaknesses.
- It optimizes for working, not secure: functional output is not audited output.
- It learns insecure patterns: trained on public code that includes them.
- It lacks your threat model: it does not know what you need to protect.
- Treat it as a draft: review and verify before shipping.
Does AI-generated code have vulnerabilities?
Yes, and the reasons are built into how these tools work. Research on AI coding assistants has consistently found that a meaningful fraction of generated code contains security flaws, and that developers using AI assistance sometimes produce less secure code while feeling more confident about it. Three structural causes drive this. First, models are trained on large amounts of public code that includes plenty of insecure examples, so they reproduce those patterns. Second, they are optimized to produce code that satisfies the request and runs, and security is not the same objective as functionality, so a working result can still be insecure. Third, the model does not know your application's threat model, what data is sensitive, what must be protected, what an attacker would target, so it cannot make the judgment calls security depends on. The output is plausible and functional, which is exactly why its weaknesses are easy to miss.
What vulnerabilities does AI commonly introduce?
The same categories that show up in insecure code generally. The table lists the frequent ones.
| Vulnerability | How it appears in AI output |
|---|---|
| Hardcoded secrets | Keys or tokens embedded in the code |
| Injection flaws | Unsanitized input in queries or commands |
| Weak or misused cryptography | Outdated algorithms or hardcoded keys |
| Missing access checks | Endpoints or data without authorization |
| Insecure defaults | Permissive configuration left as generated |
For mobile apps specifically, these surface as a key hardcoded in the client, a database left open because access rules were generated as permissive, sensitive data written to insecure storage, or cleartext network calls. None of it looks wrong at a glance, because the app runs; the weakness is in what the code does not do, validate, restrict, encrypt, rather than in an obvious bug.
How do you ship AI-generated code safely?
Treat it as a starting point and put a security step between generation and release. Review the code with security in mind rather than only checking that it works, paying attention to the categories above, secrets, input handling, access control, crypto, and configuration. Do not trust insecure defaults; the model often leaves permissions broad and storage plain because that is the path of least resistance. Move real secrets to your backend, enforce access server-side, and use proper secure storage and strong standard crypto. For anything sensitive or production-facing, add a human security review, since the model cannot reason about your threat model. And verify the built artifact, not just the source, because the question that matters is what actually ships. AI accelerates the writing; the security judgment is still yours to apply.
What to watch out for
The first trap is trusting AI code because it works and looks clean, when functional and secure are different properties and the weaknesses are in what the code omits. The second is shipping insecure defaults, broad permissions, plain storage, embedded keys, that the model produced for convenience. The third is assuming a future review will catch it, which often does not happen before launch. A pre-submission scan such as PTKD.com (https://ptkd.com) reads your compiled APK, AAB, or IPA against OWASP MASVS and surfaces hardcoded secrets, insecure storage, cleartext traffic, and related issues, giving you an objective check on what the AI-generated code actually shipped. That turns "it works" into "it is verified."
What to take away
- Yes, AI-generated code commonly contains security vulnerabilities, because models optimize for working code, learn insecure patterns, and lack your threat model.
- The common issues are hardcoded secrets, injection flaws, weak cryptography, missing access checks, and insecure defaults.
- Treat AI output as a draft: review it for security, do not trust insecure defaults, keep secrets server-side, and add a human review for sensitive code.
- Verify the built artifact with a pre-submission scan such as PTKD.com, so you ship something checked rather than just functional.
