AI features can accelerate creation, but they also amplify mistakes, permission sprawl, and unintended data access. When non-specialists can generate workflows or logic quickly, security teams must assume more inconsistent controls and weaker review discipline. That increases the need for governance, testing, and access oversight around the full build and deployment lifecycle.
Why This Matters for Security Teams
AI-assisted low-code and no-code development changes the risk profile because it compresses the time between intent and deployment while widening the set of people who can create logic, integrations, and data flows. That speed is useful, but it also weakens the usual review gates that security teams rely on. The result is more shadow workflows, more embedded secrets, and more accidental exposure of sensitive data across app connections and automations. Guidance from the NIST Cybersecurity Framework 2.0 still applies, but the control challenge is different when the builder is a business user guided by AI rather than a trained engineer. NHIMG research on The State of Secrets in AppSec shows that 43% of security professionals are already concerned about AI systems learning and reproducing sensitive information patterns from codebases.
That matters because low-code platforms often turn permissions, connectors, and secrets handling into reusable abstractions that are easy to over-trust. When AI generates app logic, it can also generate insecure assumptions about authentication, token scope, or data sharing boundaries. The practical risk is not just a bad workflow, but a workflow that appears legitimate, passes through business review, and still exposes a wide blast radius if a connector or identity token is over-privileged. In practice, many security teams encounter the breach path only after a “quick automation” has already copied data into an unsanctioned service or reused a secret outside its intended scope.
How It Works in Practice
AI features in low-code and no-code platforms typically influence risk in three ways. First, they accelerate creation of workflows, forms, and integrations, which means more apps are built before security review can catch up. Second, they lower the skill threshold for connecting systems, so sensitive data can move across SaaS tools, APIs, and internal data stores without a security architect in the loop. Third, they can generate or suggest logic that looks plausible but is not aligned to policy, especially around access control, error handling, and data minimisation.
Security teams should treat these platforms as production development environments, not as “lightweight” tools. That means controlling:
- Connector approvals, especially for email, file storage, CRM, and ticketing systems that hold sensitive data.
- Secret handling, including token storage, rotation, and scoping to the minimum required permissions.
- Data classification rules that block regulated or confidential data from being pulled into prompts, automations, or generated code.
- Change review for AI-generated workflows, with logging that records who created the logic, what data it touches, and which identities it uses.
NHIMG guidance in the Top 10 NHI Issues and the OWASP NHI Top 10 is especially relevant here because these platforms often create non-human identities on the fly through service accounts, API keys, and delegated tokens. The control question is not only “who can build?” but “what identity does the workflow run as, and what can that identity reach?” These controls tend to break down when a platform allows broad cross-app connectors and self-service publishing because privilege sprawl becomes invisible until an incident occurs.
Common Variations and Edge Cases
Tighter governance often slows the very teams that adopt low-code and AI tools to move faster, so organisations have to balance delivery speed against control depth. That tradeoff is real, and best practice is still evolving. There is no universal standard for AI governance in citizen development yet, but current guidance suggests that the riskiest cases are the ones with external data sources, regulated records, or automated actions that trigger payments, notifications, or account changes.
Edge cases often include prototypes that quietly become production, AI-generated apps that inherit broad workspace permissions, and “temporary” integrations that never get retired. The biggest blind spot is usually identity reuse: a workflow starts with a shared service account, then expands into multiple automations until no one can tell which task used which permission. Where this intersects with secrets management, the remediation burden rises quickly, especially if teams already have fragmented control over tokens and connectors. NHIMG research on The State of Secrets in AppSec and the Ultimate Guide to NHIs underscores why “easy to create” must be matched by “easy to govern.” In practice, the hardest failures come from platforms that let business users ship integrations before security can see the identities, data paths, or retention rules involved.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | AI-built apps often create fragile secret and token handling. |
| OWASP Agentic AI Top 10 | A1 | AI generation can create unsafe actions and hidden privilege paths. |
| CSA MAESTRO | GM-3 | Citizen-built AI workflows need governance over identities and actions. |
| NIST AI RMF | GOVERN | This question centers on governance for AI-assisted development risk. |
| NIST CSF 2.0 | PR.AA-01 | Low-code AI changes how identities and access must be controlled. |
Inventory every connector secret and enforce short-lived, rotated credentials for each workflow.
