Low-code security isn’t vibe coding, but it isn’t foolproof either
Low-code platforms occupy awkward middle ground for IT. They’re not the Wild West of vibe coding, where AI generates raw code that nobody understands and no vendor supports. But they’re not traditional vendor software either, where security is entirely someone else’s problem.
Power Platform, Salesforce, and ServiceNow ship with real guardrails, so it’s not surprising that IT feels more comfortable when citizen developers build on sanctioned platforms like them. The trouble is that comfort can obscure a different kind of risk—the configuration choices individual builders make may happen outside IT’s direct line of sight.
Gartner forecasts that by 2026, 80% of low-code users won’t be in IT. That’s a lot of people making configuration choices on platforms IT selected but can’t realistically monitor app-by-app. The platform handles the hard security problems, but it can’t stop someone from connecting to a database with their personal credentials or granting broader permissions than the app actually needs.
What makes low-code different from vibe coding
Low-code and no-code platforms give you visual development environments with drag-and-drop interfaces, pre-built components, and integrations that would take months to build from scratch. IT typically selects these platforms, configures them to meet organizational security requirements, and oversees them from there. When something breaks, there’s a vendor to call and documentation to reference.
AI coding tools generate raw code from natural language descriptions, and the person who built the app often can’t explain how it works because they described what they wanted and an AI made it happen. There’s no vendor security team patching vulnerabilities, no built-in governance, and nobody on call when it breaks at 2 a.m.
Low-code platforms abstract security into the platform layer, so authentication, access controls, and audit logging come pre-configured rather than hand-coded. Vibe-coded outputs need all the same security scrutiny as any custom development, but the people building them rarely have the expertise to provide it. If Power Platform apps worry you less than whatever ChatGPT just generated for the sales team, your instincts are solid—they just need to account for the whole picture.
What low-code platform guardrails actually protect
Enterprise low-code platforms do reduce risk compared to letting users write raw code or vibe-code solutions. Authentication infrastructure gets handled at the platform level, integrating with your existing identity provider so you’re not trusting each citizen developer to figure out OAuth flows on their own. Role-based access controls become configuration clicks rather than custom code that might have holes in it, and audit logging happens whether anyone remembers to implement it or not.
Microsoft, for example, publishes detailed documentation on how Power Platform addresses the top 10 web application risks from the Open Web Application Security Project (OWASP). That includes clickjacking prevention, Content Security Policy (CSP) support, and “Default Deny” design principles. Salesforce offers Security Health Check to continuously monitor configurations against baseline standards, plus Shield for encryption and event monitoring if you’re in a regulated industry. These are real security investments that most citizen developers couldn’t replicate if they tried.
Where low-code platform guardrails fall short
Say your marketing director builds a customer intake form in Power Apps, connects it to Dynamics using her own credentials because that’s the fastest way to get it working, and deploys it to the team without mentioning it to anyone in IT. Now every user who submits a form is implicitly operating with her access level, and nobody can tell the difference between legitimate usage and something suspicious. The platform didn’t stop her because it can’t enforce dedicated service accounts if the builder never configured them.
OWASP has cataloged these gaps in the Citizen Development Top 10. Account impersonation, like the scenario above, is near the top of the list. Excessive permissions come next.
Developers grant broad access during development because they just want the thing to work, but they may not always tighten controls before deployment. Data exposure happens because platforms handle authentication but they might not automatically prevent builders from exposing sensitive information through misconfigured sharing settings or poorly designed data flows.
Research published in June 2025 revealed five Common Vulnerabilities and Exposures (CVEs) in Salesforce Industry Clouds related to FlexCards and Data Mappers, components where seemingly minor configuration decisions bypassed field-level security entirely. Salesforce has since addressed these issues, but the underlying pattern remains instructive. The vulnerabilities weren’t exotic attack vectors requiring nation-state resources. They were the kind of mistakes any citizen developer could make without realizing the potential consequences.
Static and dynamic application security testing designed for conventional code usually can’t inspect low-code outputs at all. These platforms are easy to use because they hide complexity, and that complexity stays hidden from your security tools too. You trust the platform because you chose the platform, but that trust doesn’t automatically extend to every app built on it.
When low-code outputs still need review
The Spiceworks 2026 State of IT report confirms what you’re probably already seeing at your company. People are adopting AI tools faster than governance can keep up. That gap between capability and oversight applies to low-code as well as vibe coding. Platform guardrails don’t substitute for governance—they just make it easier to implement.
You can’t review everything, though, especially if you’re a one-person shop or a small team already stretched thin. A practical filter helps. If the app connects to a system of record like your enterprise resource planning (ERP), CRM, or financial systems, it deserves scrutiny. Apps handling customer or employee data that would trigger a breach notification warrant a closer look, and external integrations where a credential leak would be embarrassing or expensive shouldn’t go live without review. Everything else can probably wait until you have more bandwidth.
Ask what connects to what, who can see the data flowing through, and whether access controls make sense for all user types rather than just the person who built the app. Then, verify that any API connections follow credential management best practices. If you’re on Power Platform, the data loss prevention (DLP) policies in the admin center can help you see which connectors are in use across your environment.
While you’re at it, make sure someone other than the original builder can explain what the app does, because that person will eventually go on vacation or leave the company.
Governance you can manage
Low-code platforms have earned IT’s trust by building security into the foundation rather than bolting it on as an afterthought. That doesn’t mean you can stop thinking about security, but it does mean the hard problems are largely handled for you. What’s left is the kind of governance you can actually manage without hiring a dedicated team or slowing innovation to a crawl. Focus on the apps that matter most, build lightweight review habits, and let the platform do what it was designed to do.
