AI coding agents' worst security hole is letting one user see another's data: test it with two accounts

Today in AI (2026-10-20)

Salesforce agrees to buy AI marketing platform Braze for about $5.7B: Big software companies are buying up AI-powered tools that startups rely on for customer messaging, so the pricing, terms and roadmap of tools you use can change under you.
OpenAI drops its push for strict US AI chip limits on China: A shift in how hard the US limits Nvidia chip sales abroad affects global AI supply and costs, and it shows AI providers' policy positions can change quickly.
Anthropic's leaked federal AI bill is criticized as weaker than FRONTIER Act: Federal AI rules now being drafted will shape what AI companies, and the startups building on them, must disclose and guarantee.

AI coding agents leave the same security gaps again and again. They are not random. The agent is trying to make your feature work, and security is the part of "working" nobody asked for, so it gets skipped.

The good news is that the gaps are predictable, and you can check for most of them without reading a line of code. Below are six, each with a plain explanation and a check you can ask for or run yourself.

I build MVPs with Claude Code on Cloudflare daily, and I have reviewed agency-built and contractor-built codebases as an interim or fractional CTO. The pattern is consistent: the app demos fine, and the holes sit where nobody was looking.

Why agents skip security

An agent optimizes for what you asked. "Let users save a project" produces a screen that saves a project. It does not automatically ask, "Should user A be able to read user B's project?"

Security is mostly about things that should not happen. Those rarely appear in a prompt, so they rarely appear in the code. If you want a deeper checklist for launch day, I covered data access, secrets and backups in this production-readiness post. This post goes wider on the code itself.

The six gaps and how to check each

1. Missing permission checks

This is the most common one. The app checks that you are logged in, but not that the record you request is yours. Change a number in the web address (say, from /invoice/101 to /invoice/102) and you see someone else's invoice.

Check: create two test accounts. Log in as the first, copy the address of one of its records, then open it while logged in as the second. If it loads, you have this bug. Ask the agent to add an ownership check on every page or action that reads or changes data, then repeat the test.

2. Secrets sitting in the code

A secret is a password-like key that lets your app talk to a paid service (payments, email, the AI provider itself). Agents sometimes paste these straight into files, and files end up in version history or in the browser.

Check: ask the agent to search the whole project, including past history, for keys and passwords. Confirm secrets live in your hosting provider's secret settings, not in the code. If a key was ever exposed, replace it. Deleting the line is not enough, because the old key still works.

3. Trusting what the user types

Any form field, upload, or web address can carry hostile input. Agents often pass it straight to the database or the page. The classic result is someone typing database commands into a search box and getting your data back.

Check: ask the agent, "Where does user input reach the database or the page, and is each one validated?" Then try it yourself: enter a very long string, odd symbols, and a snippet of HTML in every field. If the page breaks or renders the snippet, the input is not handled.

4. Security that only exists in the browser

Agents love hiding a button from non-admins. But hiding a button is decoration. Anyone can send the request the button would have sent.

Check: log in as a normal user and ask the agent to list every action that is "admin only." For each, confirm the server refuses the request, not just the screen. A founder-level test: have a technical friend try those actions without using the interface.

5. Packages nobody vetted

Agents install open-source building blocks (packages) freely. Some are abandoned, some have known flaws, and occasionally an agent invents a package name that an attacker has since registered.

Check: ask for a list of everything installed and why. Run the standard vulnerability scan for your stack (the agent can set it up in a few minutes). Remove anything you cannot justify. Fewer packages means fewer doors.

6. Overly open settings left from development

To get past errors, agents often loosen things: let any website send requests to your app (which means a malicious site can act on behalf of your logged-in users), turn off protections, leave on developer-only pages that expose internal details, or give the database account full power. Those settings tend to survive into production.

Check: ask, "What did you loosen or disable during development, and what should be tightened before launch?" Make it a written list and go through it item by item.

Common mistakes

Asking the same agent to grade its own work and accepting "looks secure." Ask for specific evidence: which pages and actions, which checks, which tests.
Testing only as the admin. Most gaps only show up when you act as a different user.
Fixing the symptom. If one page lacked a permission check, others probably do too. Ask the agent to audit all of them.
Skipping the second reviewer. A fresh pair of eyes, human or a separate review tool, catches what the builder's habits miss. My broader AI code review checklist covers what else to look for.

What has changed recently

Models keep getting faster and cheaper. MiniMax says its new M3.1 Flash runs nearly three times faster and cuts usage costs by 70%, and it lists cybersecurity among its improved areas. Faster, cheaper agents mean more code gets written per day, which means more places for these gaps to appear unless you review as you go.

I have not used that model, so I will not claim it writes safer code. Treat vendor claims as a reason to test, not a reason to relax.

The practical shift: since writing code is now cheap, spend the savings on checking it. A security pass costs far less than a leaked customer list.

What to do this week

Create two test accounts and try gap 1 on your most important screen. It takes ten minutes.
Ask your agent the three questions above: where input is validated, what is admin only, and what was loosened during development.
Search for exposed secrets and replace any that ever touched the code.
Put the six gaps in a document and make "checked" a requirement before any release.

If gap 1 fails, stop adding features until it is fixed. Everything else is secondary to making sure one customer cannot see another's data.