Securing AI-Built Products

"Securing AI-built products" has two distinct meanings that both matter. Products built by AI — where the code itself was generated by an LLM. And products built with AI — applications that embed LLM features like chat, summarization, or agents. Each brings a different security profile, and many modern applications are both at once: AI-generated code that also calls AI APIs.

AI-Generated Code: Plausible, Not Secure

Code generation models produce code that looks correct and often works correctly. But "it works" and "it's secure" are unrelated properties. A function can return the right output while being vulnerable to injection, missing authorization checks, or leaking sensitive data through error messages. Models optimize for plausibility and functional correctness, not for security.

The patterns are predictable because models learn from the internet, and the internet is full of insecure code. Tutorials skip security for clarity. Stack Overflow answers optimize for brevity. Open-source projects have varying security maturity. The model learned from all of it.

Common Insecure Patterns in Generated Code

Missing authorization checks. The model generates a CRUD API with beautiful routing, validation, and database queries — but no middleware that verifies the authenticated user is allowed to access the requested resource. The endpoint works perfectly. Anyone can access anyone else's data.

Hardcoded secrets. API keys, database passwords, and JWT signing secrets embedded directly in source files. The model learned this pattern from thousands of tutorials that do exactly this for simplicity.

// Generated by AI — works great, ships your secret to GitHub
const stripe = require('stripe')('sk_live_abc123...');

String-concatenated queries. Instead of parameterized queries, the model builds SQL by concatenating user input. Classic SQL injection, generated fresh by a model that learned from millions of examples of the same anti-pattern.

Permissive CORS. Access-Control-Allow-Origin: * on APIs that handle authenticated requests. The model generates it because it makes the API "work" from any frontend during development, and nobody changes it before production.

Missing rate limits. APIs that accept unlimited requests per second. No throttling, no abuse detection, no cost protection. The model doesn't think about operational concerns unless you specifically ask.

Slopsquatting. Models sometimes hallucinate package names that don't exist. An attacker registers those names with malicious packages. When a developer installs the AI-suggested dependency without verifying it exists and is legitimate, they pull in attacker-controlled code. This is the AI-specific supply chain risk.

The Velocity Problem

The actual risk of AI-generated code isn't that any single generated function is worse than what a human would write. It's the speed. A developer using AI assistance can generate and ship code faster than they can review it. The bottleneck shifts from writing code to verifying code, and most teams don't adjust their processes to account for that.

When you're shipping three features a day instead of three a week, security review, testing, and architectural consideration get compressed or skipped. Velocity without verification is the core risk. The code isn't the problem — the process around it is.

Products With LLM Features

If your product includes LLM features — chatbots, summarization, code generation, agents — everything from the previous lesson on AI security risks applies. Prompt injection, insecure output handling, excessive agency, and all the rest. But there's a product-level lens that's worth calling out separately.

The integration points are where things go wrong. Your LLM feature talks to your database. It reads user-uploaded documents. It calls third-party APIs on behalf of users. Each of these integrations inherits the risks from the previous lesson and compounds them with your application's specific trust model.

The Hardening Checklist

Whether your SaaS was built by AI, with AI, or both, these are the security controls that catch the most common failures. This isn't comprehensive security — it's the floor, the minimum you should have before you ship.

Authorization at every endpoint. Not just authentication (is this a logged-in user?) but authorization (is this user allowed to access this specific resource?). Check it server-side, on every request. Never trust the client to enforce access control.

Secrets in a manager, not the repo. Use environment variables or a secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler). Run git log --all -p -- '*.env' and search for patterns like sk_live, AKIA, and -----BEGIN RSA in your history. If secrets were ever committed, rotate them — deleting the file doesn't remove it from git history.

Parameterized queries. Every database query uses parameterized statements or an ORM that handles parameterization. No exceptions. This is a zero-tolerance item.

// Never this
db.query(`SELECT * FROM users WHERE id = '${userId}'`);

// Always this
db.query('SELECT * FROM users WHERE id = $1', [userId]);

Input validation server-side. Validate type, length, format, and range on the server. Client-side validation is UX, not security. An attacker won't use your form.

Security headers and CSP. Set Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Strict-Transport-Security, and Referrer-Policy. A restrictive CSP that blocks inline scripts and limits script sources is one of the most effective XSS mitigations available.

Dependency scanning in CI. Run npm audit, pip audit, Dependabot, or Snyk on every pull request. Block merges on critical vulnerabilities. AI-generated code tends to suggest popular packages at the versions the model was trained on — often outdated.

Rate limits and cost caps. Rate limit every public-facing endpoint. If your product uses LLM APIs, set per-user and per-organization cost caps. An unauthenticated endpoint that triggers an LLM inference is a cost-amplification attack waiting to happen.

Logging and alerting. Log authentication events, authorization failures, and anomalous patterns. Alert on spikes in failed auth attempts, unusual data access patterns, and cost anomalies. You can't respond to what you can't see.

Least-privilege cloud IAM. Your application's service account should have the minimum permissions it needs. Not AdministratorAccess. Not s3:*. The specific actions on the specific resources the application actually uses.

Tenant isolation. If you're building multi-tenant SaaS, enforce isolation at the data layer. Row-level security, separate schemas, or separate databases — pick your model, but verify that tenant A cannot access tenant B's data through any path, including LLM features that might retrieve cross-tenant content.

Building the Review Habit

The checklist works, but only if it's applied consistently. Build it into your process:

Run SAST (static analysis) and dependency scanning in CI. They catch hardcoded secrets, known vulnerable dependencies, and common code patterns (SQL concatenation, missing CSP headers) automatically. They won't catch everything, but they catch the easy stuff at scale.

Do focused security reviews on AI-generated code. Not line-by-line review of everything, but targeted review of authentication flows, authorization checks, data access patterns, and external integrations. These are where AI-generated code is most likely to be insecure.

Treat AI-generated code with the same rigor you'd apply to a pull request from a new contractor: probably fine, but verify the important parts.

Key Takeaways

• AI-generated code optimizes for working, not for secure. Missing authorization, hardcoded secrets, and string-concatenated queries are the most common generated anti-patterns.
• The velocity problem is real: shipping faster than you can review means security gaps accumulate faster than they're caught.
• Slopsquatting — hallucinated package names registered by attackers — is a novel AI-specific supply chain risk.
• The hardening checklist (auth at every endpoint, secrets in a manager, parameterized queries, CSP, dependency scanning, rate limits, logging, least-privilege IAM, tenant isolation) is the security floor for any SaaS product.
• Automated scanning in CI catches the easy wins. Focused human review of auth flows, access control, and data handling catches what automation misses.
• "It works" and "it's secure" are unrelated properties. Verify both independently.

This concludes the Security track. The principles here compound — the CIA Triad, authentication, authorization, common vulnerabilities, OAuth, zero trust, threat modeling, testing, and AI-specific risks all layer together into a security practice that scales with your product.