AI-generated code is secure only when someone who knows what to look for has checked it. That is where the official guidance from tool makers and Australian government agencies points: security depends on the review, not on the tool. Before any software goes live, a person needs to confirm where its secrets live, who can reach its data, what it accepts as input, what it depends on, how it is backed up and how it is served, and then read the code. AI coding tools produce working code quickly, and working is not the same as safe.
Why AI-written code needs a second look
With an AI coding tool, a person describes what is needed in plain language and the tool writes much of the code. Google Cloud's explainer on this way of working separates the "pure" form, where the user fully trusts the AI's output and which it calls suited to rapid ideation or throwaway projects, from the responsible form, where the user reviews, tests and understands the code and takes full ownership of the final product.
A business app belongs in the second group. The security documentation for Claude Code, one of these tools, says you are responsible for reviewing proposed code and commands for safety before approval. business.gov.au puts it more broadly: your business is responsible for everything your AI tools do.
The Australian Signals Directorate says cybercriminals may use AI to rapidly discover and exploit vulnerabilities, especially in websites. Its advice to a business that develops software is a quality assurance process that includes scanning the software for vulnerabilities.
The seven checks, and what each one prevents
These checks line up with the OWASP Top 10, which OWASP describes as a standard awareness document representing a broad consensus about the most critical security risks to web applications.
| Check | What to ask your developer | The risk it addresses |
|---|---|---|
| Secrets out of the browser | Where are the API keys and passwords kept? | Someone copies a key and uses your account |
| Access rules | Who can read and change each kind of record? | Broken Access Control |
| Input validation | What happens when a form receives something unexpected? | Injection |
| Dependencies | How do you hear about a vulnerable package? | Software Supply Chain Failures |
| Backups | Has a restore been tested? | Losing data after a mistake or an attack |
| HTTPS and server settings | Is every page served over HTTPS, and are the server settings around it (security headers) in place? | Cryptographic Failures and Security Misconfiguration |
| A human reading the code | Who read the AI-written code, and what did they check? | Insecure Design, and gaps in every row above |
Secrets stay out of the browser
An API key is a password for a service your app uses. The documentation for the Gemini, OpenAI and Claude APIs agrees on the rule: a key does not belong in code that reaches a browser or a mobile app, and it is never committed to a code repository. Requests go through your own backend server, and the key sits in an environment variable or a secret manager. Ask to be shown where yours are kept.
Access rules are written and tested
Access rules decide who can read and change each record. They are easy to skip in a first draft, because an app with no rules works perfectly in a demo.
Firebase, one of the platforms used to store app data, shows why. Its documentation says that when you create a database you can choose to deny access to all users (Locked mode) or grant access to all users (Test mode), and that you should secure your data before deploying. It warns that if a deployed app is not authenticating users and configuring security rules, anyone who guesses your project ID can steal, modify or delete the data.
Input is checked on the server
Every form field, upload and web address is a way in. Injection, one of the OWASP categories, is what happens when text a stranger typed is treated as an instruction instead of as data. The remedy is to validate input on the server, where a visitor cannot switch the check off, and to reject anything that does not fit.
Dependencies are checked
Modern apps are built on packages written by other people, including any the AI tool chose. GitHub's Dependabot alerts notify you when your code depends on packages with known security vulnerabilities. The npm audit command asks the package registry for a report of known vulnerabilities in a project's dependencies, and npm's documentation says some will need manual review.
Backups exist and have been restored
Regularly backing up your data is one of the three starting measures in the Australian Signals Directorate's small business cyber security handbook, alongside turning on multi-factor authentication and keeping software up to date. A backup nobody has restored is a hope, not a plan.
HTTPS and server settings are in place
cyber.gov.au describes HTTPS as an encrypted and more secure version of HTTP, and says you can check for it by looking for https at the start of the URL. Its key actions for securing a website also include multi-factor authentication for administrator accounts, strong passwords, appropriate access controls and keeping software and plugins up to date.
A person has read the code
This check holds the others together. A reviewer who understands the app reads what the AI wrote, runs the tests, tries to get past the access rules and removes what is not needed. If nobody can tell you who did that, assume nobody did.
How to run a review before launch
- Name who is responsible. The Australian Signals Directorate recommends identifying a person or service provider responsible for maintaining the cyber security of your websites.
- List the data the app holds. Mark anything that identifies a person and remove fields you do not need. The OAIC notes that over-collection can increase security risks.
- Look for secrets. Ask the developer to show that no keys or passwords sit in the code or its history. GitHub's secret scanning checks a repository's entire Git history for hardcoded credentials.
- Test access as each kind of user. Sign in as one customer and try to open another customer's record, then try with no sign-in at all.
- Run the dependency checks and restore a backup into a test copy. Read the results instead of filing them.
- Turn on multi-factor authentication for every administrator, hosting and code account. cyber.gov.au describes it as proving who you are in two or more ways before you can log in.
- Write down what was checked, by whom, and who acts if something goes wrong after launch.
If the app holds personal information
If the Privacy Act covers your business, APP 11 requires you to take reasonable steps to protect the personal information you hold from misuse, interference and loss, and from unauthorised access, modification or disclosure.
Under the Notifiable Data Breaches scheme, an organisation the Act covers must notify affected individuals and the OAIC when a data breach is likely to result in serious harm to an individual whose personal information is involved. An entity that suspects such a breach must take all reasonable steps to complete its assessment within 30 calendar days of becoming aware of the grounds for suspicion.
The OAIC recommends that a small business outside the Act still protects the personal information it holds. This is general information, not legal advice, so ask the OAIC or a lawyer how the Act applies to you.
These checks apply to any software, whoever or whatever wrote it, and no system is perfectly secure. Comingwave is a technology company that provides cyber security and IT consulting services to small and medium enterprises. If you would like an existing system looked at, ask for a free first consultation.
Common mistakes
- Treating a working demo as a finished app. A demo proves the features, not the defences.
- Putting a key in the page "just for now". Anything a browser downloads can be read by whoever is using that browser.
- Leaving the database open after testing. Rules written for a prototype should not survive to launch.
- Naming nobody. If no person or provider is responsible for security after launch, patches and alerts go unread.
Frequently asked questions
Is AI-written code less secure than code a person writes?
Neither is safe by default. An AI tool produces code quickly, so there is more to check in less time. What decides the outcome is whether a person reviews, tests and hardens the code before customers use it.
Can I check an app myself if I am not technical?
You can check more than you might expect. Look for https at the start of the address, ask the questions in the table above, and ask to be shown the evidence for each answer.
Who is responsible if an AI tool writes insecure code?
Treat the responsibility as yours. business.gov.au says your business is responsible for everything your AI tools do, and recommends making someone senior in the business accountable for AI safety. The tool's own documentation puts the review of proposed code on the person using it.
What should I do if I think my app has been breached?
Contact whoever maintains the app straight away and ask what was accessed. business.gov.au lists the Australian Cyber Security Hotline on 1300 292 371 for help responding to cyber incidents. If the Privacy Act covers your business, check the OAIC's guidance on notifiable data breaches or get advice. There are more answers on the Comingwave questions page.
Key takeaways
- AI-generated code is as secure as the review it gets, not the tool that wrote it.
- Ask about seven things: secrets, access rules, input validation, dependencies, backups, HTTPS and server settings, and human review.
- Keys never go in code that reaches a browser, and a database is never left open to all users.
- Name a person or provider responsible for security after launch.
- If the app holds personal information, know what the Privacy Act and the Notifiable Data Breaches scheme ask of you.