Securing AI Code: OWASP, GDPR, HIPAA, EU AI Act Checklist

Endor Labs has a good guide to securing Cursor. It covers secrets detection and malicious dependency scanning. It does not mention GDPR, HIPAA, or the EU AI Act once. That’s not a criticism, it’s just not what that guide is for, but if your AI-generated code touches EU users, health data, or an AI-driven decision, secrets and dependencies are not the whole list.

This is the checklist I wish existed when I started scanning AI-generated code for more than just OWASP. Four standards, one section each, concrete checks you can run against a pull request instead of vague advice about “being careful.” Bookmark it, or run it as a review gate.

None of these standards care that a model wrote the code instead of a person. GDPR doesn’t have an exemption for “the data minimization violation was AI-generated.” The EU AI Act auditor doesn’t ask who typed the function. What changes with AI-assisted development isn’t the requirement, it’s the volume and the speed: a single prompt can produce a new endpoint, a new database table, and a new log line in the time it used to take to write one of those, which means the same three checks now need to happen three times as often, on code a human skimmed for correctness but may not have skimmed for compliance.

Section 1 of 4

OWASP Top 10 for AI-generated code

The classic OWASP Top 10 is about web application vulnerabilities, and it doesn’t care whether a human or a model wrote the vulnerable line. The reason it matters more for AI-generated code specifically is volume: a model can produce a SQL query with string concatenation faster than a human can type it, and it will, because that pattern shows up constantly in training data.

• Injection (A03): every SQL, shell, or ORM query built from user input uses parameterization, not string concatenation or f-strings. Grep the diff for f"...{ or + user_input patterns near a query call.
• Broken access control (A01): every new endpoint has an explicit authorization check, not just authentication. AI-generated CRUD scaffolding routinely checks "is logged in" and skips "is allowed to touch this specific record."
• Cryptographic failures (A02): passwords hashed with bcrypt, Argon2, or scrypt, never MD5 or SHA-256 alone. Models default to whatever hashing function appeared most often in their training data, which is not always the current best practice.
• Security misconfiguration (A05): no hardcoded secrets, debug flags, or permissive CORS (Access-Control-Allow-Origin: *) left in from a "make it work" first pass.
• Vulnerable and outdated components (A06): new dependencies pinned to a specific version, not latest, and checked against a known-vulnerability database before merge.
• Identification and authentication failures (A07): session tokens are random and long enough, not sequential IDs or predictable strings a model generated as a placeholder that never got replaced.
• Software and data integrity failures (A08): new CI/CD steps, install scripts, or auto-update logic verify a checksum or signature before executing anything pulled from a remote source, rather than piping a download straight into a shell.

The fix pattern for all six is the same: catch it before code review, because by the time a human reviewer is reading a 400-line AI-generated PR, injection patterns blend into the noise. AIVory Guard runs the OWASP Top 10 check for free, inline, as the code is written, which is the free tier regardless of which paid product you end up choosing for the rest of this list.

Section 2 of 4

GDPR checks for AI-generated code

GDPR is a data protection law, not a code style guide, so the checks here are about what the code does with personal data, not syntax.

• Data minimization: the new field, log line, or API response doesn't capture more personal data than the feature actually needs. AI-generated logging code has a habit of dumping the entire request object, headers and all, "for debugging."
• Consent before processing: any new tracking, profiling, or third-party data share has a consent check in front of it, not just a privacy policy paragraph promising one exists.
• Right to erasure is actually wired up: if you generate a new table that stores personal data, check whether your existing delete-user flow was updated to cover it. AI-generated schema migrations rarely know your erasure pipeline exists.
• Data stays where it's supposed to: new third-party API calls (analytics, email providers, AI model APIs) don't silently send EU user data to a processor without a data processing agreement, or across a border without a valid transfer mechanism.
• PII isn't logged in plaintext: emails, names, and IP addresses in log statements are masked or excluded, not concatenated straight into a log line that ends up in a third-party logging service.
• Automated decisions have a human path (Article 22): if generated code makes an automated decision with legal or similarly significant effect on a user, a rejection, a price, an eligibility check, there's a documented way for the user to request human review, not just an API that returns a verdict.

The pattern that actually catches teams out isn’t the big violation, it’s the small one: a debug log line an AI assistant added while fixing an unrelated bug, that now ships a user’s email address to a log aggregator with a three-year retention window nobody set on purpose.

Section 3 of 4

HIPAA checks for AI-generated code

If you’re nowhere near healthcare data, skip this section entirely, it doesn’t apply and doesn’t need a compliance program built around it. If any part of your product touches Protected Health Information (PHI), the AI-generated code checks are stricter than GDPR’s.

