Understanding Security with AI agents
Common vulnerability classes in AI-generated code, why agents can amplify them, and review habits that keep shipping safe.
Agents can ship working features quickly. The same velocity makes it easy to bake in classic web and app vulnerabilities unless you treat generated code like any other contribution: review against real threats, trust boundaries, and data flows.
Scope
None of the patterns below are unique to AI. They are familiar security failure modes. What changes is how often they can appear when a tool produces large diffs very quickly, sometimes without the usual pause to threat-model.
Common risk patterns
Use this table as a quick scan when reviewing agent-produced changes. Each row is a reminder of what to look for, not a complete guide.
| Area | What often goes wrong |
|---|---|
| Injection and unsafe composition | SQL, OS commands, LDAP, or HTML built by concatenating model output or user text without parameterization or encoding. |
| Secrets and credentials | API keys pasted into source, example env vars committed, or logging that prints tokens because the snippet looked convenient. |
| SSRF and URL trust | Server-side fetches to user-influenced hosts, open redirects, or webhooks that follow attacker-controlled endpoints. |
| Access control | CRUD scaffolds that authenticate but skip authorization checks, predictable IDs, or admin routes left unguarded. |
| Dependencies | Copy-paste installs of outdated packages, deprecated crypto, or transitive libraries with known CVEs the model did not re-verify. |
| Errors and debug surfaces | Stack traces, internal paths, or temporary endpoints shipped because the happy path worked in dev. |
Why agents amplify the same failures
| Pressure | What you tend to see |
|---|---|
| Speed | Generated code lands fast. The usual human pause to threat-model a feature often disappears when the diff already compiles. |
| Plausible-looking patterns | Changes read as “normal CRUD” or “standard config” while skipping subtle rules: CSP, CSRF, rate limits, file sandboxing. |
| Missing context | The model may not see your real deployment boundary, trust zones, or compliance rules unless you spell them out every time. |
Review habits that help
Treat agent output as code
The same review, testing, and tooling you expect from a human teammate still applies. Agents do not replace security gates; they change how fast unreviewed code can appear.
Untrusted by default. Treat every agent diff as untrusted until it passes the same review bar as a junior PR.
Name your boundaries in prompts. Say what is allowed: public internet exposure, PII, secrets, file system access, and who may access which resources.
Example you can paste and adapt:
Stack: Node REST API, Postgres, JWT access tokens. Surface is public internet; clients are untrusted.
Rules for any code you suggest: load secrets only from env; never log tokens or raw PII; every route needs explicit authorization beyond "user is logged in"; parameterized queries only. Call out any suggestion that breaks those rules before you write it.Keep CI gates on. Run static analysis, dependency audit, and secret scanning in CI. Extend coverage when agents touch security-sensitive paths.
Small, verifiable steps. Prefer small changes with tests for authorization and input handling on the code paths the agent modified.
When you are unsure
If a change touches auth, data access, parsing, or anything reachable from the network, slow down. Pull in your usual security review or threat-modeling habit before merging, even when the diff “looks fine” at first glance.