The security exposure created when non-professional builders assemble automations, apps, or agentic workflows with limited governance. These environments can accumulate weak controls, excessive permissions, and unclear ownership, making it harder for security teams to review access, validate data handling, and enforce policy consistently.
Expanded Definition
citizen developer risk refers to the security exposure created when business users or non-professional builders design automations, apps, or AI-enabled workflows outside mature engineering controls. In NHI environments, the concern is not the act of building itself but the combination of weak approval flows, opaque data paths, and over-broad access that can emerge when governance is thin.
Definitions vary across vendors because some treat citizen development as a low-code productivity topic, while others focus on the access and policy risks that appear once those workflows call APIs, store secrets, or trigger agents. NHI Management Group treats it as a governance problem: the builder may be trusted, but the artefact can still create standing privilege, unmanaged secrets, and unclear ownership. That distinction matters when evaluating a workflow that touches production systems or sensitive credentials. Frameworks such as the NIST Cybersecurity Framework 2.0 help anchor the risk in access control, asset visibility, and continuous monitoring.
The most common misapplication is assuming a low-code tool is low risk, which occurs when teams approve production use without reviewing permissions, data retention, or fallback ownership.
Examples and Use Cases
Implementing citizen development safely often introduces friction, because every shortcut that speeds delivery can also widen the review burden for security and IAM teams, requiring organisations to weigh agility against control. That tradeoff becomes sharper once automations begin handling secrets or invoking agents.
- A finance analyst builds an approval flow that can read invoices and send payment requests, but the workflow inherits broad mailbox and storage access, creating an invisible privilege chain. This is the type of pattern highlighted in Top 10 NHI Issues.
- A marketing team publishes a customer-facing app through a low-code platform and pastes API keys into shared configuration fields, bypassing central secret management. That failure mode aligns with the concerns in The State of Secrets in AppSec and the need to validate secret handling against OWASP guidance for AI-enabled applications.
- An operations manager connects a citizen-built bot to ticketing, cloud, and chat tools, but no single owner is assigned for access review, so dormant permissions persist after staff changes.
- A frontline team creates an agentic workflow that approves routine actions, yet the workflow can escalate when prompts or triggers are modified without security review, which mirrors the control gaps described in the OWASP NHI Top 10.
Why It Matters in NHI Security
Citizen developer risk matters because many of the resulting assets behave like NHIs even when they were not created by engineering teams. They authenticate to services, store credentials, move data, and make execution decisions. If those artefacts are not inventoryed, reviewed, and owned, they become shadow identities with no reliable lifecycle management. NHI Management Group research shows that 72% of organisations have experienced or suspect a breach of non-human identities, and 46% confirmed a breach, which underscores how quickly weak governance can become operational loss.
This is where Ultimate Guide to NHIs and Why NHI Security Matters Now are useful references, because they frame governance as a lifecycle discipline rather than a one-time approval. The practical challenge is not just misuse of tools, but loss of accountability across identity, secret, and data boundaries. Organisations typically encounter the real cost only after a workflow leak, access abuse, or production incident, at which point citizen developer risk becomes operationally unavoidable to address.
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 OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Citizen-built workflows often fail through secret sprawl and weak identity governance. |
| OWASP Agentic AI Top 10 | Agentic workflows built by non-professionals can introduce unsafe tool use and prompt-driven abuse. | |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access control is central when citizen developers connect business tools to production systems. |
| NIST AI RMF | Governance and risk management apply when low-code tools incorporate AI features or autonomous actions. | |
| NIST Zero Trust (SP 800-207) | Zero trust principles help constrain unmanaged workflows that call sensitive services and data stores. |
Inventory citizen-developed automations, remove embedded secrets, and enforce approval before production use.
Related resources from NHI Mgmt Group
- Why do AI agents create more IAM risk than ordinary developer tools?
- Why do AI agents create more NHI risk than ordinary developer automation?
- How should security teams reduce risk from AI agents and developer tools that use secrets locally?
- Why do AI coding environments create more secret exposure risk than standard developer tools?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
