# How to secure AI generated code from prompt to pentest > Source: > Published: 2026-08-05 11:04:55+00:00 We ran a session with Jordan Constantine, Head of Offensive Security at WorkNest Secure. Codacy CTO Kendrick Curtis covered what goes wrong while the code is being written; Jordan covered what he finds when he's paid to attack it afterwards. The single highest-return fix in the whole session: set a minimum age in your .npmrc. Most malicious packages get flagged and pulled within hours, so 3 days of insulation removes the large majority of bleeding-edge dependency risk. One config line. For the other end — known-vulnerable older versions — you need a version database, which is the part we do; Verity runs our CLI inside the agent and corrects the version before it lands. **Malicious MCP servers.** An MCP server is a wrapper around an API, which means it's a middleman in your code path on the developer machine and in production. Same threat model as a malicious package: exfiltrate what's on the machine and post it out. The fix isn't banning them, it's a curated allowlist committed somewhere developers can actually find, a process for adding to it, and scoped tokens per server so the blast radius is contained when 1 turns out to be hostile. **Prompt injection.** You can now hack computers in English. On the dev machine it doesn't even need executable code — a text file inside a dependency instructing the agent to read your env vars and POST them somewhere is enough, because agents can't separate instructions from data. Containment is the answer: sandbox the agent, control what crosses the boundary, keep keys in a vault and only short-lived ones in env vars. **Unbounded agent permissions.** Agents execute as you, with your permissions, including dropping to a terminal. The weekly "the AI deleted my production database" post is a permissions failure, not an AI failure. Read-only if it must have prod at all, or hand it a clone and review the script it writes. How guardrails actually get bypassed. Not with zero-days in the safety logic. Role-play and pretexting, indirect injection hidden inside documents, task decomposition into a chain of individually harmless steps, and spacing/encoding tricks that reassemble server-side after a grammar pass. Structurally identical to XSS and SQLi filter evasion, different surface. The bypass goes around the guardrail, not through it. **Walkthrough 1**: chatbot to password hashes. Well-configured web app, almost nothing else found. They asked the customer-facing chatbot which database tables it could reach and it answered dbo.Users. It gave a count of 60,000 but withheld the rows, so they asked what parameters the backend expected, learned it wanted a user ID, supplied their own test account's ID, and got the full record — including an MD5 password hash. With user enumeration also present, they could cycle accounts and pull hashes. No payload, no exploit. **Walkthrough 2 **: LLM document ingestion to AWS credentials. Ingestion service on AWS, so SSRF against the EC2 metadata endpoint was the obvious target. Direct requests to localhost and the metadata IP were blocked. So they pointed it at a permitted external URL that redirected to the metadata endpoint, and the LLM followed. The response never came back directly — it got vectorized into the LLM's own document store — so they asked the chatbot what it had recently ingested, and it read the AWS credentials back out, reasoning that it could only answer from data in its context. High-privilege credentials. **Treat AI like infrastructure.** Jordan's summary of what most teams get wrong: AI gets the access level of a service but the governance of a feature, usually because narrowing scope slows development down. Least privilege on the agent's token, human in the loop on a defined list of actions rather than everything, and incident response that works in hours — which means accepting false positives and deciding where you sit on usability versus security before it's an incident. **One from the Q&A worth repeating.** When asked which AI-generated vuln is hardest to catch in review, Kendrick's answer was missing authorization on API endpoints - no token check, or no scoping of results to the requesting user. Scanners are good at things that are there and backed by a pattern or a database. Humans and tools are both bad at spotting the absence of something that should exist.