Securing 1,000 vibe coded repos

AI has made software generation cheap enough that organisations risk producing more software than they can meaningfully govern.

If a hundred employees make a hundred apps you will have a hundred different forms of authentication, logs, and more. With a hundred different forms for one solution there is no ownership, patching and reviews become impossible, it is simply not viable.

AI needs to be restrained in a centralised manner but lacks the context of an organisation. As a result each repository becomes independent of each other. The experience is fragmented and the chances of vulnerability generation increase significantly as critical parts of applications such as auth are implemented with a thousand different variations. Instead AI should be able to look up how we implement authentication/authorization across applications, any code snippets that are used and more. This creates a more grounded approach, there is one mechanism to be reviewed by the security team and as it’s consistent across the board updating it is painless.

Code reviews are disappearing but what about secure code? Code generation is too fast to review and which PRs are worth reviewing?

AI wants documentation too

The issue is that AI is only aware of what’s in the current repository, tools, skills etc. but a company’s software goes beyond the repository. There are standards, rules, processes and decisions that the agent may have no context of.

The documentation humans use is similar to what AI needs, but it could be better suited for agents. Documentation should act as both rules and a cookbook. An AI agent should be able to query the cookbook, see if there is already a recipe for what it is trying to build and understand the rules it needs to follow.

This brings consistency and ownership instead of treating every repository as its own independent environment.

Reduce, reuse, and recycle

Certain functions such as authentication, authorisation, logging and database access are common across applications. The issue is that when this knowledge and context isn’t given to the AI agent, it creates its own interpretation.

AI agents shouldn’t recreate these components every time. They should be able to reuse approved code snippets, libraries and implementation patterns that already exist across the organisation.

This gives a better user experience, improves security and creates clear ownership. The team that owns the implementation can update it or introduce a security fix centrally, while AI agents can identify applications using that pattern and update the repositories accordingly.

Instead of generating another version of authentication, recycle the one the organisation already trusts.

AppSec isn’t just for humans

Shifting left allowed developers remediate issues before code reviews, the same loop works with coding agents.

AI agent makes changes
Run AppSec pipelines such as code scanning, SBOM etc
Review issues
Patch and verify the fix works
Ensure the changes did not affect functionality.
The importance is verification, AI should have the tools needed to dynamically verify functionality rather than static code.

What’s new?

A PR of a UI overhaul is harmless compared to changing authz and authn. A change to my note taking app isn’t important compared to a change in a production service. As a result repositories and changes should not be treated as equals. Repositories should be catagorised on significance and risks, if this repository were to be vulnerable what’s the worst that could happen? AI should review the contents of the changes, any sensitive/critical services touched should force a review by the security team.

Remote Environments > Local

Remote environments are much easier to control, offer better performance and more. Tools such as Claude Code and Codex still lack a straightforward mechanism for centrally deploying and continuously updating all Skills, MCP configuration, and agent settings across developers’ local environments.

Data segregation is also important. The chances of AI deleting irrelevant files are low but never zero. To let a coding agent act autonomously it should live in its own environment, it’s simply an unnecessary risk. This also allows security to easily manage secrets by distributing, killing and regenerating because when an environment spins down so can its secrets.

Coding isn’t limited to engineers but staff may not know what skills/MCPs are or the risks of installing unknown skills/MCPs. Remote environments lets staff be ready to go without having to think of what tools their setup may need, how to point it to internal MCP servers etc.

Conclusion

The security that should be introduced isn’t new, it just needs to be applied. Some companies talk about Mythos like models scanning for vulnerabilities which can be useful but its costly especially if your coding environments do not constrain or guide AI to good practices.