Citizen Developer and Internal AI App Governance Guide: Low-Code, No-Code and AI Builders

Citizen developers now build business applications, automations and AI agents that touch production data, yet most of these apps never pass through the controls applied to professional software. Low-code and no-code platforms such as Microsoft Power Platform, and AI builders such as Copilot Studio, let any licensed employee connect SharePoint, Outlook, Salesforce or an HTTP endpoint in minutes and share the result with thousands of colleagues. The result is an estate of apps, flows and agents with unclear owners, embedded connections that act with someone's credentials, and data paths nobody designed. This guide sets out a governance model for citizen development and internal AI apps: risk tiers, environment strategy, data policies, identity and connection controls, a lifecycle, detection and metrics. It is written for platform owners, security architects, IT governance and AI governance leads. Security of individual AI app builder products is covered in the AI App Builder Security Guide, and agent-specific controls in the Low-Code Agent Platforms Guide.

Key takeaways

• Govern the platform, not each app. You cannot review thousands of citizen-built apps one by one; you can control environments, connectors, sharing and publishing centrally.
• Connections are identities. Every app, flow or agent runs with an embedded connection: a user's delegated access, a shared account or a service principal. That is where most of the risk sits.
• Tier by data and reach. A personal productivity flow and an agent published to customers need different controls; a three-tier model keeps governance proportionate.
• The default environment is the shadow IT zone. Route makers into governed environments and lock down data policies in the default one first.
• Ownership decays fast. Makers change roles and leave; orphaned apps keep running with their connections. Lifecycle and attestation are not optional.

What citizen development changes

A citizen developer is a business user who builds applications or automations on a platform sanctioned by IT, without being a professional developer. With generative AI, the same users now build agents that read company knowledge, call tools and take actions. The OWASP Low-Code/No-Code Top 10 lists the risks that recur on these platforms:

Two features of these platforms drive most incidents. First, makers configure security settings that professional developers would treat as code: sharing scope, authentication mode and table permissions. Second, defaults matter enormously. In 2021 UpGuard found Power Apps portals whose OData list feeds were publicly readable because table permissions were not enabled by default for lists, exposing 38 million records across 47 organisations; Microsoft changed the default for new portals and released a Portal Checker tool. No attacker skill was needed, only a default nobody reviewed.

A risk-tiered governance model

Classify each app, flow or agent by the data it touches and who can use it. Apply the tier at creation (through environment routing and a short intake form) and re-evaluate when sharing or connectors change.

Tier 3 apps that support financial reporting fall under IT general controls in the same way as any other application. See the SOX IT General Controls (ITGC) Guide and the Segregation of Duties Guide.

Environment strategy

• Default environment: every licensed user can build there, so it holds most unmanaged apps. Apply the most restrictive data policy to it, rename it so its status is clear, and use default environment routing (a Power Platform managed environments feature) to send new makers to their own governed development environments instead.
• Managed environments: Microsoft's managed environments add limit sharing, weekly usage insights, data policies, pipelines, maker welcome content, solution checker, IP firewall, IP cookie binding, customer-managed keys and conditional access on individual apps. They are included with standalone Power Apps, Power Automate, Copilot Studio, Power Pages and Dynamics 365 licences, according to Microsoft. Microsoft also states that unmanaged developer environments are deprecated and must have managed environments enabled by 15 December 2026 to be kept.
• Development, test, production: for tier 2 and 3, separate environments with deployment through pipelines, so changes are tested and recorded rather than edited live.
• Maker welcome content: use it to state the rules (data classes allowed, how to request a connector, who to call) at the moment makers start building.

Data policies and connector control

