How should security teams govern citizen development in generative AI and low-code environments?

Why This Matters for Security Teams

Citizen development in generative AI and low-code platforms expands who can create business logic, connect data sources, and trigger actions. That speed is useful, but it also widens the blast radius if approvals, permissions, and secrets handling are weak. NHI Management Group’s Top 10 NHI Issues highlights that unmanaged non-human access often becomes a hidden control gap long before it becomes a visible incident. Security teams should treat these builders as governance subjects, not just end users.

The main mistake is assuming the platform itself provides sufficient restraint. In practice, low-code and GenAI tools often make it easy to connect SaaS apps, API keys, and internal data with minimal friction, while the underlying identity and secret sprawl remains outside the creator’s awareness. That is why guidance from the NIST Cybersecurity Framework 2.0 is useful here: governance must be mapped to clear ownership, access management, and monitoring, not informal trust. In practice, many security teams encounter risky citizen-built automations only after a sensitive connector is already live and behaving like an unsanctioned production integration.

How It Works in Practice

Governance works best when it is layered into the platform lifecycle rather than bolted on after deployment. The starting point is to define who may build, who may approve, and what kinds of data or tools each builder role can touch. That means separating experimentation from production, and separating read-only access from the ability to write back, invoke external actions, or create service connections. For GenAI features, this is especially important because prompt chains, model outputs, and connectors can trigger downstream activity faster than a human reviewer can react.

Security teams should align controls to the specific risk of the environment. Current guidance suggests using least privilege for connector access, approval workflows for any step that exposes secrets or production data, and logging that captures both the builder identity and the non-human identity used by the app at runtime. NHI Management Group’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is a useful reference for thinking about issuance, rotation, review, and retirement as a lifecycle rather than a one-time configuration.

• Use separate builder, approver, and operator roles so no single citizen developer can self-authorise risky integrations.
• Require just-in-time access for elevated actions, especially where secrets, external APIs, or production records are involved.
• Inventory every connector, bot, and shared credential so non-human access can be reviewed like any other privileged pathway.
• Monitor for abnormal data movement, prompt injection effects, and unapproved workflow changes.

For GenAI-specific policy design, the NIST AI 600-1 GenAI Profile is a practical way to translate risk into controls over data handling, output review, and human oversight. These controls tend to break down when teams allow direct production connectors without central registration because the platform can execute changes faster than the approval process can respond.

Common Variations and Edge Cases

Tighter governance often increases friction for business teams, requiring organisations to balance delivery speed against the risk of uncontrolled automation. That tradeoff is real, especially where low-code platforms are used by operations, finance, or customer-facing teams that need rapid iteration. Best practice is evolving, but a common pattern is to allow broad experimentation in sandboxes while reserving production deployment, external data access, and secret binding for restricted workflows.

One edge case is “shadow citizen development,” where a well-intentioned employee builds a useful automation outside the formal platform. Another is delegated administration, where business units can approve their own tools but lack the expertise to judge privilege creep. A third is shared service accounts, which can hide accountability and make revocation impossible without breaking multiple apps at once. NHI Management Group’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives is relevant here because auditability matters as much as technical control.

For environments with many connectors and frequent app changes, the DeepSeek breach is a cautionary example of how exposed credentials and weak boundaries can turn convenience into exposure. The same pattern appears in citizen development when secrets are embedded in workflows, copied between apps, or reused across teams. In those cases, governance breaks down fastest when no one owns the lifecycle of the non-human access behind the app.

Related resources from NHI Mgmt Group

• How should security teams govern API keys used for generative AI access?
• How should security teams govern third-party access to development environments in cloud-native pipelines?
• How should security teams govern non-human identities in cloud environments?
• How should security teams govern AI-generated code in production environments?