How to Audit and Secure an AI-Generated Internal Application

Published on September 19, 2026 | By Nick | Categories: Digital Transformation & IIoT

An internally built application can become useful very quickly with Claude Code or another AI coding tool. The first users get working screens, data starts moving out of spreadsheets and the team can change the system without waiting for an external development cycle.

Security and operational control rarely arrive at the same speed.

This is not a criticism of AI-assisted development. The same thing happens with conventional prototypes. The team concentrates on proving the workflow first. The risk appears when the prototype quietly becomes the system that holds customer, employee, quality, financial or production data.

A practical audit should answer one question: can the business continue using and changing this application without carrying risks it does not understand?

Start with the application boundary

Before reviewing code, document what the application actually touches:

  • users and user roles;
  • data stored in the application;
  • imports, exports and API connections;
  • hosting, database and file storage;
  • email, identity and other external services;
  • backups and recovery arrangements; and
  • business processes that stop if the application is unavailable.

This boundary matters because a small application can have a large operational footprint. A ten-screen quality tool connected to an ERP and used for release decisions carries more risk than a much larger standalone reporting application.

Review identity and access before individual features

Authentication proves who a user is. Authorisation controls what that user can do. Internal applications often implement the first and only partially implement the second.

Check whether permissions are enforced by the server, rather than merely hiding buttons in the browser. Test whether an ordinary user can change a URL or API request and access another user’s records. Confirm who can create accounts, assign roles, export data, approve transactions and delete records.

Broken access control is first in the OWASP Top 10:2025. It deserves attention even when the application is available only on an internal network. Internal access is not the same as authorised access.

Inspect the data model and change history

AI coding tools can add tables and fields quickly, but they do not know which business concepts must remain stable unless the team has defined them clearly.

The audit should look for duplicated master data, inconsistent status values, missing relationships, free-text fields where controlled values are required and records that can be deleted without trace. If approvals or compliance records matter, confirm that the system records who changed what and when.

Database changes also need a repeatable migration process. Manually changing the live database eventually creates differences between development, test and production environments that nobody can explain with confidence.

Check secrets, configuration and dependencies

API keys, database passwords and email credentials should not live in source files, prompts, browser code or copied configuration examples. Review the repository history as well as the current files; deleting a secret from the latest version does not remove it from earlier commits.

List the application’s packages and external services. Confirm which versions are in use, whether security updates are applied and whether the business knows what would happen if a package or hosted service changed or disappeared. The OWASP Top 10:2025 now treats software supply-chain failures as a major web-application risk.

Test input handling and exceptional conditions

Every field, uploaded file, import and API endpoint is an input boundary. The application should validate type, range, length and allowed values on the server. Database queries should use parameterised access rather than building commands from user input.

Also test what happens when things go wrong. What does the user see when an integration is unavailable? Can a failed import be safely retried? Does a partial transaction leave inconsistent records? Are technical error details exposed in the browser?

AI-generated code often covers the successful path first because that is the path used during the demonstration. Production reliability depends just as much on failed and interrupted paths.

Separate development, test and production

A business-critical application should not be developed directly against live data. At minimum, the team needs source control, a repeatable deployment method, separate test and production configuration, database migrations and a rollback plan.

Tests should concentrate on the workflows that would hurt the business if they failed: permissions, calculations, approvals, imports, integrations and record state changes. A large number of generated tests is less useful than a smaller set that protects the real operating rules.

Prove backup and recovery

Confirm that backups include the database, uploaded documents and any configuration required to rebuild the application. Then restore them into a clean environment.

The business should know its practical recovery point and recovery time. If the system failed late Friday, how much work would need to be re-entered and when could users expect it back?

Use a defined verification baseline

A review should not depend only on one developer’s preferences. The OWASP Application Security Verification Standard provides a structured basis for testing web-application security controls. It covers areas such as authentication, access control, validation, cryptography, logging and configuration.

The entire standard may be unnecessary for a low-risk internal tool. The reviewer should select a proportionate level and record which requirements were checked, which did not apply and which need remediation.

The output should be a repair plan, not a fear report

An audit that returns a long vulnerability list without business context is not very useful. The findings should be ranked by operational consequence and realistic likelihood.

A practical report separates:

  • issues that need immediate containment;
  • changes required before wider rollout or integration;
  • engineering improvements that can be scheduled; and
  • accepted limitations appropriate to the application’s actual use.

The team may be able to make most of the changes itself with Claude Code. External help is valuable when it provides an independent architecture and security view, tests assumptions and takes responsibility for the areas the internal team cannot confidently verify.

Audit before wider adoption

The best time to review an internally built application is after it has proved useful but before it holds irreplaceable data or becomes embedded in daily operations.

Nick’s Software reviews and productionises internally built database applications, including applications created with AI coding tools. Send a short description of the application, its users, data and integrations. The initial scope can be a bounded architecture, security and production-readiness review while your team retains control of the build.