The real security risks in AI-generated code are well documented - SQL injection, exposed secrets and API keys, broken authentication, and insecure dependencies show up consistently across independent research. Almost everything written about this is aimed at security teams inside companies already running one. This page is aimed at the other audience: a non-technical founder who isn't going to run a security program, but does need to know what to ask a platform before building something real on it.
This is a genuinely crowded topic, most of what's written here comes from security vendors, and it's good, careful material. It's just not written for someone deciding whether to launch a product, and the founder's answer is: don't try to become a security expert, pick a platform that removes the riskiest decisions from your hands by default, and know the few questions worth asking regardless of platform.
We don't think a non-technical founder should have to understand SQL injection, secret management, or authentication architecture just to launch an app safely. That's why we think the most important security decisions should be handled by the platform by default, rather than left for someone to discover through a prompt after something goes wrong.
That principle shapes how we think about building Greta: reduce the number of security-sensitive decisions the user has to make, provide safer defaults for things like authentication and backend infrastructure, and put guardrails around areas where generated code can introduce risk. AI can make building software dramatically more accessible, but making the code easier to generate shouldn't mean making security the founder's responsibility.
The real risks, honestly
Independent security research on AI-generated code consistently finds the same handful of problems, not a single sensational one:
- Exploitable vulnerabilities in generated code. Multiple independent studies have found a meaningful share of AI-generated code samples containing exploitable security flaws when tested against standard vulnerability checks.
- Exposed secrets and API keys. Repositories built with heavy AI-tool usage have been found more likely to leak credentials than average - a real, measurable pattern, not a hypothetical.
- SQL injection and broken authentication. These remain common in generated backend code when a model isn't specifically guided toward safe patterns, the same OWASP Top 10 categories that have caused problems in hand-written code for two decades, not a new category of risk.
- Hallucinated dependencies. AI coding tools sometimes reference packages that don't exist or aren't what the model assumes, an emerging risk specific to AI-generated code, since an attacker can register a hallucinated package name and have it silently installed.
- Insecure defaults and overly permissive access. Generated code frequently gets the "happy path" working without necessarily locking down who can access what.
None of this means AI-generated code is uniquely dangerous compared to code a junior developer writes without review - the research consistently finds the same categories of mistake, just at meaningful scale because so much more code is now being generated. The fix isn't avoiding AI-assisted development. It's the same fix that's always applied to any code nobody senior has reviewed: review it, or use a system that removes the decision from the builder's hands by default.
What a founder should actually ask, not what a security team should implement
Most existing coverage of this topic is written as a checklist for security engineers - CI/CD scanning, RBAC audits, secrets rotation policies. A non-technical founder isn't going to implement any of that directly. What actually matters at the founder level is narrower:
- Does the platform generate auth and data-handling code with safe defaults, or does it leave that entirely to the prompt? This is the single highest-leverage question - a platform that handles auth correctly out of the box removes most of the risk above without you doing anything.
- Are secrets and API keys handled by the platform, or exposed in code you can see and accidentally commit somewhere public?
- Is there any human or automated review step before code goes live, or does a prompt go straight to production?
- If something goes wrong, can you actually get help is there documentation, support, or a community that's dealt with the same platform's specific behavior?
Risk summary
| Risk | How it shows up | What actually mitigates it |
| Exploitable code patterns | SQL injection, broken auth in generated backend logic | Platform-level safe defaults for auth/data access, not manual review alone |
| Exposed secrets | API keys committed in generated code or config | Platform-managed secrets/environment variables, not hardcoded values |
| Hallucinated dependencies | A referenced package that doesn't exist or isn't what it claims | Platforms that pin and vet dependencies rather than installing whatever a model names |
| Overly permissive access | Working "happy path" with no real access control | Real auth/RBAC generated by default, not bolted on later |
Got an idea? Build it now!
Just start with a simple prompt. No coding required — Greta.sh turns your idea into a working app in minutes.
Frequently asked questions
Is AI-generated code less secure than code written by a human developer?
The research doesn't show AI-generated code as a categorically new kind of risk, it shows the same familiar categories of mistake (SQL injection, broken auth, exposed secrets) appearing at meaningful scale because so much more code is now AI-generated. The mitigation is the same one that's always applied to unreviewed code: review it, or use a platform that removes the riskiest decisions from the builder by default.
What security risks should a non-technical founder actually worry about?
Four things cover most of the real risk: whether the platform handles authentication and data access safely by default, whether secrets/API keys are exposed anywhere you could accidentally make public, whether there's any review step before code goes live, and whether help is available if something looks wrong. Most other security-focused advice online is written for security teams running audits, not founders picking a platform.
Can hallucinated AI dependencies really be a security risk?
Yes — this is a risk specific to AI-generated code. A model can reference a package name that doesn't actually exist (or exists but isn't what it assumes), and if that name gets registered by someone else, installing it can introduce malicious code. Platforms that vet and pin dependencies rather than blindly installing whatever a model names reduce this risk considerably.
How does greta.sh handle these risks?
Greta.sh generates auth and backend logic with security handled at the platform level rather than left entirely to what a model happened to generate from a prompt. That doesn't remove every risk in the table above no platform can promise that, but it removes several of them from the founder's list of things to personally get right.
