Your operations manager built a field-service app over a weekend. Your sales team has a quoting tool that pulls from spreadsheets and your CRM. All of it was built with an AI coding assistant, it works, and people love it.
The payoff can be real. In BTI client experience, customers developing in Claude have saved as much as $500,000 per year in Salesforce license fees, even at a roughly 100-person company.
Then someone asks a simple question: “Can we roll this out to the whole company?” Or a customer sends a security questionnaire. Or your cyber insurance renewal asks how your applications are monitored. That is the moment many teams hit what we call the Claude Wall, and vibe coding security stops being a side issue.
The app did exactly what it was asked to do. It was just never asked to be secure, governed, or ready to run a part of your business.
Vibe coding security risks: signs you have hit the Claude Wall
If your team has built tools with AI assistance, you will probably recognize several of these:
- Secrets in the code. API keys, database passwords, and tokens are pasted directly into source files or config that sit in a repository. GitGuardian’s 2025 research found 23.8 million new hardcoded secrets in public GitHub commits in 2024 alone, a 25% increase over the prior year.
- No real access control. Anyone with the link gets in, or everyone shares one login. No MFA, and no way to remove access when someone leaves.
- No audit log. When a record changes or data is exported, nobody can say who did it or when.
- No backups or recovery plan. The database lives on a free or personal tier. If it is deleted or corrupted, it is gone.
- You cannot pass a security questionnaire or cyber insurance review. Questions about encryption, logging, incident response, and change control have no good answers.
- It breaks when you scale it. What worked for five users fails at 200.
- It was not built for AI agents to call safely. AI agents will need to read and act on this data, and the app has no safe, scoped way to let them.
None of this means the builder did a bad job. The app simply outgrew being a prototype.
Why vibe-coded apps are not production ready
AI coding assistants are very good at producing working software quickly. They optimize for “does it run” and “does it do what I described.” Unless someone explicitly asks for identity integration, secrets management, logging, and least-privilege permissions, those things usually do not appear. That is the core of most AI-generated code security risks: not bad code, but missing controls.
Most of this development also happens outside governed environments. A typical stack is a GitHub repository, a front end deployed on Vercel, and a database and authentication layer on Supabase. These are excellent tools with real security features. The problem is not the tools. The problem is how prototypes get deployed: on personal accounts, outside your company’s identity system, with nobody from IT or security reviewing configuration, monitoring activity, or owning the response if something goes wrong.
The gap shows up in breach data. In IBM’s 2025 Cost of a Data Breach Report, 13% of organizations reported breaches involving AI models or applications, and 97% of those said they lacked proper AI access controls. The same report found that most breached organizations had no governance policies in place to manage AI or prevent shadow AI. That is why vibe coding governance belongs inside your broader AI security, governance and risk program, not beside it.
Finally, these apps were designed for humans clicking buttons. As businesses adopt AI agents, the app must also serve machine users, with tighter permissions and clearer guardrails. We cover that shift in more depth in why your organization isn’t agentic yet.
Eric’s take: it is already connected to your business
From Eric Brackett, Founder and President of BTI Communications Group
Almost no vibe-coded app is truly standalone. To be useful, it connects to enterprise systems along the way: a SharePoint list, a OneDrive folder of spreadsheets, a shared mailbox, the CRM, the ERP. And those connections are almost always made with one person’s own sign-in. The builder authorizes the app with their Microsoft 365 account, and from that point on the app looks exactly like an ordinary domain user going about their day. Your IT and security teams have a very hard time seeing it, let alone telling it apart from normal activity. So the app is outside the enterprise, but its hands are inside your data.
Why do good people build this way? Because the alternative is often impossibly onerous. Most mid-sized organizations have internal IT plus several outsourced IT, SaaS, and security vendors, and every one of them is doing its job, which is to keep things locked down. Asking for a service account, a sandbox, or a new API permission can mean tickets with three or four parties, each waiting on the others. Weeks go by. So builders route around the process, not out of bad intent, but because the business needs the tool now.
The answer is not to stop people from building, and it is not to lock things down harder. It is to give everyone a governed path that is faster than the workaround.
How to secure vibe-coded apps in Microsoft Azure
Bringing an AI-built app inside means moving it into an environment your organization governs, secures, and monitors, without throwing away the work your team did. For most of our customers, that environment is Microsoft Azure, because it shares the same Microsoft 365 and Entra ID identity, security policies, and monitoring as the rest of the business. Here is what it typically includes:
Identity and access
- An Azure landing zone. A policy-driven foundation with separate development, test, and production environments, cost controls, and guardrails that prevent risky configurations.
- Entra ID single sign-on and MFA. Users sign in with their company identity. Access is granted by role and removed automatically when someone leaves.
- Managed identities. The app authenticates to databases, storage, Microsoft 365 data, and other services with its own identity instead of a builder’s personal sign-in, and without stored passwords at all. IT can finally see the app as an app.
Secrets, network, and deployment
- Azure Key Vault. Any secret that must exist is stored, rotated, and access-logged in a vault, never in code.
- Private networking. Databases and back-end services are not exposed to the public internet. Traffic flows over private endpoints, with a web application firewall in front of anything public.
- CI/CD with approvals. Code moves from repository to production through an automated pipeline with security scanning, required reviews, and a human approval before anything reaches production. GitHub can remain part of this, now inside your organization’s governance.
- Change control. Documented changes, rollback plans, and a clear production owner.
SOC and SIEM monitoring, backup, and continuity
- Logging into a SIEM. Application, identity, and infrastructure logs flow into a SIEM where they are correlated and retained, giving you the audit trail questionnaires and insurers ask for.
- 24/7 SOC monitoring. Someone is actually watching those logs around the clock and responding to alerts, not just collecting them.
- Backup and continuity. Automated, tested backups with defined recovery objectives and a plan for outages.
Safe access for AI agents
- APIs and permissions designed for AI agents. Well-defined APIs that agents can call with their own identities, scoped to least privilege. Agents can read what they need and propose actions, while sensitive steps such as payments, deletions, or customer communications require human sign-off. Every agent action is logged.
The result is the same app your team built, now able to pass an audit, scale, and safely serve people and AI agents.
Vibe coding security checklist: is your app production ready?
Use this list to judge whether an app is ready for production or still on the wrong side of the Claude Wall:
- Does the app have a named business owner and a technical owner?
- Are all users signing in through your company identity provider with MFA?
- Are there zero secrets in the code or repository, including the history?
- Is the database private, encrypted, and backed up, and has a restore been tested?
- Is the app deployed into a company-owned cloud subscription, not a personal account?
- Do code changes go through review, automated security scanning, and approval?
- Are application and access logs sent to a SIEM and monitored 24/7?
- Do you know what data the app touches, and whether any of it is regulated?
- Can AI agents access the app only through scoped APIs with their own identities, with human approval for high-impact actions?
- Could you answer a customer security questionnaire or cyber insurance application about this app today?
If you answered “no” or “not sure” to three or more, the app is a good candidate to bring inside. For a wider look at your environment, try our security self-assessment checklist.
How BTI helps: co-managed vibe coding governance
For more than 40 years, BTI Communications Group has helped organizations across Los Angeles, Chicago, and Phoenix run IT, communications, cybersecurity, security systems, and AI they can trust. As a Microsoft Partner, we help customers take what their teams have built with AI and deploy it securely in Microsoft Azure, with SOC and SIEM controls in place from day one. It is the same discipline we bring as an outsourced AI partner and through our managed IT services.
Our approach is delivered in a co-managed way:
- Assessment. Starting with a cybersecurity assessment, we inventory your AI-built apps and tools, including the personal Microsoft 365 and OneDrive connections they quietly depend on, review code, data flows, and hosting, and rank them by business value and risk.
- Migration. We move the app into an Azure landing zone, connect it to Entra ID, move secrets into Key Vault, set up private networking, and build a CI/CD pipeline with approvals. Your builders stay involved.
- Hardening. We apply least-privilege access, configure logging into a SIEM, design agent-ready APIs with human sign-off for sensitive actions, and align controls with the frameworks you answer to through our governance, risk and compliance practice, such as ISO 27001 compliant practices, HIPAA, or the FTC Safeguards Rule.
- Co-managed governance. Through our co-managed IT model, we work alongside your internal IT team and your existing SaaS and security vendors, not around them. We set up a clear shared responsibility model, a sanctioned sandbox, and a single, fast request path for permissions, so builders get what they need without weeks of tickets and IT keeps the control it is accountable for. Internal IT, vendors, builders, and leadership stay informed and work together instead of against each other.
- Ongoing managed security. Our 24/7 NOC and SOC, backed by a SOC 2 Type II audited partner, delivers cybersecurity services that monitor your apps and infrastructure, respond to incidents, and keep controls current as the app evolves.
The goal is not to slow down the people who are building, and it is not to sideline the people who protect your systems. It is to turn promising prototypes into governed business systems that deliver measurable ROI without creating new risk.
Ready to get past the Claude Wall?
If your team has built AI tools or mobile apps that may not be production-ready, let’s talk. Schedule a free consultation with BTI, and we will help you identify which apps to bring inside first and what it will take to secure them in Azure.
Vibe coding security FAQs
Is vibe coding a security risk?
It can be. Vibe coding itself is not the problem; the risk comes from AI-built apps reaching real users and real data without enterprise controls such as company sign-in, secrets management, audit logging, backups, and monitoring. Treat any vibe-coded app that touches business data as production software.
What is the Claude Wall?
The Claude Wall is BTI’s name for the vibe-coding wall: the point where an app built quickly with an AI coding assistant works for a small group but cannot go further because it lacks enterprise basics such as single sign-on, secrets management, audit logging, backups, monitoring, and change control.
How do you secure a vibe-coded app?
Move it into a company-owned, governed environment. In Microsoft Azure that typically means Entra ID sign-in with MFA, managed identities instead of personal sign-ins, secrets in Key Vault, private networking, a CI/CD pipeline with security scanning and approvals, logs sent to a SIEM with 24/7 SOC monitoring, and tested backups.
Are Supabase, Vercel, and GitHub insecure?
No. They are capable, widely used platforms with their own security features. The risk comes from how prototypes are typically deployed on them: personal accounts, no connection to company identity, no central logging or monitoring, and no one accountable for security in production.
Do we have to rebuild our AI-built app from scratch?
Usually not. In most cases the core application logic can be kept. The work focuses on identity, secrets, networking, deployment pipelines, logging, backups, and permissions, which are the pieces AI assistants tend to skip.
What is the difference between shadow IT and shadow AI?
Shadow IT is any technology used without IT’s knowledge or approval. Shadow AI is the AI version: unsanctioned AI tools, agents, and AI-built apps, including vibe-coded apps connected to company data through someone’s personal sign-in. Both are solved the same way, by giving people a sanctioned path that is faster than the workaround.
Why does an app need to be ready for AI agents?
AI agents are increasingly used to look up information and take actions inside business systems. An app designed only for human users often gives an agent too much access or none at all. Agent-ready design gives each agent its own identity, scoped permissions, full logging, and human approval for sensitive actions.
Our builders route around IT because getting permissions takes weeks. How do we fix that without losing control?
That friction is common when internal IT and several outsourced IT, SaaS, and security vendors each own a piece of the environment. BTI’s co-managed approach sets up a shared-responsibility model, a governed sandbox, and one fast path for access requests, so builders move quickly, IT and vendors keep oversight, and leadership can see what is being built and where it connects.
