What do organisations get wrong when they assume low-code and AI automatically make development safer?

Why This Matters for Security Teams

Low-code and AI platforms reduce the friction of building workflows, but they do not remove the security obligations that sit behind every publish button, connector, token, and approval path. The most common failure is assuming platform guardrails are equivalent to governance. That assumption breaks quickly when citizen developers can wire data sources together, when AI assistants generate logic that no one fully reviews, or when a single shared credential gives broad access across environments.

Security teams also underestimate how quickly small mistakes become repeatable at scale. NHIMG research on The State of Secrets in AppSec shows that organisations are still struggling with secret sprawl, delayed remediation, and uneven developer practice. In a low-code context, those same weaknesses appear inside app builders, automation engines, and AI-assisted workflows. A workflow that is easy to publish is also easy to propagate insecure defaults.

Controls still need to map to well-defined requirements such as NIST SP 800-53 Rev 5 Security and Privacy Controls, especially around access enforcement, configuration management, and auditability. In practice, many security teams discover over-permissive automations only after a business process has already been exposed to unnecessary data or privilege.

How It Works in Practice

Safer low-code and AI development depends on treating the platform as an execution layer, not a trust boundary. The right question is not whether the tool is fast, but whether every automation has a verified identity, bounded permissions, and reviewable change history. For AI-assisted development, that means outputs must be treated as untrusted until they pass policy checks, testing, and approval.

In practice, mature teams separate three things:

• Who can create or modify workflows, with role separation for builders, approvers, and operators.
• What the workflow can access, using least privilege and narrowly scoped secrets rather than shared broad credentials.
• When a change is allowed to go live, with versioning, approval gates, and logging that supports post-change investigation.

This is where identity and secret governance matter. Low-code tools often make it easy to connect APIs, databases, and SaaS services, but that convenience can hide a fragile trust chain. If the platform stores long-lived tokens, or if AI-generated code inherits credentials from a developer session, then one mistake becomes a reusable access path. The risk is not only code quality. It is also whether the platform can prove who changed what, which connector was used, and which data moved.

Guidance from DeepSeek breach is relevant here because it illustrates how quickly sensitive data exposure can spread once development and operational boundaries are weak. For control design, teams should align low-code pipelines with NIST controls for access control, audit logs, and change management, then enforce them at the platform layer rather than relying on developer discipline alone.

These controls tend to break down when organisations allow direct production publishing from AI-assisted builders because no single owner can reliably review every generated change.

Common Variations and Edge Cases

Tighter control often increases delivery overhead, requiring organisations to balance speed against assurance. That tradeoff is real, and current guidance suggests it should be managed through risk-based segmentation rather than blanket restrictions. Highly regulated workflows need stronger approval and logging than internal productivity automations, even if both are built in the same platform.

One edge case is so-called shadow automation, where business teams create useful flows outside central review because the approved path feels too slow. Another is AI-generated configuration that appears correct but silently expands access, duplicates data movement, or bypasses a human approval step. Best practice is evolving here: there is no universal standard for how much autonomy an AI-assisted workflow should have before it requires mandatory review, but organisations should assume that higher autonomy requires tighter change control.

Security teams should also watch for shared environment patterns. If development, test, and production reuse the same connectors, secrets, or service principals, then “safe enough for testing” becomes a direct production risk. The practical answer is not to ban low-code or AI. It is to define clear boundaries, short-lived credentials where possible, and explicit publishing authority. That becomes even more important as workflow builders grow more capable and easier to reuse across business units.

NHIMG’s The State of Secrets in AppSec is a useful reminder that confidence and control are not the same thing, especially when a platform can scale a weak pattern faster than a traditional developer team ever could.

Related resources from NHI Mgmt Group

• What do organisations get wrong when they try to make BYOD compliant across different device types?
• What do organisations get wrong when they assume AI is a general-purpose solution?
• What do organisations get wrong when they assume passwordless login automatically means stronger security?
• What do organisations get wrong when they assume blockchain automatically removes the need for intermediaries?