Replace the generic request with an observable rule
A negative test starts with a rule that can be confirmed, such as preventing a collaborator from reading another customer's requests. Specify who attempts the action, on which record and under what conditions. The outcome should describe the rejection and the state that must remain intact after the attempt is made.
“Test security” leaves too much room for interpretation. AI might check the login, open a few pages and conclude that it found no errors. That does not answer the business question: can someone with access to one project consult another project for which they have never received authorisation?
Imagine a hypothetical portal with two projects and two collaborator accounts. Each account should only see its respective project. Ask for a test in which the first account tries to open a record from the second project. The expected outcome includes not receiving that record's content, even if the account knows its address.
Add the action of changing it. Someone may have permission to read a proposal but not to approve its execution. The test should check whether an attempted approval is rejected and whether the proposal retains its previous state. Authorised reading does not resolve the separate question of permission to write.
These rules should emerge when planning the application before coding. Asking questions at this stage clarifies decisions that AI cannot make on the business's behalf. If nobody has defined who may approve, a passing test merely confirms an assumption introduced during development, rather than a requirement the team agreed.
To prepare your next step, explore Security for applications developed with AI.
Choose accounts and data that reveal the difference
Prepare test identities with different permissions and records belonging to each one. Include someone without an active session and another person with limited access. Use fictional information that makes improper exposure recognisable, avoiding real customer data and any sending or modification outside the environment intended for this particular test exercise.
In the hypothetical portal, I would call the records “Test project A” and “Test project B”. The distinction needs to be visible to the person reading the report. If every account is an administrator or shares the same data, the exercise cannot demonstrate isolation between users with different responsibilities.
I would also prepare an account whose access has been removed. The expected behaviour must be defined: that person may no longer read or change the protected project. Testing only newly created accounts leaves unexamined what happens when responsibilities change and access that used to be valid comes to an end.
Tell AI what it may execute. For example, create fictional records, start test sessions and inspect results within that environment. Exclude real messages, charges and changes to customer accounts. A request for testing needs operational boundaries as clear as those of the functionality being tested in the first place.
Record the starting point before the attempt. For an approval, save the request's state and version; for a value, save the current amount. Without this reference, a report can display an error message while missing a change that happened despite the rejection shown to the person using the application.
Test different routes to the same action
The rejection should hold across the routes that can reach the action, including direct requests to the server. Do not limit verification to a button being absent from the screen. Ask AI to connect tests to the entry points that exist in your application and present the checks it could execute.
An interface can hide the delete option while the server continues accepting the operation. In an authorised test of your own application, verification should confirm that the rule is enforced where the request is processed. The screen's appearance tells you about the interface; by itself, it does not prove effective authorisation.
The same care applies to attachments and exports. If a project's page is protected but its document is accessible to any account, the test needs to identify the difference. Include the resources that form part of the task, instead of testing only the first screen that someone encounters along the way.
If there are several user types, combine permitted and rejected cases. An authorised collaborator should be able to read their own project; the same account should be prevented from opening the other one. A system that blocks everything also passes a poorly designed check that looks exclusively for rejected attempts.
Ask for a report containing the executed case, expected result and observed result. If AI could not start a particular session or reach an entry point, record that as a test not executed. Do not accept missing results summarised as success, or a description of code replacing an execution that was requested.
Include invalid data and states that prevent progress
Beyond permissions, test inputs that violate process rules: empty required fields, values outside limits and changes to an old version. Define the expected response in each case. The application should explain the rejection usefully and avoid saving a partial operation that would leave the work in an inconsistent state afterwards.
In a hypothetical purchase request, quantity might need to be positive and a justification required above a limit set by the company. AI needs these conditions before constructing the cases. Do not ask it to invent acceptable values just to fill in a testing table without business decisions behind it.
Test the exact boundaries, including the permitted value and the first value that is no longer accepted. That comparison shows whether the rule has been implemented with its intended meaning. The same reasoning applies to limits for an automation that changes advertising budgets, where a mistaken interpretation can have concrete consequences.
Also consider a request that is already complete. If the rule says approval may happen only once, repeating the action should not create another execution or an improper notification. The team should decide how repetition is handled and request evidence of that behaviour, including what remains recorded after both attempts.
During concurrent editing, someone may try to save an outdated version. The expected result might be a request to reload the information, rather than silently replacing more recent work. This case tests a rule about collaboration and data integrity, even when everyone involved has legitimate permissions to perform their work.
Use failures to correct the rule and repeat the proof
When a test fails, retain the case that exposed the problem and confirm the correction with the same attempt. Run the related permitted journey again as well. End the review with a clear list of results and gaps so the team knows what was demonstrated and what still requires verification.
If an account opened a record it should not have, the next task is to fix authorisation and test that access again. Hiding the address or removing the button that made the failure visible is insufficient. The rule has to withstand the same attempt at the point where the application decides to serve data.
If the test was wrong, correct it with an explicit decision about the intended behaviour. A supervisor may be supposed to access both projects, and the selected account may have held that role. In that case, the result reveals a problem with the exercise, rather than necessarily a failure in the application itself.
Keep these cases for subsequent changes. A new export, a new role or a change in document storage can open a route that has not yet been checked. The test collection needs to follow these changes, with cases tied to rules that remain relevant to how the business operates.
This work complements testing an automation before handing it over to the team. AI helps prepare and execute checks, but results need evidence and clear limits. A useful report distinguishes what works, what was correctly rejected and what remains untested, so the team can make its next decision.