Citizen-Built AI Agents vs IT-Built Agents: When an Agent Must Move to IT Ownership

Business users can now build an AI agent in an afternoon, connect it to mail, files and line-of-business systems, and share it with thousands of colleagues, yet most organisations have no rule for when that agent stops being a personal tool and becomes a system IT must own. The result is agents that run on one employee's credentials, sit outside change control and break or keep running unattended when that person leaves. This guide compares the citizen-built and IT-built paths on identity, connector permissions, inventory, data policy and lifecycle, then sets out a tiered control model with explicit graduation triggers and a handover procedure. It is for platform owners, IAM teams and AI governance leads. The platform-wide governance model is in the Citizen Developer and Internal AI App Governance Guide and agent configuration in the Low-Code Agent Platforms Guide; this page does not repeat them. Where platform settings are named, Microsoft Copilot Studio and Salesforce Agentforce are used as documented examples; platforms are listed alphabetically, and the order is not a ranking. Sources checked 13 November 2026.

Key takeaways

• The real difference is whose identity the agent runs as. Citizen-built agents typically act with the maker's connection or each user's delegated access; IT-built agents should run under a dedicated, least-privilege identity with a named owner that outlives any one employee.
• Tier by reach and action, not by who built it. A personal agent that summarises the maker's own mail can stay citizen-built indefinitely; an agent shared broadly that writes to a business system cannot, however well it was built.
• Write graduation triggers down. Sharing beyond a team, a new write action, a regulated data source, an external channel or an autonomous trigger should each force a review and, past a threshold, transfer to IT.
• Handover is an identity migration. Moving an agent to IT means replacing maker connections with managed identities or user authentication, moving it into a governed environment, and putting it under source control and change management.
• Offboarding is where both paths fail. Citizen agents orphan when makers leave; IT agents orphan when projects end. Ownership attestation and leaver hooks are needed on both paths.

The short answer

Let business users build agents that act only for themselves or a small team, read data they can already see, and take no irreversible actions, inside a governed maker environment with a restrictive data policy. Move an agent to IT ownership when it serves people who did not build it at scale, holds credentials or permissions beyond the user's own, writes to systems of record, handles regulated data, is exposed outside the organisation, or runs without a human starting it. Between those poles, keep the agent citizen-owned but require a registered business owner, a review and a co-owner from IT.

Citizen-built agents: threat model and failure modes

Threat model

The OWASP Low-Code/No-Code Top 10 describes most of what goes wrong. The first risk, LCNC-SEC-01 Account Impersonation, is the defining one for citizen agents: when an agent uses the maker's embedded connection, every user of the agent acts with the maker's access, and the logs show the maker. LCNC-SEC-02 Authorization Misuse follows when that connection is reused beyond its intended audience, LCNC-SEC-03 Data Leakage when the agent can move data to an external connector, and LCNC-SEC-09 Asset Management Failures when nobody knows the agent exists. Generative agents add prompt injection from the content they read, which matters most once an agent can take actions.

Architecture in words

A maker opens the platform, usually in a default or routed personal environment, picks knowledge sources and tools, and chooses how each tool authenticates. In Copilot Studio a tool can use User authentication, where each user signs in and the agent acts with that user's permissions, or Agent author authentication, where a set of credentials provided for the agent is used for everyone; Microsoft positions the author option for implicit or low-risk access such as looking up a public phone number. Microsoft's security and governance page states that makers can configure tools to use the user's credentials by default. The agent itself can be set to No authentication, Authenticate with Microsoft or Authenticate manually. In Salesforce, an employee agent runs in the context of the currently logged-in user, so it inherits that user's permissions, which keeps citizen use inside existing access.

Failure modes

• Privilege by proxy: an agent built by a finance or HR administrator with author credentials, then shared widely, gives every user the administrator's view of the data.
• Quiet scope creep: a personal agent gains a write tool and a broader share list over several weeks, crossing every threshold without a review event.
• Anonymous publication: an agent published to a website or external channel without user authentication becomes a public interface to internal knowledge.
• Orphaning: the maker changes role or leaves; the agent either breaks mid-process or keeps running on a connection nobody owns. See Ownership for Orphaned and Abandoned AI Agents.

IT-built agents: threat model and failure modes

Threat model

