The admin panel is beautiful. It only shows up for users with role: 'admin', and the button is tucked behind a clean little feature flag. But the API routes behind those buttons don't know they're admin routes. Any logged-in user can call them directly. The guard lived in the frontend the whole time.
Function-level authorization is the question 'is this caller allowed to use this feature at all?' — as distinct from BOLA's 'is this caller allowed to touch this object?' When the answer lives in the UI instead of the route handler, any logged-in user becomes effectively an admin the moment they know the URL.
What your AI actually built
You asked for an admin dashboard with user management, org settings, and a feature toggle panel. The model built all three. It added a nice sidebar that only renders for admins, and it wrote the corresponding API routes: DELETE /api/users/:id, POST /api/orgs/:id/plan, PATCH /api/flags/:name.
What it did not do is add a role check on any of those routes. Each handler only verifies the caller is logged in. 'The UI hides the button from non-admins' was the implicit assumption. The UI is a suggestion; the API is the boundary.
On top of that, there are usually hidden endpoints the UI never even calls — /api/internal/debug/users, /api/admin/impersonate — that the model added 'just in case' and nobody added auth to because nobody was testing them.
How it gets exploited
A regular user with a paid account opens the browser dev tools and views the JavaScript bundle.