Everyone Is a Builder - Now Security Has to Catch Up
AI-built applications and autonomous agents are pushing security teams to rethink visibility, permissions and development controls.
AI is changing who gets to build software, not just how quickly developers can write it. The definition of a builder has expanded beyond engineers to include employees with no coding experience, who can now create applications that interact with business data and production systems. Increasingly, it is expanding beyond humans altogether, as AI agents gain the ability to take multistep actions across software environments.
Recent cybersecurity incidents have offered a glimpse of what happens when AI systems move from assisting with software to acting within real environments. In separate disclosures this summer, OpenAI and Anthropic described AI models operating in cybersecurity evaluations that moved beyond their sandboxes to interact with real systems. As AI shifts from generating answers and code to taking actions, the security boundary shifts with it.
This creates a new form of shadow IT. Security teams are no longer only dealing with applications employees have adopted without approval, but applications built by employees outside established development and security processes as well as AI agents operating across systems with limited oversight. Restricting AI outright is unrealistic. Security must evolve to govern both the people and agents now building and acting within the enterprise.
Shadow IT Is Becoming Shadow Development
The biggest change is that software development is no longer confined to traditional developers. Orca Security’s 2026 State of AI Security Report, based on telemetry from more than 1,200 production organizations, found that 51% of organizations are already using AI to build custom applications. Analysts, marketers and product managers can increasingly create software that once required an engineering team.
From a security perspective, job title is not the important part. What matters is what they built, what it connects to and what permissions it has. A marketing application can access customer information. A finance workflow can touch sensitive data. An AI agent can have credentials for cloud services. That is why I see shadow development as different from shadow IT. An application that connects services, identities and data sources creates a broader security concern. IBM’s 2025 Cost of a Data Breach Report found that one in five organizations studied experienced a breach involving shadow AI. To me, the takeaway is simple – you cannot secure applications you do not know exist.
The Development Pipeline Is No Longer the Whole Security Boundary
Application security has historically had obvious places to apply controls: repositories, code review, CI/CD pipelines and deployment workflows. Those controls still matter, but they no longer cover everything being built.
Professional developers are using AI to produce code faster, while non-engineers are creating applications outside traditional development workflows. At the same time, tools like GitHub Copilot CLI can plan complex tasks, edit files, run tests and iterate on their work with limited human involvement. The challenge is no longer simply reviewing more code. It is securing software created by more people, across more environments, with AI agents taking on more of the development process.
The answer cannot be more human review; it’s impossible to scale. If development is moving faster, security cannot depend on checkpoints designed for a slower era. It has to operate at the same speed and inside the workflows where software is actually being built.
Visibility Has to Come Before Control
The first response to new technology is often to limit its use. But with AI, restriction does not necessarily create control. If approved processes are too slow, employees can turn to another service, a personal account, or an application security never sees. The risk has not been eliminated. Security has simply lost visibility into it.
I would rather know that 100 AI applications exist and understand which three create meaningful exposure. That is better than believing I have prevented AI adoption while dozens are being built outside my view. That means starting with discovery: What is being built? Who owns it? What identities does it use? What data can it reach? What happens if it’s compromised?
We also cannot expect every builder to become an application security expert. A developer may want technical details about a vulnerability. A business user may simply need to know whether there is a problem and how to fix it quickly. And as AI agents begin taking on more of the building themselves, security will need to adapt again.
The Next Builder May Not Be Human
I believe the shift from people using AI to AI agents building on their behalf is where the conversation becomes much more interesting. The number of people capable of building software will continue to grow, but that may not be the most significant change. Soon, every employee may have AI agents building and modifying software on their behalf. When that happens, identity and permissions become even more important. An agent should act within the context and access of the person it represents, meaning security teams will need to understand the application, the agent that created it, and the actions it was allowed to take.
None of this makes me pessimistic about AI. I believe AI will strengthen security far more than it threatens it. But we learned something important from the cloud: when technology changes where software lives and how quickly it moves, security has to adapt quickly. The organizations that succeed will not be those that stop people or agents from building, but those that can see what they are doing, understand the risk and secure it at the same speed.