Before an Agent-Built App Touches Production, Test Its Server

Say a team asks a coding agent for a small internal app, and a week later it works. It has a login screen and hides the admin buttons from everyone else, and people like it. Now it's about to be connected to the systems that hold real customer and order data.

Before that happens, someone should check whether the server knows who's calling it.

What the studies keep finding

A team of researchers posted a study of vibe-coded applications to arXiv in June and revised it in September. They audited 200 publicly deployed apps built with AI coding agents and found at least one vulnerability in 91% of them, with about two-thirds of the issues rated critical or high. The problems clustered in broken access control, injection and authentication failures.

That matches a Cloud Security Alliance research note from April, which pulled together earlier studies and named authorization flaws and missing access controls among the dominant weaknesses, especially in flows with several roles or steps.

The server has to check too

The app checks the user's role in the browser and hides the admin pages from everyone else. The server, though, accepts whatever the browser sends. If a request says "I'm an admin" or asks for another user's record, the server believes it.

Nothing about this shows in a demo. Everyone clicks through the screens they're allowed to see, and everything works. The gap only appears when someone calls the server directly, which anyone with a browser's developer tools can do.

Ask an agent for "only admins should see the settings page" and it will often hide the page in the browser without a server check.

Test it as a stranger and as the wrong user

Before the app touches production data, run two sets of tests against every endpoint.

First, call each one without logging in. Anything that returns data or changes something, apart from the login itself, is a finding.

Then log in as an ordinary user and try what that user shouldn't be able to do, like reading another user's records by changing an ID in the request, or setting your own role in the request body. Log every request that works.

Ask an agent for these tests directly: one per endpoint per role, each expecting a refusal, from a list of endpoints and roles you give it. Then read the tests yourself to make sure they check the server's response.

Check for secrets while you're there

Search the repository and its history for API keys and database passwords. Agents paste them into code when it's the quickest way to make something work, and once they're in a commit they're in the history. Rotate anything you find, then move it to the platform's secret store.

Put it on a list

Internal apps built this way often belong to the team that asked for them, and security may not know they exist. Add them to whatever list security keeps of internal apps, with a named owner, and require the two test runs above before any of them gets a production connection. For a small app that's a few hours of work.