Before a non-engineer launches an AI-built app, check five things: every package is real and current, no secrets are hard-coded, authentication is on, inputs are validated and queries parameterized, and logging records actions without sensitive data. A second person should read the code once.
Why blind trust is the main risk
OWASP's Blind Trust (CD-SEC-01) is the uncritical acceptance of outputs from an automated system without checking accuracy, integrity or security. It calls this foundational because it amplifies the other nine risks. Builders may assume generated code and prebuilt components are safe.
OWASP's text on AI assistants is specific. They aim for code that works, not code that is secure. They will not add security features nobody requested. They may skip query parameterization, hard-code keys, default to plain HTTP, and reuse a flawed block across an app. They may also suggest packages that do not exist or are outdated.
Five checks
| Check | How |
|---|---|
| Dependencies | List every package. Confirm each exists in the official registry, is maintained and is a version you accept. |
| Secrets | Search the code and config for keys, tokens and passwords. Move them to a secret store. |
| Authentication | Open each page and endpoint while signed out. Anything private must refuse. |
| Input handling | Try overlong text, odd characters and quotes. Confirm queries are parameterized. |
| Logging | Trigger a sign in and an update. Confirm they appear in logs, and that no secret does. |
Steps for the builder
- Ask the assistant for the controls explicitly: authentication on every route, input validation, parameterized queries, secrets from environment variables.
- Paste the result into a repository, not a loose file, so changes are tracked.
- Run the five checks above.
- Ask a colleague to read it and answer: what does this app do with data?
- Register the app with an owner and a review date.
Why the repository step matters
OWASP's asset management guidance asks for mandatory version control and secure deployment. A script copied into a shared chat or a personal drive cannot be patched when a flaw is found. A script in a repository can be scanned, owned and updated.
What a reviewer can automate
- Dependency scanning on every change, to catch outdated or risky packages.
- Static analysis for injection patterns.
- A pre-commit or CI check for obvious secrets.
- A gate that blocks merging when a rule fails.
For deeper reading, see how to scan AI-generated code for vulnerabilities.
Try it yourself
Click through it at your own pace, or open it full screen. See how a failing check stops a change before it merges.
Where Safeguard fits
Safeguard's dependency scanning, reachability analysis and policy gates give engineering teams an automated review of code changes, including AI-written ones. A free scan is available at https://gold.safeguard.sh/scan.
Quick check
Can I trust code from a well-known assistant?
Treat it as a draft. It aims to work, not to be secure, so run the checks.
What if a suggested package cannot be found?
Do not install a lookalike. The name may be hallucinated, so ask for a different approach.
Sources
Last reviewed: 19 October 2026.
