Confirm who can read and change the database
The first check establishes whether data has its own protection and permissions match the necessary operations. In Supabase projects, I check RLS and explicit policies alongside granted access. I request reading and writing tests with ordinary users instead of accepting a statement that every security option has simply been switched on.
Imagine an application for a company producing personalised promotional items. It contains orders, design files and internal production notes. A person may need to consult their order status without reading observations intended for staff. That distinction should remain valid when data is consulted through the journey the application provides to customers.
The review should identify relevant tables, permitted operations and evidence that other access is refused. If testing uses a privileged account, ask for that to be declared. Its powers may differ from those of the application's eventual users and conceal an unsuitable configuration that a normal account would expose.
I also ask for attention to alternative ways of consulting the same data, such as views or functions created to simplify reporting. Protection on the main table does not remove the need to check how those paths are configured. The result should explain who can obtain each set of information and why.
This rule belongs in planning the application before coding because it depends on relationships between data and people. If those relationships are only discussed at publication, review may uncover an unresolved product decision already affecting several journeys. Addressing it then can involve more than changing a single security setting.
To prepare your next step, explore Security for applications developed with AI.
Check that the server decides permissions and important values
The second check looks for important decisions that rely only on the browser. Identity and authorisation should be confirmed on the server, while values determining an operation need a valid source. Form contents are incoming information, not evidence that the person submitting them is authorised to carry out the requested action.
For the promotional item order, the browser may display a price and an approval option. That does not mean it should independently determine the accepted amount or who may approve. The system needs to consult the verified rules and information that support that specific operation within the project being delivered.
Ask the agent to identify user-supplied fields that could affect a decision: identity, organisation, access level or approval status. Review should show how each is handled. Hiding those fields on screen is insufficient if subsequent processing trusts them without appropriate confirmation from the system that is responsible for the action.
Tests should show that an input incompatible with the rule is refused before producing an effect. A visual message may be correct while the saved record is wrong. Evidence therefore needs to include the stored result or the absence of a change, according to the expected behaviour for that case.
Require authorisation for every requested resource
The third check confirms that knowing a resource's identifier is insufficient to read or change it. Each request should connect the verified identity with the resource and intended action. The rule must also apply to attachments and exports whenever they carry information that needs protection, including through services outside the main application.
In the promotional items example, two companies may have orders in the same application. A legitimate user from the first still lacks permission to view the design uploaded by the second. Review needs to follow access to both the order and its file, including the service where that file is stored.
Prepare fictional data that demonstrates separation in an authorised environment. Testing should show that correct access works and incorrect access is refused without using real customer documents. This makes the rule observable and lets you repeat the check when a relevant change affects the journey or the way files are delivered.
This is a concrete application of testing before handing over an automation. Validation follows the business consequence: who receives what and who can change the state of the work. The report should distinguish a control found in the code from behaviour that was actually exercised with the relevant accounts and data.
Look for secrets in anything that can leave the server
The fourth check looks for credentials appearing in shared code, files sent to the browser or execution records. Private keys belong in appropriate server configuration mechanisms. I request a report identifying locations and risk without printing the value of any secret found, which would create another copy during the review itself.
A messaging integration may need a private credential, but the application's user does not need to receive it. The server performs the authorised operation and returns the necessary result. If the key appears in code downloaded by the browser, a private repository does not resolve that particular route of exposure.
When preparing the working environment for Claude Code, separate configuration examples from actual values. A file with variable names and blank placeholders can guide installation without revealing credentials. Review should confirm that files containing secrets have not been included in the material intended for sharing with others or publishing online.
If an exposed credential is found, removing the code line does not close the issue. The compromised credential and any places where it may remain available need attention, with someone responsible for replacement and service continuity. The report should record completed and outstanding actions without presenting a cosmetic cleanup as complete resolution.
Validate inputs before using them
The fifth check follows incoming data and confirms that it is accepted only under the intended conditions. I request server validation, suitable limits and rules consistent with the operation. Assistance in a form improves the experience but does not replace controls protecting how the information is processed and stored by the application.
A quantity of promotional items should respect the type and limits defined for an order. A design file should meet accepted format and size conditions. Rules need to reflect what the business can handle, with a clear response when the information received is unsuitable for completing the request as intended.
Validation does not mean resolving every risk with a single text check. Content displayed as HTML, database queries and uploaded files require treatment appropriate to the context in which they will be used. Ask the agent to explain those destinations and corresponding controls without treating a generic filter as a guarantee.
At the end, I want five answers tied to evidence, including the reviewed version, executed tests and known limitations. A failure affecting important data or actions needs resolution before the intended publication. After correcting it, repeat the affected checks so the final decision corresponds to the code that will actually be delivered.