IT-built agents usually have broader reach by design: service-level access to systems of record, autonomous triggers and external channels. The attacker's interest shifts to the agent identity itself (its tokens, certificates or client secrets), to the deployment pipeline that can change its instructions and tools, and to injected content that turns a highly privileged agent against the data it can reach. A compromise of an IT-built agent is closer to a compromised integration account than to a compromised user.

Architecture in words

The agent is built in a development environment, stored in source control, promoted through test to production, and runs under its own identity. In Copilot Studio, Microsoft documents deploy-from-Git with audit trails under application lifecycle management, and agents can be represented as Microsoft Entra identities through Agent 365 and governed with Conditional Access and access governance workflows; see the Microsoft Entra Agent ID Guide. In Salesforce, a service agent operates as an agent user with the Einstein Agent User profile, which Salesforce says "is created with minimal access so that your agent is secure by default"; administrators add permission sets and choose a role following least privilege. The implementation guide validates changes in a sandbox, deploys the agent metadata and the agent user's permission sets with the Salesforce CLI, and recommends turning on Audit and Feedback to store details of interactions with the LLM for analysis and reporting.

Failure modes

• Over-provisioned agent identity: permissions granted broadly to make the first release work and never reduced.
• Secrets on the agent: client secrets or API keys stored in configuration rather than a managed identity or vault; see the Service Account Security Guide.
• Shared identity across agents: one integration identity reused by several agents removes attribution and blast-radius limits; see Per-Agent Identity vs Shared Agent Identity.
• Slow delivery drives shadow builds: if IT intake takes months, business units rebuild the agent on the citizen path, which recreates the risk the process was meant to remove.

The tiered control model

The live governance guide sets three platform tiers for all citizen development. For agents, the useful question is narrower: who must own it. The model below adds an ownership decision to each tier.

Graduation triggers

Each trigger should be detectable by the platform or the intake form, not left to the maker's judgement.

Identity and connector permissions per path

• Maker credentials: acceptable only where the data is public or reference data and no write actions exist. They break attribution because the platform records the maker for every user's actions.
• User delegated access: the default for citizen agents on both documented platforms, and often the right choice for IT agents too, because it keeps existing access controls and audit attribution. It does not suit autonomous triggers, where no user is present.
• Dedicated agent identity: required where the agent acts without a user or needs access users do not have. One identity per agent, scoped to the documented purpose, owned by a person and reviewed. See the Agentic AI Identity Guide.
• Agent-level authentication: in Copilot Studio, data policies can require authentication, which removes the No authentication option; Require users to sign in is available only with Authenticate manually. Equivalent publication rules should be set on any platform that allows anonymous channels.

Data policies as the boundary between paths

Data policies are what let citizen agents exist safely, so set them per environment rather than per agent. In the Power Platform, connectors are classed as Business, Non-business or Blocked; Business and Non-business connectors cannot share data with each other in one app or agent, and new connectors land in the group chosen with Set default group, which Microsoft recommends leaving as Non-business so administrators review them first. Tenant policies cannot be overridden by environment policies. Microsoft also lists data policy controls specific to agents, covering maker and user authentication, knowledge sources, actions, HTTP requests, publication channels and triggers, and notes that blocking a connector at runtime suspends apps, flows and agents that use it; check Microsoft's documentation for how quickly this takes effect. For Salesforce, the agent's reach is set by the permission sets on the agent user or the logged-in user, so the equivalent boundary is permission set design and sandbox-first build. In both cases, the maker environment should carry the most restrictive policy and the managed production environment the policy written for the specific agent.

Handover procedure: moving an agent to IT

1. Freeze and record: export the agent definition, list every knowledge source, tool, connection, trigger, share and channel, and note which credentials each tool uses.
2. Assign owners: a business owner accountable for purpose and a technical owner accountable for operation, both recorded in the agent inventory.
3. Re-platform the identity: replace maker connections with user authentication or a new dedicated agent identity; never transfer the maker's own connection to IT staff.
4. Move environments: import into a managed development environment under source control, then promote through test to production.
5. Test: run functional and adversarial tests, including prompt injection through each knowledge source; Salesforce documents a Testing Center that can generate up to 100 test scenarios and track results over time.
6. Cut over: publish the IT version, redirect users, and keep the citizen version read-only for a short rollback window.
7. Decommission: delete the citizen version, revoke its connections and remove the maker's shares.

