Is AI-generated Apex secure? A checklist for security teams

If your developers are asking to use Cursor or Claude, your security team probably has questions. That's a good thing. This checklist is for the people who have to say yes or no. It covers two areas: the code the AI writes, and the way the AI tools are used.

Nothing here is new. These are the same Apex security basics that apply to code a person writes. The difference is that AI writes code fast, so gaps show up fast too, unless the rules are built in.

Part 1: Checks for the code itself

1. Sharing is declared on every class

Apex runs in system mode by default, so a class with no sharing keyword can show records a user shouldn't see. AI tools often leave the keyword out. Check that every class says with sharing or inherited sharing, and that any without sharing class has a clear, written reason.

2. Object and field access is enforced

Sharing controls which records a user sees. CRUD and field-level security (FLS) control which objects and fields they can see. Check that queries run in user mode, for example with WITH USER_MODE in SOQL or AccessLevel.USER_MODE on Database methods, or that results go through Security.stripInaccessible before they're used.

3. No SOQL injection

Watch for dynamic SOQL built by adding user input to a string. That's the classic way to open a SOQL injection hole, and AI tools do it when they're asked for "flexible" queries. Check that the code uses bind variables, or Database.queryWithBinds for dynamic queries. String.escapeSingleQuotes helps, but it's a fallback, not the first choice.

4. No hard-coded IDs, URLs or credentials

AI tools often paste in a record ID or an endpoint URL to get something working. Hard-coded IDs break between orgs, and hard-coded credentials are a real risk. Check that configuration lives in Custom Metadata or custom settings, and that callouts use Named Credentials.

5. Code is bulkified and respects governor limits

This is more about stability than security, but it matters. A trigger with a query inside a loop can fail when a data load runs, and a failing process can leave data half-updated. Check for SOQL and DML inside loops, and make sure tests insert at least 200 records.

6. Lightning Web Components don't open XSS holes

For LWC, check that the code doesn't write user-supplied content into the page with innerHTML or lwc:dom="manual". Lightning Web Security helps, but it isn't a reason to skip the check. Also check that Apex methods marked @AuraEnabled enforce sharing and FLS, because any user with access to the component can call them.

7. Tests prove the security, not just the coverage

75% coverage tells you the code ran. It doesn't tell you it's secure. Check for tests that use System.runAs with a user who has limited permissions, and that confirm they can't see or change what they shouldn't. Ask the AI to write these tests every time. It's very good at it once it's told.

8. Salesforce Code Analyzer runs on every change

Don't rely on people to spot all of this. Salesforce Code Analyzer checks Apex and LWC for many of these issues automatically. Install it as a CLI plugin and run it in your pipeline:

sf plugins install @salesforce/plugin-code-analyzer
sf code-analyzer run --rule-selector pmd:Security

If your pipeline still uses the old sf scanner run command, plan to move it. Code Analyzer v4 is retired, and v5 replaces it with sf code-analyzer run.

Part 2: Checks for how the AI tools are used

9. AI tools only connect to sandboxes

AI coding tools can run Salesforce CLI commands. Check that they're connected only to sandboxes or Developer Edition orgs, and that nobody's AI setup can deploy to or query production.

10. No real customer data reaches the AI

Whatever is in the project folder or the prompt can be sent to the AI model. Check that sandboxes used with AI hold test data or masked data, not real customer records, and that data exports aren't kept in project folders.

11. No secrets in prompts or project files

Check that passwords, tokens and keys never go into prompts, and that files holding them are excluded from the AI tools, for example with a .cursorignore file in Cursor.

12. Approved tools, models and settings

Agree which AI tools and models people can use, and which settings are required, such as privacy mode or your company's data retention terms. Write it down and give everyone the same setup, instead of letting each developer configure their own.

13. Security rules are written into the tools

The checks in Part 1 work best before the code is written, not after. Put your security rules into the AI tools' project rules, such as "always use user mode" and "never build SOQL from strings", so the AI follows them from the first line.

14. Humans still review security-sensitive code

An automatic first review catches the common issues. Keep a human reviewer for anything that changes sharing, runs without sharing, exposes Apex to guest users, or calls external systems. AI makes reviews faster. It doesn't replace them.

How to use this checklist

Use Part 2 to approve the AI tools before your team starts. Use Part 1 in your code reviews and your pipeline, and turn as much of it as you can into automatic checks and project rules. Write down what you've agreed, and review it whenever your tools change. That written record is what makes the next audit straightforward.

Questions teams ask

Is AI-generated Apex less secure than code written by developers?

Not on its own. AI tools make the same mistakes a rushed developer makes, like missing sharing keywords or FLS checks. With security rules built into the tools, automatic scans and human review, AI-written Apex can meet the same standard.

Can AI coding tools see our customer data?

They can see whatever is in the project folder, the prompt and any org they're connected to. Connect them only to sandboxes with test or masked data, and keep data exports out of project folders.

Which tool checks Apex for security issues automatically?

Salesforce Code Analyzer. Version 5 runs with the sf code-analyzer run command and can be added to your DevOps pipeline so every change is scanned.

Do we still need code reviews if AI writes the code?

Yes. An automatic first review catches common issues, but a person should still review security-sensitive changes, like code that runs without sharing or calls external systems.