At a glance
There are two questions every application has to ask about a request. Who are you? and are you allowed to have this?
AI-built software is reliably good at the first and reliably forgets the second. That single gap is the most common serious defect we find, and it is the one with legal consequences attached.
The two questions, properly explained
Authentication is proving who you are. Logging in with an email and password. AI handles this well, because it is a standard, visible, self-contained problem with a well-known shape, and it fails loudly when it does not work.
Authorisation is whether the logged-in you may have this particular thing. Not "can you use the invoices page", but "may you see invoice number 4,417 specifically".
The second question has to be asked separately, every time, for every record. There is no single place you can put it and be finished. And unlike a broken login, a missing authorisation check fails completely silently, showing the requester exactly what they asked for.
What it looks like in practice
The address bar version is the easiest to picture.
You are logged in, looking at your own invoice, and the address ends in /invoice/4417. You change it to /invoice/4416. If the check is missing, you are now reading somebody else's invoice, and the application considers this an entirely normal request, because you were logged in and you asked politely.
The same pattern hides everywhere: a report that filters by a value the browser supplied, an API that returns a record by its identifier, a file download, an export. Anywhere the request says which item it wants, the software has to independently verify you are entitled to it.
Why AI misses it so consistently
Two reasons, and both are structural rather than accidental.
It learned from examples that deliberately leave it out. Tutorial code exists to demonstrate one concept clearly. An example showing how to fetch a record does not clutter itself with ownership logic, because that is not what it is teaching. The model absorbed the shape of the demonstration, not the shape of a real system.
Absence is invisible. AI is good at producing code that does something. Authorisation is code that prevents something, and nothing in the request or the resulting behaviour signals that it is missing. The feature works perfectly either way.
Why nobody catches it
Because the software behaves flawlessly during every test anyone actually runs.
You test with your own account, on your own data. Every record you request is yours, so every request correctly returns something you are allowed to see. The check being absent produces results identical to the check working.
Finding it requires deliberately trying to access someone else's data, which requires two accounts, which requires it to occur to you as a thing worth doing. Most people building their first application have never been given a reason to think of it.
The part that makes it more than a bug
If the exposed data is personal, this is not merely a defect. It is very likely a personal data breach, with the obligations that follow: assessing it, and in many cases reporting it within seventy-two hours and telling the people affected.
We are developers rather than lawyers, and you should take proper advice on your specific situation. But the general shape matters: the expensive part is rarely fixing the code. It is the notification, the loss of trust, and the customer who reads the email and quietly decides not to renew.
There is also a nastier property here. Because the flaw is invisible, you often cannot say afterwards what was actually accessed unless the logging happens to be good, and in this class of application it usually is not.
How to check, today, for free
Two accounts and five minutes.
- Create a second test account with its own data.
- Log in as the first account and note the identifier of one of its records from the address bar.
- Log in as the second account and request that identifier directly.
- You should be refused. If you can see it, you have this problem.
- Repeat for anything that returns a file, an export, or a report.
If you get through that cleanly, well done, genuinely. If you did not, the fix is not usually enormous, and it gets smaller the sooner it happens.
This is the first thing we look for in an AI Code Audit, our fixed-price £495 review. We find some version of it more often than not.
The pattern is the one this series keeps returning to: AI is a brilliant typist and a terrible architect. It typed a function that fetches a record. Who may have it was a decision, and decisions were never its job.
Found something you did not like in that five-minute test? Get in touch for a no-pressure conversation.
