AI writes code and installs packages: 5 checks before shipping an app to production

An AI assistant built a user dashboard, connected the database and showed you a working page. Now call the API as another user: if it returns someone else's profile, the app is not ready to ship. Passing tests do not rule this out, especially if they only check successful sign-in and page loading.

Habr has published a practical look at the security of AI-written code and the agents that run it. Its useful central point is simple: faster development also gives the team more actions to check. The assistant suggests libraries, installs dependencies, reads files and runs commands. Each of these actions needs clearly defined access boundaries.

For developers, this is a reason to rethink code review. For product managers and founders, it means adding a few checks to the “the demo works” criterion, without which shipping remains a gamble.

Start with someone else's profile

The most useful checks often look mundane. Can a user read someone else's order by changing an identifier in a request? Is a table accessible without authentication? Does a name entered by a user go straight into HTML?

The article gives an example of an app built on Supabase. A public key in the frontend does not, by itself, mean there is a data leak: Row Level Security policies should restrict access to rows. The problem arises when the app is already connected to the database but access rules have not yet been configured or are too permissive.

Test this with separate scenarios: a request without a token, a user's request for their own resource and the same user's request for someone else's. The last one is especially important. Checking that “the person is signed in” does not answer the question “does this document belong to them?”

Static analysis helps identify dangerous operations and exposed secrets. But without your product's rules, it generally cannot determine who is entitled to read a particular order. That requires review and authorization checks.

Checking a dependency starts with its name

The second problem arises before the app even runs. A model may suggest a plausible name for a library that has never existed. If an attacker registers that name, the next installation brings their code into the developer's environment.

Imagine an agent needs a library to process documents. It suggests a package, installs it and carries on. The developer sees a finished feature, but no one has checked where the dependency came from. In some ecosystems, third-party code can run during installation itself.

Every new dependency should therefore be checked against the project's official documentation. Then pin the version and use a lockfile when building. This makes installation reproducible, although it does not, by itself, prove that the chosen package is safe.

Disabling installation scripts has limits too: a library may run malicious code later, when the app imports it. A scanner for known vulnerabilities may also miss a newly published malicious package. These measures complement checks on the package's provenance.

Agents need limits on their permissions

When an assistant gets terminal access, the risk extends beyond generated code. It can install a package, read a file containing keys or follow an instruction found in someone else's README. External text becomes dangerous if the agent treats it as permission to act.

The practical response is to grant access according to the task. Fixing an interface usually does not require production secrets or permission to publish packages. Dependency installation commands, access to secrets and infrastructure changes warrant separate oversight.

Before the next release, you can choose five checks: access to other users' resources, the provenance of new packages, reproducible installation, secrets in code and logs, and agent permissions. These are specific places where a small mistake can turn into a data leak or the execution of third-party code.

The article itself remains an overview: individual examples and studies cannot tell you the probability of your particular service being compromised. Asking a model to “check security” offers no guarantee either. Useful results come when the team turns recommendations into verifiable release criteria and assigns an owner to each one.