TL;DR: Citizen development is expanding because low-code, no-code and generative AI tools let business teams build faster, but the same shift creates shadow IT, unmanaged identities, weak logging and excessive access across business-built apps, according to Pluto Security. The security problem is not the tooling itself, but the assumption that platform controls substitute for application governance.
At a glance
What this is: Citizen development is moving application creation into business teams, and Pluto Security says the main security failure is that these apps often bypass traditional review, identity, logging and access controls.
Why it matters: IAM, PAM and NHI teams need to treat business-built apps as governed assets because service accounts, API tokens and AI agents can accumulate privileged access outside standard oversight.
Context
Citizen development is the practice of letting non-technical teams build workflows, automations and applications with low-code, no-code and AI-assisted tools. The governance gap appears when those creations inherit access to business data and connected systems without the controls usually applied to enterprise software.
The core issue is not speed versus safety, but where accountability sits when business units build production-like processes outside central engineering. In that environment, identity boundaries blur, platform trust gets overextended, and security teams lose the visibility needed to govern the resulting access paths.
Key questions
Q: What breaks when citizen-developed apps are not brought under governance?
A: The main failure is that business-built apps begin to behave like production systems while remaining outside the controls that normally govern production systems. That means ownership is unclear, access is broader than intended, logging is incomplete, and integrations can be created without review. The risk is not only exposure, but the creation of durable, unmanaged access paths that security teams cannot reliably see or revoke.
Q: Why do business-built apps create identity risk even inside approved platforms?
A: Approved platforms can still host risky identities because the app, not the platform, defines who can act, what data can be reached and how long access persists. Service accounts, API tokens and agent identities often bypass normal lifecycle controls, especially when business users create them informally. That creates an identity governance gap even when the underlying platform is sanctioned.
Q: How should security teams govern citizen development without slowing delivery?
A: Use a guardrail model instead of a blanket approval model. Security teams should define approved patterns, classify apps by sensitivity, require ownership, restrict default access and monitor for exceptions. That preserves delivery speed while making risky applications visible enough to control. The goal is not to stop business-built apps, but to make them governable before they scale.
Q: When should AI-assisted workflows be treated as higher risk than standard automations?
A: Treat them as higher risk as soon as the workflow can select data, trigger actions or call external services with minimal human review. AI assistance compresses the time between idea and deployment, which increases the chance that unsafe prompts, overbroad permissions or unintended actions become operational. Once the workflow can make decisions or chain integrations, it needs stricter governance than a simple task automation.
Technical breakdown
Why business-built apps escape traditional application governance
Citizen-developed applications often sit inside approved SaaS or low-code platforms, which makes them look benign even when they are not. That creates a governance blind spot: architecture review, security testing, change control and logging standards are applied to the platform, but not consistently to the app, workflow or connector built on top of it. Once business users can create integrations, they can also create new trust relationships without a formal review cycle. The result is not just shadow IT, but shadow control planes running on trusted infrastructure.
Practical implication: Treat each business-built app as a separately governed asset, not as a harmless extension of the platform.
How non-traditional identities expand the attack surface
The article correctly highlights service accounts, API tokens and AI agents as the identities most likely to escape IAM governance in citizen development environments. These identities often have broader access than human users, are reused across workflows, and are rarely subject to the same lifecycle controls as workforce accounts. When that happens, privilege grows through convenience rather than design. In practice, the dangerous part is not just authentication, but ownership, scope and revocation across the full identity lifecycle. See the Agentic AI Security Policy Template.
Practical implication: Inventory non-human identities tied to citizen apps and put them under the same ownership and rotation expectations as other machine identities.
Why AI-assisted workflow generation changes the control model
AI copilots reduce the effort needed to generate logic, queries and workflows, but they also compress the time available for design review. That means security problems can emerge before a team even recognises that an app is effectively production-facing. AI-driven prompts can introduce risky data use, unexpected actions or unsafe integrations, especially when the workflow is built by someone who does not understand the downstream trust implications. The control challenge is therefore shifting from code review to intent, data boundaries and approval of connected actions. See the Agentic AI Security Guide.
Practical implication: Govern prompt use, data inputs and autonomous actions in low-code AI workflows as first-class security controls.
Threat narrative
Attacker objective: Exploit a trusted business-built application path to reach data and systems that were never intended to be exposed through an unmanaged workflow.
- Entry occurs when a business user creates a workflow or app inside an approved platform and connects it to internal data or SaaS services without security review.
- Credential access follows when the app uses service accounts, API tokens or delegated connector permissions that are broader than the task requires.
- Escalation happens as the workflow is extended, reused or repurposed, allowing the original access scope to expand across data sources and systems.
- Impact is achieved when the ungoverned app exposes regulated data, creates an unauthorized integration path, or becomes a persistent source of weakly monitored access.
NHI Mgmt Group analysis
Citizen development creates governance debt when app creation outruns identity control. The security failure is not low-code itself, but the mismatch between how fast business users can assemble workflows and how slowly governance processes usually adapt. When security teams do not own the inventory, classification and approval boundary, the organisation accumulates applications that behave like production systems without being treated like them. The practical conclusion is that citizen apps need explicit governance, not informal tolerance.
Non-human identities are the real control point in business-built applications. Service accounts, API tokens and AI agents are the identities that carry privilege through citizen-developed workflows, and those identities are often least visible to IAM and PAM teams. service account security becomes essential when the build layer and the access layer are decoupled. The field should stop treating these identities as implementation details and start treating them as the primary unit of risk.
Shadow IT is now a shadow trust problem, not just a tooling problem. Approved platforms can still produce unsafe systems when teams assume vendor-level controls cover app-level risk. That assumption fails as soon as connectors, prompts and delegated permissions are chained together outside review. The wider implication is that governance must move from platform approval to per-application trust decisions.
Citizen development needs a policy model built for speed, not exception handling. Heavy-handed approval gates will keep pushing builders toward unmanaged channels, which is why the control objective has to be guardrails, templates and scoped permissions. The best operating model is one that defines safe patterns, tracks ownership and makes deviation visible before privilege accumulates. The practical conclusion is to govern the pattern of build, not just the platform used to build it.
What this signals
Citizen development is becoming an identity governance problem as much as an application governance problem. The deciding factor is no longer whether a business user can build something quickly, but whether the resulting access paths are owned, scoped and reviewable. That makes non-human identity inventory, connector policy and privilege review part of the same control stack rather than separate programmes.
Low-code and AI builders will keep widening the gap between creation speed and control maturity. Security programmes that rely on annual review cycles will miss the moment when a harmless workflow becomes a privileged integration. The practical response is to govern at issuance time, not after the app has already spread across the business.
For practitioners
- Create a full inventory of citizen-built applications Track every low-code app, workflow and automation as an individual asset, with business owner, data classification, environment and connector list recorded at intake.
- Put non-human identities under explicit ownership Assign a named owner to each service account, API token and bot tied to a business-built app, then review scope, rotation and revocation on a fixed cadence.
- Restrict connector and data-source permissions by default Start with least privilege for every integration, especially where low-code tools reach SaaS tenants, databases or regulated datasets, and require approval for scope expansion.
- Turn on logging before apps go live Require platform-native audit trails, event logging and alerting for workflow changes, data access and agent actions before a citizen-built app is allowed into production.
- Set explicit guardrails for AI-generated workflows Define approved prompts, allowed data inputs and permitted actions for AI-assisted builders so that model output cannot create unchecked access paths or unsafe integrations.
Key takeaways
- Citizen development creates a governance gap when business users build apps that inherit data access and integrations without the controls applied to enterprise software.
- The most important risk is the spread of non-human identities such as service accounts, API tokens and AI agents outside IAM and PAM oversight.
- Security teams should focus on inventory, ownership, least privilege and logging so citizen development stays fast without becoming ungoverned.
Related NHI Mgmt Group resources: Low-Code Agent Platform Security Guide · Agentic AI Security Policy Template · AI Agent Identity Security Buyer's Guide · Agentic AI Security Guide · Shadow AI and AI Agent Discovery Guide
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Citizen-built apps often accumulate broad connector and service account access beyond task need. |
| NHI-10 — Human Use of NHI | Business users are creating and operating identities that should not be handled informally. | |
| Recommendation — Apply NHI-05 by scoping every business-built app to the minimum access its workflow requires. Separate human builders from machine identities and require explicit governance for any human-created NHI. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centers on overbroad permissions and weak access review in citizen apps. |
| Recommendation — Review and tighten entitlements for every app, connector and workflow that reaches sensitive data. | ||
| CIS Controls v8 | CIS-5 — Account Management | Service accounts and shared credentials in citizen development need explicit lifecycle management. |
| Recommendation — Inventory, approve and regularly review all accounts used by citizen-built applications. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The main control gap is excessive access granted to apps, connectors and service identities. |
| Recommendation — Enforce least privilege across low-code apps, connectors and delegated accounts. | ||
| MITRE ATT&CK | TA0006; TA0010 — Credential Access; Exfiltration | Uncontrolled connectors and tokens can be abused to reach data and extract it from business apps. |
| Recommendation — Map citizen app risks to credential access and exfiltration paths in detection and review. | ||
Key terms
- Citizen Development: Citizen development is the practice of allowing non-traditional developers to build applications, automations, or workflows using accessible tools. It can improve speed and productivity, but it also introduces governance, access, and data protection risks unless security teams define clear boundaries and review points.
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
- Shadow IT: Shadow IT is the use of applications or services outside formal enterprise approval or visibility. In SaaS environments, it often includes department-purchased tools and unsanctioned integrations that create hidden identity, data, and access paths the security team cannot readily govern.
- Least Privilege: A security principle requiring that every identity, human or non-human, is granted only the minimum permissions necessary to perform its function. Least privilege is the single most effective control for reducing NHI blast radius.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps identity and security teams bring business-built apps and their non-human identities under control.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org