AI app security checklist: what to verify before launch

Define the system and the assets at risk

List what the application stores and what it can do: accounts, private records, uploads, payments, model calls and administrative actions. For each capability, identify the actor, required permission, trusted server and underlying data. This is a small threat model that makes the review specific instead of treating security as a decorative checklist.

Use the OWASP Top 10 as a starting framework for web risks, not a pass certificate. A generated app can look complete while leaving an important access rule unspecified. Review the actual implementation and deployment configuration together. A secure source pattern can still be undermined by a production credential with excessive permissions.

Define the release boundary. An internal prototype with sample data is different from a public product accepting private records or money. Limit the initial audience and capability set when evidence is incomplete. Make the unknowns visible to the release owner rather than replacing them with a reassuring score.

Technical references: OWASP Top 10

Use two accounts to challenge access boundaries

Create two test users with independent records. With user A signed in, attempt to read and change a record belonging to user B through the application’s normal request interface. The server should reject unauthorized access even if an identifier is known. Do the same for listing, exporting and deleting records, since a single protected detail view is not enough.

Test account states: signed out, ordinary user, collaborator and administrator where applicable. Hiding the administrator menu does not enforce an administrator-only endpoint. Determine which layer enforces the policy and inspect the response. If the check exists only in browser code, the system needs a stronger authorization boundary.

Keep testing contained to systems and test accounts you own or are authorized to assess. Use synthetic records and avoid disturbing other customers. Record the request category, expected rule and observed outcome without putting session tokens or private data into your report.

• Record reads respect ownership or explicit sharing.
• Updates and deletes enforce the same policy.
• List and export routes do not bypass the detail-view rule.
• Administration is checked by the server.
• Signed-out requests receive the intended rejection.

Inspect the client bundle and credential lifecycle

Browser code and mobile packages are distributable artifacts. Inspect generated output and configuration for credentials that grant privileged service access. A value named “secret” is not safe merely because it came from an environment variable; public build variables can be compiled into the client.

Classify each credential by purpose, scope, owner and rotation process. Use the least authority required for a task. Keep privileged operations behind an authenticated server and avoid sharing live secrets in agent prompts. A screenshot of a settings panel can expose a token as easily as a source file.

If a credential has been exposed, revoke or rotate it promptly. Removing it from the current source does not invalidate the copy already distributed, and repository history can preserve it. GitHub’s remediation guide is useful for understanding why deletion and revocation are different actions. Check logs and other distribution paths as part of the response.

Technical references: GitHub: removing sensitive data

Protect operations that cost money or change state

A model endpoint, file conversion or email sender can be abused even if it returns no private data. Require the intended identity and permission, bound the input, cap work and define per-user limits. Measure server-side usage rather than trusting a client counter. Decide what happens when a request times out after the underlying work has already succeeded.

For purchases or credits, test repeated delivery and interrupted responses in a safe test environment. A retry should not grant the same entitlement twice or charge a user twice. Verify external event signatures using the relevant provider’s current documentation. Do not rely on the return URL alone as proof of a completed payment.

Document recovery authority. A support operator may need to repair an entitlement, but that ability should be scoped, recorded and distinguishable from ordinary user actions. Security and observability meet here: you need enough information to investigate without retaining sensitive request bodies indefinitely.

Check uploads, rendering and dependency changes

Try empty, oversized, malformed and unsupported inputs. For uploads, inspect file size limits, accepted formats, storage access and download behavior. A file extension is not a complete validation strategy. Confirm that error messages help the legitimate user recover without revealing internal credentials or another user’s details.

Review how untrusted text reaches the interface, database and external tools. Prefer established framework escaping and parameterized operations. If the application deliberately renders HTML, it needs an appropriate sanitization design. Treat model output as input to validate, not as privileged instructions just because the application requested it.

Inspect dependency additions in an agent diff. Ask why each package is needed, whether it is maintained and which authority it gains. A successful installation is not a trust assessment. Keep lockfiles and a reproducible build, and prioritize updates that resolve an identified risk rather than indiscriminately changing the entire stack before release.

Publish an evidence register rather than a blanket verdict

For every check, store the rule, test environment, result, tested revision and remaining limitation. Label an untested condition as untested. An automated scan may identify a known dependency problem while missing an application-specific ownership rule. A manual click test may demonstrate a journey while missing an API route.

Assign an owner and review date to unresolved items. Higher-risk applications may need a qualified independent assessment. This guide is a practical engineering review framework, not a penetration test, compliance opinion or guarantee against compromise. Keep the release decision proportional to the data and authority the app handles.

Specific answers

Common questions