AI-assisted development is making it possible for people across a business to create useful internal applications without traditional software-development teams. For security leaders, the challenge is deciding which risks need to be controlled centrally — without attempting to turn every small internal tool into a fully governed enterprise application.
“Vibe coding” creates an interesting problem for security teams.
An employee can now describe a relatively simple business problem to an AI assistant and have a functioning application remarkably quickly. That changes the economics of software development inside an organisation.
Historically, the effort required to build an application acted as a natural gate. Development resources were scarce, infrastructure needed provisioning, deployment required technical knowledge and security often entered the process through established engineering practices.
AI is removing much of that friction.
The obvious security response is to introduce new friction: security reviews, architecture approvals, vulnerability assessments, coding standards and conventional SDLC controls for everything that gets built.
I am not convinced that scales and believe there is another approach.
Rather than trying to ensure that every small AI-built application is engineered to the same standard as a customer-facing production system, control the environment in which those applications are allowed to exist.
The objective becomes less about trusting the application and more about establishing controls around it that the organisation can trust.
Start with the risk, not the application
For a small internal application, the security questions I care about most are not necessarily whether every function has been elegantly written or whether the application’s internal identity model is perfect.
I care about questions such as:
- Can somebody outside the organisation reach it?
- Can an unauthorised employee reach it?
- Can a former employee reach it?
- Can somebody change the production code without another person being involved?
- Can the application expose credentials?
- Can somebody deploy arbitrary code outside our controlled environment?
- Can we understand what happened if something goes wrong?
Those risks can often be controlled without depending heavily on the application itself and that is an important distinction.
If I can enforce network access, corporate identity, deployment control, source control and secrets management outside the application, then I do not need every person building an internal tool to correctly reinvent those controls themselves.
Build a security boundary you can trust
The model I favour is to provide a controlled environment into which these applications can be deployed.
The exact technology is not particularly important. What matters is that certain security properties are inherited from the platform rather than being optional decisions made by each application creator.
For example:
- Code must live in centrally controlled source repositories.
- Protected branches and pull-request approval prevent an individual from directly changing production code.
- Applications deploy through a managed CI/CD path rather than informal manual deployment.
- Production workloads run on centrally controlled infrastructure.
- Network controls make these applications internal by default.
- Access is placed behind a mandatory corporate OIDC identity boundary.
- Secrets are stored through a managed secrets mechanism rather than embedded in source code.
- Appropriate platform and access logging exists centrally.
None of these controls require the application itself to be particularly sophisticated and that is the point.
The less security depends upon the quality of the vibe-coded application, the less assurance we need to obtain from that application.
Authentication is a useful example
Consider Joiner/Mover/Leaver controls.
A vibe-coded application might maintain its own user database. It might even still contain an account belonging to somebody who left the organisation six months ago.
That looks bad if you assess the application in isolation.
But security controls should be assessed in the context of the architecture around them.
If that application is only reachable through corporate network controls and every request must first pass an centrally managed corporate OIDC boundary, the stale local account does not necessarily represent an enterprise access-control failure.
The former employee cannot reach the application.
Their VPN or corporate network access has been removed and their corporate identity can no longer pass the mandatory OIDC boundary.
The local account might be untidy. It might eventually present a data-retention issue. But we are not relying upon the application’s local account lifecycle to prevent former employees accessing the system.
That distinction matters.
Security teams have finite capacity. We should concentrate assurance effort on the controls on which our security model actually depends.
The application does not have to be architecturally perfect
Once someone has passed the mandatory corporate access boundary, I am considerably less interested in dictating how every low-risk internal application works.
- The application owner might consume the OIDC identity and use the claims provided by it.
- They might build their own application roles and authorisation model.
- They might even maintain a completely separate authentication mechanism inside the application.
That last option may be redundant or architecturally inelegant, but that does not automatically make it a security problem that central security needs to solve.
The mandatory control remains outside it.
This is an important principle:
Security does not need to enforce architectural perfection where architectural imperfection does not materially increase risk.
That mindset becomes increasingly important as AI makes software creation cheaper.
Security assurance should follow blast radius
The other half of this model is knowing when the lightweight approach is no longer appropriate.
An application that helps one department manipulate some low-sensitivity internal information presents a very different risk from one that processes regulated data or performs privileged actions against production systems.
The method used to create the application is almost irrelevant and what matters is its potential impact.
As characteristics change, e.g. external exposure, sensitive information, privileged access, significant business dependency, consequential automated decision-making, the assurance expectations should change with them.
At some point the application stops being something we are comfortable containing with platform controls and becomes something whose internal behaviour we genuinely need to trust.
That is when traditional secure-development practices, deeper architecture review, vulnerability management, testing and formal ownership become proportionate.
The mistake is assuming everything must begin there.
Security should enable experimentation safely
AI-assisted development is going to make internal software creation easier whether security teams like it or not.
Trying to solve that entirely through prohibition or heavyweight approval processes risks creating an environment where the approved route is so difficult that employees look for ways around it.
A better security outcome may come from accepting that these applications will exist and making the safe route extraordinarily easy.
- Give people an approved place to put code.
- Give them an approved way to deploy it.
- Put strong identity, network, change and infrastructure controls around it.
Then apply deeper assurance only when the risk justifies doing so.
This is not lowering security standards.
It is deciding where those standards need to be enforced.
For many small internal applications, I would rather have a poorly engineered application operating inside a well-controlled security boundary than a beautifully engineered application somebody deployed into an environment I know nothing about.
The aim is not to trust every vibe-coded app. The aim is to make sure we do not have to.
