How to prevent security problems in AI-generated applications

Someone on your team typed a prompt into an AI assistant, got back a working login screen or a data entry form in twenty minutes, and shipped it the same afternoon. Nobody on the team is a trained security engineer, and nobody asked the AI whether the generated code checks permissions properly, sanitizes input, or exposes an API key in plain text. This is not a hypothetical — it's the default workflow now inside thousands of small and mid-sized companies using AI-assisted, low-code tools to build internal software fast.

The speed is real and valuable. The risk is also real, and it's different from the risks you learned to watch for in traditional development. This article walks through exactly what can go wrong in AI-generated applications, and the concrete checks you can put in place before this code touches customer data or production systems.

Why is AI-generated code a different kind of security risk?

Traditional code has a human author who (hopefully) understood the security implications of what they wrote. AI-generated code has a pattern-matcher that produced something statistically likely to work — not something proven safe.

Concretely, this shows up in a few recurring ways:

• The AI optimizes for "it runs," not "it's safe." Ask an AI assistant to build a customer lookup script in FileMaker, and it will very likely produce something that queries the right table and returns the right fields. It will just as likely skip privilege checks, because you didn't ask for those, and the training data it learned from is full of tutorial-grade examples that skip them too.
• It reuses patterns from public code, including insecure ones. Large language models are trained on enormous amounts of public code — a meaningful share of which contains known vulnerabilities (hardcoded credentials, missing input validation, weak session handling). The model doesn't know which examples were good practice and which were the reason a tutorial repo got flagged.
• It's confidently wrong. An AI assistant will state that a script "safely handles user input" or "stores the API key securely" with the same tone whether or not that's true. There's no hedge, no red flag — which means the humans reviewing it need to bring their own skepticism.
• Low-code tools amplify the blast radius. Platforms like FileMaker, and AI layers built on top of them such as Klai or form-builders like FmBetterforms, let one non-developer generate a working module in an afternoon. That's the whole point of low-code — but it also means security review is now needed at a stage where, a few years ago, nobody outside a dev team was producing code at all.

What actually goes wrong in practice?

These aren't theoretical categories — they're the specific failure modes we see most often when reviewing AI-assisted builds.

1. Hardcoded credentials and API keys. An AI-generated FileMaker script calls an external API and the assistant writes the API key straight into the script step, because that's the fastest way to make the demo work. It sits there in plain text, visible to anyone who can open the script in Manage Scripts — including a former employee whose account was never fully revoked.
2. Missing or wrong privilege sets. A generated layout lets any logged-in user edit a field that should be locked to managers only, because the prompt was "let users update the order status" and the AI has no way of knowing your org chart.
3. No input validation. A web form built with an AI-assisted low-code tool accepts a name field that actually accepts arbitrary script content, because nobody told the generator to sanitize it — opening the door to injection-style attacks against whatever backend the form talks to.
4. Overly broad API scopes. When AI wires up a connector between two systems — say, FileMaker to an accounting package — it's common for the generated integration to request full read/write access to an entire account, because that's the simplest scope to configure, not because the task needed it.
5. No audit trail. The generated code performs the action requested (delete record, update price, export data) but doesn't log who did it or when — fine for a prototype, a liability once that module handles real customer or financial data.
6. Copy-pasted logic with silent assumptions. AI tools often generate code that assumes a single-user, single-location context because that's the simplest interpretation of the prompt — and that assumption quietly breaks once a second office, warehouse, or franchise starts using the same system.

How do you review AI-generated code for security before it ships?

Treat every AI-generated module the way you'd treat code from a junior contractor you've never met — useful, often good, always in need of a second pair of eyes.

