Five security gates for AI-generated code before it reaches production
Before Vibe Coding launches, AI-generated applications must undergo checks at five security stages: identity and permissions, data and keys, dependencies, business behavior, and fault tolerance. Simply being functional does not guarantee it can handle real user data.
Gate one: identity and permissions
List which operations are allowed for anonymous users, which require login, and which are only accessible by administrators. Test lateral privilege escalation with two ordinary accounts: Can Account A read or modify records of Account B by changing object IDs? Hidden buttons do not constitute server-side authorization.
Database views should also be checked separately. By default, PostgreSQL checks the underlying relationships using the view owner's permissions; setting `security_invoker` allows for caller permissions and RLS policies are influenced by this choice. Verify access identities according to the actual database version, do not assume that enabling RLS automatically satisfies expected isolation.
Gate two: data and keys
Ensure that front-end code, build artifacts, logs, and version control do not contain server-side keys. Confirm that sensitive fields are only returned if necessary, and ensure error responses do not leak complete internal information.
User passwords should be stored using a salted slow hash suitable for password storage, handled by mature libraries for parameter and validation logic. Reversible encryption is typically avoided, and it is never appropriate to use a quick one-time hash instead.
Gate three: dependencies and execution environments
Add AI-recommended packages to official projects and package repositories, verify their names, maintainers, and versions. Save lock files after checking them in isolated environments. Scripts for installation, database migrations, and deployment should be checked in isolation before interacting with production credentials.
Gate four: business behaviour and exceptional paths
Turn requirements into verifiable rules, such as 'duplicate payment requests cannot be deducted again' and 'orders cannot be created when inventory is insufficient.' Test empty inputs, excessively long inputs, timeouts from third parties, repeated submissions, and behavior after revoking permissions.
Static Application Security Testing (SAST) can assist in identifying code issues, while Software Composition Analysis (SCA) can help analyze component risks. However, business authorizations and state transitions still require scenario testing. Repeating AI reviews to confirm the correctness of the code does not equal an independent proof of correctness.
Gate five: release and recovery
Save rollbackable versions before release, verify backups and recovery in actual tests, and confirm that logs can identify the operator and anomalies. Initially release within controlled scopes, then expand usage based on operational results.
Choosing an architecture should serve the size and complexity of your team and business. A clear, well-defined monolithic application can be a reasonable starting point; breaking it into microservices does not automatically eliminate issues such as authorization, data consistency, or operational concerns.
Do all production checks need to be performed on prototypes? Using simulated data and isolated environments can simplify the process. When connecting real identities, data, or payment capabilities, ensure that corresponding validations are in place.
Who is responsible for the final quality of AI-generated code? It should be someone who can explain critical logic and take responsibility for a release. Review conclusions need to be supported by testing and evidence.