Rollback means re-enabling the read-only citizen version with its original user-authenticated connections, never re-activating author credentials that the review rejected.

Lifecycle and offboarding

• Leaver hook: connect HR leaver and mover events to agent ownership so every agent owned by the person is reassigned or disabled. See the Joiner-Mover-Leaver Guide.
• Attestation: owners confirm purpose, sharing and connections every six or twelve months by tier; unconfirmed agents are disabled, then deleted.
• Inactivity: tier A agents unused for a set period are disabled automatically.
• Project end: IT agents need a retirement date or review date at creation, because project teams disband. See the AI Agent Lifecycle Management Guide.

Worked scenario

A procurement analyst builds an agent that answers questions about the supplier policy from a document library. It uses user authentication and is shared with the procurement team: tier B, citizen-owned with a business owner. Three months later the analyst adds a tool that creates purchase requisitions in the ERP using an integration account she was given for testing, and the head of procurement asks to share the agent with all 3,000 budget holders. Two triggers fire: author credentials on a system of record, and organisation-wide sharing. The platform team blocks the share pending review and opens a handover. IT replaces the integration account with a dedicated agent identity that can create, but not approve, requisitions, adds a confirmation step, moves the agent to the managed production environment with source control, and runs injection tests against the policy library. The analyst stays as business owner and continues to edit the knowledge content through a reviewed change. The requisition tool goes live four weeks later; the answering function stayed available throughout.

Decision criteria

• Small organisations: a two-tier version (personal and IT-owned) with a single sharing threshold is enough; the key control is banning author credentials on non-public data.
• Large organisations: use all four tiers, automate trigger detection from platform audit logs, and staff a fast-track review so the IT path is not slower than rebuilding.
• Regulated sectors: treat any agent that touches regulated data or produces records used for reporting as tier C at least, and tier D if it acts autonomously.

Detection and measurement

• Audit sources: maker audit logs (Copilot Studio records these in Microsoft Purview) and Salesforce Audit and Feedback data, plus sharing, connector and channel changes.
• Alerts: author credentials added to a tool using a Business connector, authentication set to none, new autonomous trigger, share list above threshold, owner account disabled.

Metrics:

1. Percentage of agents with a registered, active owner, by tier.
2. Number of tier B or higher agents using maker or author credentials on non-public data (target zero).
3. Median days from graduation trigger to completed review.
4. Median days from maker leaver event to agent reassignment or disablement.
5. Number of agents rebuilt on the citizen path after an IT request was declined or delayed.

Framework mapping

Common failure patterns

• Tiering by builder rather than by reach: IT-built agents skip review because IT built them, while harmless personal agents are blocked.
• No trigger for gradual change: reviews happen only at first publication, so incremental sharing and new tools never prompt a re-tier.
• Handover keeps the maker's connection: the agent moves environment but still acts as the original maker.
• Default environment left open: makers build agents with Business connectors where no restrictive policy applies.
• Owner field set to a departed employee: inventory looks complete while the owner account is disabled; see Orphaned and Dormant Accounts.

Practitioner checklist

• Publish the four-tier agent ownership model and the graduation triggers.
• Route makers to governed environments with a restrictive data policy and new connectors defaulting to Non-business or the platform equivalent.
• Prohibit author or maker credentials on tools that reach non-public data.
• Require authentication for every published agent; review any anonymous channel as tier D.
• Detect sharing, tool, trigger and channel changes from platform audit logs and raise a review.
• Run handovers as identity migrations: new identity, managed environment, source control, tests.
• Give every tier B to D agent a business owner and a technical owner in the inventory.
• Connect HR leaver and mover events to agent ownership.
• Set a fast-track IT path so declined or slow requests do not become shadow rebuilds.

Standards and references

• OWASP: Top 10 Low-Code/No-Code Security Risks
• Microsoft Learn: Security and governance in Copilot Studio
• Microsoft Learn: Configure end-user authentication for tools in Copilot Studio
• Microsoft Learn: Configure user authentication in Copilot Studio
• Microsoft Learn: Manage data policies in Power Platform
• Salesforce: Agentforce implementation guide

Related NHI Mgmt Group resources: Securing Microsoft Copilot Studio Agents Guide · Securing Salesforce Agentforce Guide · Unsanctioned AI Agents and MCP Servers Guide · AI App Builder Security Guide