What is the difference between securing IT-built applications and securing citizen-developed AI applications?

IT-built applications are usually governed through formal development, review, and deployment processes. Citizen-developed AI applications need controls that are easier to consume, because business users are the builders and may not understand security mechanics. The difference is not the security objective, which is the same, but the delivery model. Controls must be automated, embedded, and usable by non-specialists.

Why the control model changes when business users build the app

Securing IT-built applications starts with a well-defined engineering path, so security can be built into source control, CI/CD, testing, release gates, and operational handoff. Citizen-developed AI applications are different because the builder is often a business user, not an application engineer, so the control set has to be simpler, more embedded, and harder to bypass. The core security objective stays the same, but the delivery model changes the practical control surface.

That difference matters because low-friction tooling can expand usage faster than governance can keep up. In practice, the challenge is not to invent a separate security goal for citizen development, but to make the same security outcomes achievable through templates, defaults, policy guardrails, and platform-enforced controls that do not require specialist judgment at every step.

IT teams usually have more leverage over code review, build pipelines, and deployment approvals, which makes formal control points realistic. Citizen-developed AI applications often need controls that operate earlier and more invisibly, such as approved connectors, preconfigured access patterns, safe prompt and data handling defaults, and constrained publishing paths. Where the builder cannot reliably interpret security nuance, the platform has to carry more of the burden.

What still has to be secured in both models

The security objective is the same across both approaches: protect data, limit unauthorized action, preserve integrity, and keep production behavior observable and accountable. The difference is that IT-built applications usually express those goals through process-heavy controls, while citizen-developed AI applications need controls that feel native to the tool itself and do not depend on the user remembering a separate security workflow.

For citizen-developed AI applications, that usually means stronger opinionated defaults, less freedom to expose sensitive systems, and more centralized oversight of shared building blocks. The practical question is whether the platform can reduce unsafe choices without blocking ordinary business work. If security only exists as policy text or a separate approval step, adoption will often drift around it.

In both models, secrets handling remains a hard boundary. NHIMG research notes that 96% of organisations store secrets outside secrets managers in vulnerable locations, which is a reminder that any AI application development model that makes credential handling easier, or less visible, needs compensating guardrails around storage, rotation, and access pathways. NHIMG’s Ultimate Guide to NHIs is a useful reference when the application depends on API keys, tokens, or other identity material that can be reused outside the intended workflow.

Risk and Threat Considerations

Citizen-developed AI applications can create more accidental exposure than traditional IT-built applications because they are often assembled quickly, with shared components, broad connector access, and weaker review discipline. The risk is not that the business user is malicious, it is that convenience features can turn sensitive data access, external integration, or automated actions into an uncontrolled production path.

Failure mechanism: Users may connect AI tools to data sources or services that they do not fully understand, then publish workflows that inherit excessive access, weak data boundaries, or reusable credentials. That can lead to prompt-driven disclosure, overbroad automation, and hard-to-see privilege spread across the environment.

Impact: The result can be unauthorized data exposure, unsafe automated actions, or a governance gap where the organization can no longer clearly explain who built the workflow, what it can reach, or how quickly it can be contained if something goes wrong.

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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Management	Citizen-built AI apps often depend on API keys and tokens.
	NHI-03 — Privilege and Access Management	Low-code AI workflows can inherit excessive access and broad connector permissions.
Recommendation — Centralize and restrict secret storage, rotation, and access for citizen-built apps. Apply least privilege to connectors, service access, and app publishing rights.
OWASP Agentic AI Top 10	A1 — Agent Identity and Access	AI applications need bounded authority when they can trigger tools or actions.
Recommendation — Constrain tool access and action scope before allowing autonomous or semi-autonomous execution.
NIST CSF 2.0	PR.AC-1 — Identity Management, Authentication, and Access Control	Both application models depend on controlled access to data and services.
	PR.DS-1 — Data-at-Rest Protection	Citizen-built AI apps can expose data through misconfigured integrations or storage.
Recommendation — Enforce access control for users, connectors, and application actions. Protect sensitive data with approved storage, encryption, and handling rules.
CIS Controls v8	6.3 — Account Management	Business-built apps often expand access paths without equivalent lifecycle governance.
	3.4 — Automated Asset Inventory	Organizations need visibility into citizen-developed apps and their dependencies.
Recommendation — Review and remove unnecessary accounts, permissions, and access paths regularly. Maintain an inventory of citizen-built apps, connectors, and data sources.

Practitioner Guidance

What to prioritise: Treat the citizen-development platform, not the individual app, as the primary control point. The most effective controls are the ones that ship with the builder, for example approved connectors, restricted data sources, bounded publishing options, and default-safe sharing settings.

What to verify: Before trusting a citizen-developed AI application in production, verify who can change its data access, whether secrets are stored centrally, and whether the workflow can be independently disabled without relying on the original builder. If you cannot answer those questions quickly, the app is not yet operating under an acceptable control model.

Common mistake: Applying IT delivery governance verbatim to citizen development and assuming training alone will close the gap. That usually fails because the weakest point is not knowledge, it is usability. The control must be easy enough that the safe path is also the fastest path.

Practitioner takeaway: The strongest programs do not separate “IT security” from “citizen AI security” by objective, they separate them by how control is delivered. When non-specialists are the builders, the platform must enforce the security outcome by default.