1. Never deploy straight from the AI's output. Build a rule into your workflow: AI-generated scripts, layouts, or connectors go into a staging area first, not directly into the live file or production environment.
2. Ask the AI to explain its own security choices — then verify them yourself. Prompting "explain how this script handles unauthorized access" often surfaces gaps immediately, because the AI will either admit it didn't handle it or describe a check that isn't actually in the code. Read the actual script, don't just trust the explanation.
3. Run a credentials and secrets scan. Search every generated script, calculation, and webhook for anything that looks like a key, password, or token. In FileMaker specifically, check script steps, custom functions, and the Data API configuration — these are the places AI assistants tend to drop credentials directly.
4. Check privilege sets against the actual org structure, not against what the prompt implied. Someone who knows the business — not the AI, not even the developer — needs to confirm who should actually see and edit each field.
5. Test with a low-privilege account, not the admin account. A huge share of access-control bugs never surface during development because the developer is testing as an admin who can see everything anyway.
6. Validate every external-facing input field. Anything a customer, vendor, or public-facing form submits should be treated as untrusted until explicitly checked — regardless of who or what wrote the validation logic.
7. Limit API and connector scopes to exactly what the task needs. If the integration only needs to read order status, don't accept a generated connector that requests full account access because it was easier to configure that way.
8. Add logging before go-live, not after an incident. Every module that touches financial data, customer records, or user permissions should record who did what, when — this is often the first thing an AI-generated build skips.

Who should actually be reviewing this — the developer, IT, or the business owner?

All three, at different points, because each catches something the others miss.

• The person who built it (developer or power user) should run the technical checks above — secrets, validation, privilege sets — before anyone else looks at it.
• IT or a security-minded reviewer should confirm the module fits your existing access-control model and doesn't introduce a new attack surface (an unnecessary open API endpoint, an over-broad connector scope) that IT wasn't tracking.
• The business owner or manager who requested the tool is the only person who actually knows who should have access to what. "Should warehouse staff see customer pricing?" is a business question, not a technical one, and AI has no way to answer it correctly.

If your organization has nobody formally responsible for this review today, that's the first gap to close — not with a new hire necessarily, but with a written checklist and a named owner for the sign-off, even if that's a 15-minute step before anything goes live.

Does this mean AI-assisted development is too risky to use?

No — but it does mean the review step can't be skipped just because the build step got faster. The organizations getting real value from AI-assisted low-code tools are the ones that treat AI as a fast first draft, not a finished product, for anything that touches real data or real users.

In practice, this looks like: AI generates the script, layout, or connector in minutes; a human runs it through a short, repeatable security checklist; only then does it move to production. That checklist takes far less time than the original build saved — which is why speed and security aren't actually in conflict here, as long as someone owns the checklist step.

A pre-deployment security checklist for AI-generated modules

• No hardcoded API keys, passwords, or tokens anywhere in the script, calculation, or connector
• Privilege sets reviewed against actual job roles, not assumed from the prompt
• Tested with a low-privilege account, not an admin account
• All external-facing inputs validated and sanitized
• API/connector scopes limited to exactly what the task requires
• Logging in place for any action touching financial, personal, or customer data
• Explanation from the AI cross-checked against the actual generated code, not taken at face value
• A named person has signed off before go-live

FAQ

Can an AI assistant fix the security issues it created if I just ask it to? Sometimes, but not reliably. Asking "make this secure" often produces surface-level fixes — renaming a variable, adding a comment — without addressing the actual gap, especially around privilege logic that depends on business context the AI doesn't have.

Is this more of a risk in FileMaker/low-code than in traditional coding? The risk is different, not necessarily bigger. Traditional development has its own AI-code risks (the same models write JavaScript and Python too). Low-code platforms concentrate the risk because they let non-developers ship working software directly, which means the review step has to be added deliberately rather than inherited from an existing dev process.

How often should existing AI-generated modules be re-reviewed? Any time the module's data access changes — a new user role gets added, it starts touching a new table, or it gets connected to a new external system — treat that as a new build and run the checklist again.

Should we just ban AI-generated code until we have a formal review process? That's rarely practical or necessary. A lightweight, written checklist and a named sign-off owner get you most of the protection without slowing the team down to a crawl.

If your team is already using AI to speed up FileMaker development, or is looking at AI-assisted tools like Klai or form builders such as FmBetterforms, it's worth pairing that speed with a proper review step rather than bolting one on after something breaks. We go deeper into how AI is changing the shape of custom software development in our related article on how low-code and AI-assisted development change business software. Loggix helps teams build that review step into a custom FileMaker solution, a connected web application, or an API integration from the start — and, where useful, sits down for a hands-on consultancy session to map out exactly where AI can safely speed up your development without opening new risk.