• PHI is encrypted at rest and in transit: every new field that could hold health information (diagnosis codes, medication names, appointment notes) is encrypted in the database, and every connection carrying it enforces TLS.
• Access is logged, not just controlled: HIPAA's audit requirements mean you need a record of who viewed what PHI and when, not just a permission check that silently allows or denies. AI-generated CRUD code gets the "denies" part; it rarely gets the audit trail.
• Minimum necessary standard: a new API response returns only the PHI fields the caller actually needs, not the full patient record because that was the easiest object to serialize.
• Automatic session timeout: any new authenticated view containing PHI has a session timeout appropriate for the sensitivity, not the default "stay logged in for 30 days" a generated auth scaffold ships with.
• De-identification before analytics: if generated code feeds PHI into an analytics or AI pipeline, verify it's actually de-identified first, not just excluded from the specific columns someone remembered to filter.
• Third-party AI calls have a Business Associate Agreement behind them: if generated code sends PHI to an external LLM API for summarization, classification, or search, check that a BAA actually covers that vendor before the call ships, not after a security review catches it.

Section 4 of 4

EU AI Act checks for AI-generated code

Most teams building general developer tooling or B2B features land in the Act’s minimal or limited risk tiers, where the burden is real but narrow. The checks below are the code-level version of that narrower burden, not the full high-risk conformity assessment (if you’re building in hiring, credit, or medical devices, this list isn’t enough, get legal review).

• AI disclosure is in the UI, not just the ToS: if a feature is AI-generated content or an AI chat interface, the interface itself says so, visibly, not buried three clicks deep in a terms-of-service page.
• AI-generated content is labeled where it could be mistaken for human output: generated images, summaries, or written content that a user could reasonably mistake for something a person made, has a label attached in the code path that renders it, not just a design mockup that a later PR forgot to include.
• There's a human override path: if an AI feature makes or suggests a decision (categorization, scoring, moderation), the code includes a path for a human to override or appeal it, not just log the AI's decision as final.
• Basic system documentation exists in the repo: a README or doc comment describing what the AI feature does, what data it uses, and its known limitations. This is also the fastest way to re-classify your risk tier later if the feature's scope changes.
• No silent scope creep into a higher tier: if a generated feature quietly starts influencing an employment, credit, or access-to-essential-services decision, that's a tier change, not a footnote. Flag it for review rather than shipping it as a minor feature update.
• No prohibited-practice patterns: the code doesn't implement social scoring, manipulative dark patterns aimed at exploiting a user's vulnerabilities, or untargeted biometric scraping, the handful of use cases the Act bans outright regardless of risk tier. Most teams will never brush against this, which is exactly why it's worth a single explicit check rather than an assumption.

If you can only run one section today

Start with OWASP. It applies to every codebase regardless of industry or user location, the checks are the most mechanical of the four, and a scanner catches most of them without a human in the loop. Add GDPR next if you have EU users at all, which is a lower bar than most teams assume, “we have one customer in Germany” already counts. HIPAA and the EU AI Act are conditional: skip them entirely if they don’t apply to your product, and don’t build process around a regulation your product doesn’t trigger. The mistake isn’t doing these out of order, it’s treating all four as equally urgent for every team when two of them usually aren’t your problem at all.

Running this as an actual gate

A checklist that lives in a doc nobody opens isn’t a checklist, it’s a wiki page. The practical version of this is a pre-merge scan that runs automatically and blocks or flags on the items above, the same way you’d gate on a failing test.

AIVory Guard scans against OWASP Top 10 on the free tier, and against GDPR, HIPAA, PCI-DSS, SOC 2, the EU AI Act, and other named standards on the paid tiers, inline in JetBrains, VS Code, Cursor, and Antigravity, or through the MCP server and Claude Code plugin for AI-agent workflows. It’s not a substitute for the items above that need a human judgment call, the erasure pipeline check and the tier-classification check especially still need a person to actually think about them. What it’s good for is not letting the mechanical checks, the plaintext log line, the missing parameterized query, slip through because a reviewer was scanning a 400-line AI-generated diff at 6pm on a Friday.

For the parts of this checklist an auditor will actually ask to see evidence of, the dashboard side matters as much as the scan side. Violations come back classified by severity (Critical, High, Medium, Low), and reports export as JSON, CSV, PDF, or HTML, with an audit trail of who scanned what and when. That export is the difference between telling an auditor “we check for this” and handing them a PDF with a timestamp. Neither replaces the actual legal review a high-risk EU AI Act system or a HIPAA covered entity needs, this checklist is the technical layer underneath that review, not a substitute for it.