Power Platform data policies (Microsoft's current term; many pages and tools still say data loss prevention or DLP) classify connectors into three groups: Business, Non-Business and Blocked. An app or flow cannot combine connectors from Business and Non-Business groups, and Blocked connectors cannot be used at all. Microsoft's documentation describes several details that shape a good policy:

• Default group: new policies place connectors in Non-Business, and new connectors added to the platform later land in the default group. Microsoft advises keeping Non-Business as the default and moving connectors into Business or Blocked after evaluation.
• Unblockable connectors: core connectors such as SharePoint, OneDrive for Business, Microsoft 365 Outlook, Microsoft Teams, Excel Online (Business), Dataverse, Approvals and Microsoft Copilot Studio cannot be blocked, only classified. Use advanced connector policies to restrict them further.
• HTTP connectors: HTTP, HTTP Webhook and "When an HTTP request is received" can be classified. They reach any endpoint, so classify them as Non-Business or block them in shared environments such as the default environment; note that child flows depend on the HTTP connector.
• Custom connectors: tenant-level policies classify custom connectors by ordered URL patterns, with * as the last entry and the action Blocked, Business, Non-business or Ignore.
• Enforcement: blocking stops makers saving new resources with that connector, and existing apps, flows and agents that violate the policy are suspended or quarantined. Microsoft says enforcement usually completes in about an hour and can take up to 24 hours in large tenants, so communicate changes before applying them.
• AI features: data policies also govern Copilot Studio capabilities: maker and user authentication, knowledge sources, connectors, HTTP requests, publication to channels and triggers for autonomous agents.

Data policies prevent combinations of connectors; they do not classify the data inside a SharePoint list or inspect what an agent says. Pair them with sensitivity labels and the controls in the Data Loss Prevention (DLP) Guide.

Identity, connections and sharing

Every citizen-built asset runs as someone. Getting that identity right is the single most effective control.

• Embedded maker connections: when an app or agent uses the maker's own connection for all users, every user acts with the maker's access (LCNC-SEC-01). For shared assets, require each user to sign in with their own connection, or use a dedicated service principal with least privilege for tier 3.
• Service accounts in disguise: makers often create a shared mailbox or "flow account" with a password and a broad licence to keep automations running. Treat these as non-human identities: register an owner, vault the credential, scope access and review it. See the Service Account Security Guide.
• Secrets in flows: API keys pasted into HTTP actions or app variables are visible to co-owners and exported with the solution. Use environment variables backed by a secrets store, or connectors with managed authentication. See the Secrets Management Guide.
• Agent authentication: an agent published without user authentication cannot enforce per-user access to knowledge or tools. Use data policy controls to require authentication and restrict publication channels; Copilot Studio also lets admins disable publishing of agents that use generative AI features tenant-wide.
• Sharing: limit sharing with large security groups or "everyone" for tier 1 and 2, using the managed environments sharing limits, and require review before an app is shared beyond its department.
• Consent and OAuth: agents and apps can be used to deliver OAuth consent prompts. In the CoPhish 2025 research, Datadog Security Labs showed a Copilot Studio agent's login topic redirecting users to a malicious consent prompt and forwarding the resulting token; no real-world victims were reported. Restrict user consent and monitor agent creation. See the SaaS and OAuth App Governance Guide.

Lifecycle: from idea to retirement

1. Intake: a short form at environment creation or before sharing beyond the team: purpose, data classes, connectors, audience, owner and backup owner. The answers set the tier.
2. Build: in the routed environment, under its data policy, with maker guidance and the solution checker for tier 2 and above.
3. Review: tier 2 needs a peer or platform team review of connections and sharing; tier 3 needs a security review covering authentication, input handling, AI prompt and tool design, and logging. See the AI-Generated Code Review Guide.
4. Deploy: tier 3 through pipelines into production, with the deployer different from the builder.
5. Operate: usage insights, connection health and data policy violations monitored by the platform team.
6. Attest: owners confirm at least annually (quarterly for tier 3) that the asset is needed, its owner is correct and its access is still appropriate.
7. Retire: when the owner leaves or usage stops, reassign or quarantine, then delete after a grace period, and remove connections and service accounts with it.

Microsoft has stopped actively maintaining the CoE Starter Kit, its earlier governance toolkit, and points customers to the inventory, usage, monitor and actions capabilities of the Power Platform admin center and the Power Platform inventory API. Plan governance automation on those supported interfaces.

Rolling out governance without stopping the business

1. Discover: export the inventory of environments, apps, flows, agents, connectors and owners. Identify assets owned by leavers and assets shared widely.
2. Quick wins in audit mode: draft a data policy for the default environment and analyse which existing resources would violate it before enforcing. Notify affected owners.
3. Enforce in the default environment: block high-risk connectors, place HTTP and consumer services in Non-Business, and switch on default environment routing.
4. Stand up tiered environments: managed environments for departments and production, with named admins.
5. Migrate tier 3 assets: move business-critical apps into production environments with pipelines, service principals and owners.
6. Roll back: keep previous data policies documented; if enforcement breaks a critical flow, add a targeted environment-level exception for that environment rather than weakening the tenant policy, and fix the flow.
7. Sustain: maker training, monthly reports on violations and orphaned assets, and an annual policy review.

Decision guidance

• Allow citizen AI agents or reserve them for IT: allow tier 1 and 2 agents grounded on Microsoft 365 data with user authentication; reserve agents that take actions in business systems, or face customers, for tier 3 with a security review.
• User connections or service principals: user connections keep access aligned with each user's rights and suit internal apps; service principals suit scheduled automations and tier 3 apps that must outlive their maker, provided they are scoped and owned.
• Small organisations: one restrictive tenant data policy, a separate environment for anything shared beyond a team, and a quarterly owner review cover most of the risk.
• Large organisations: a platform team (often called a centre of excellence) with environment-per-department, automated intake, managed environments, SIEM integration and attestation campaigns. See the NHI Ownership Attestation Campaigns Guide.
• Multiple platforms: the same model applies to other low-code, automation and AI builder platforms; inventory each, and do not let a stricter policy on one simply push makers to another.

Detection and measurement

• Audit logs: send maker and admin activity to the SIEM. Copilot Studio maker audit logs are available in Microsoft Purview, and Microsoft documents monitoring agent activity in Microsoft Sentinel.
• Watch for: new connectors or custom connectors in production environments, sharing with large groups, agents published to external channels, data policy violations and suspensions, new OAuth consents created from agent flows, and assets owned by disabled accounts.

Metrics that show governance is working:

• Percentage of apps, flows and agents with an active, named owner (target above 95%).
• Number of assets in the default environment, trended down.
• Percentage of environments covered by a data policy (target 100%) and of tier 3 assets in managed environments.
• Count of shared assets using embedded maker connections or shared accounts.
• Median time from intake request to approval for tier 2.
• Orphaned assets older than 30 days after the owner left.

Common failure patterns

• Trusting defaults: the Power Apps portals exposure showed how a platform default (table permissions not enforced for lists) can expose regulated data at scale without any attack.
• Policing the platform team's environments but not the default one: the default environment holds the bulk of shadow assets and is often the least governed.
• One shared "automation account" for everything: a single licensed account with broad access, a never-rotated password and no owner becomes a high-value NHI.
• Treating AI agents as chatbots: agents with tools and connectors take actions; reviewing only their prompts misses the access they hold.
• Blocking without an alternative: a heavy-handed block drives makers to unsanctioned SaaS automation tools. Pair every restriction with a supported route.

Framework mapping

Practitioner checklist

• Export a full inventory of environments, apps, flows, agents, connectors and owners.
• Apply a restrictive data policy to the default environment and turn on default environment routing.
• Classify HTTP and custom connectors deliberately, and block consumer services in business environments.
• Define three tiers by data and reach, and require intake for anything shared beyond a team.
• Replace embedded maker connections and shared accounts in tier 3 assets with scoped service principals or per-user connections.
• Require user authentication and restrict publication channels for AI agents.
• Move tier 3 assets into managed production environments with pipelines and separate deployers.
• Send maker and agent audit logs to the SIEM and alert on wide sharing and policy violations.
• Run owner attestation and reassign or retire orphaned assets within 30 days.

Standards and references

• OWASP: Top 10 Low-Code/No-Code Security Risks
• Microsoft Learn: Power Platform data policies
• Microsoft Learn: Connector classification
• Microsoft Learn: Managed environments overview
• Microsoft Learn: Security and governance in Copilot Studio
• NIST: SP 800-53 Rev. 5
• OWASP: Top 10 for LLM Applications 2025
• UpGuard: By Design: How Default Permissions on Microsoft Power Apps Exposed Millions

Related NHI Mgmt Group resources: AI App Builder Security Guide · Low-Code Agent Platforms Guide · Securing Microsoft Copilot Studio Agents Guide · Shadow AI Discovery Guide · SaaS and OAuth App Governance Guide