Most organisations govern user built AI assistants as a sharing problem and enterprise agents as an application problem, but nobody has written down the point at which one becomes the other. A policy Q&A assistant and an agent that wakes on an event and writes to a business system can be built by the same person in the same afternoon, yet need very different controls. This guide sets out criteria for drawing the boundary: what data the assistant can reach, what it can do, whose identity it acts with, who can use it, and what events force a review. It is for AI governance, identity and platform owners. Sharing settings and knowledge file controls for the assistant builders themselves are covered in the Custom GPTs and Gems Governance guide, and the low-code operating model in the Citizen Developer and Internal AI App Governance Guide; this page does not repeat them. Where platforms are named they are listed alphabetically; order is never a ranking.
Key takeaways
- The boundary is about capability, not the tool used to build it. The same builder can produce a read-only assistant or an autonomous agent; classify by data reach, actions, identity, audience and autonomy, not by product name or who clicked "create".
- Identity is the sharpest dividing line. An assistant that only ever acts with the signed-in user's own permissions inherits that user's controls; one that acts with its author's connection, a shared API key or its own identity is a non-human identity and needs an owner, least privilege and review.
- Autonomy moves an assistant across the line on its own. Anything that runs without a user prompt (event triggers, schedules, proactive messages) must be governed as an enterprise agent, whatever else it does.
- Write actions outweigh read access. An assistant that reads broadly but cannot change anything is a disclosure risk; one that can send, write, approve or pay is an operational risk and needs human approval points and complete mediation in the downstream system.
- Review triggers keep the boundary honest. Assistants drift: a new action, a wider share or a connection swap can promote an assistant into an agent overnight, so define the change events that force reclassification and detect them from platform inventories.
Two categories, defined by what they do
The vendors draw part of this line themselves. Microsoft's comparison of declarative and custom engine agents states that declarative agents use Copilot's own orchestrator and foundation model, need no additional hosting, are "designed to be used by individuals", do not support proactive behaviour and inherit Microsoft 365 compliance and security standards. Custom engine agents use custom orchestration and models, are hosted outside Microsoft 365, support group use and proactive actions, and the organisation "must ensure your own compliance, RAI practices, and security measures". Google's Gemini Enterprise documentation separates employee-made Workflow Builder agents from custom agents an organisation registers, such as ADK, A2A and Dialogflow agents. For identity, Google states that ADK agents receive the user's email address from Gemini Enterprise, that an agent which must reach Google Cloud resources on behalf of a user needs an OAuth authorization resource listing the scopes it requests, and that admins can view an agent's identity, typically its SPIFFE ID where the publisher makes it available; a Private agent can be used only by its creator. OpenAI's GPT Actions documentation distinguishes no authentication, a builder API key, and per-user OAuth.
Product categories are a starting point, not a governance boundary: a declarative agent writing to a business API is riskier than a custom engine agent answering from public content. Use two working definitions:
- Custom AI assistant: a configured instance of a vendor model that answers a user's prompt, in that user's session, using knowledge the user is entitled to and at most read-only or user-confirmed actions performed with the user's own credentials. It has no standing access of its own and does nothing when nobody is talking to it.
- Enterprise agent: any AI system that holds access that is not the current user's (author connection, shared key, service principal, agent identity), takes actions with side effects, runs on triggers or schedules, serves an audience wider than its builder's team, or touches regulated or confidential data in bulk. It is governed as an application with a non-human identity, whoever built it.
Any one criterion is enough, which makes the boundary enforceable from configuration rather than judged from intent. The distinction between agent identity and other machine identity is covered in the NHI vs AI Agent Identity guide.
The boundary at a glance
Score each assistant on five dimensions; any right-hand cell makes it an enterprise agent.
| Dimension | Stays a custom AI assistant | Becomes an enterprise agent | How to detect it |
|---|---|---|---|
| Data access | Uploaded or linked knowledge at or below the audience's classification; permission-aware retrieval in the user's context | Confidential or regulated sources read in bulk, cross-tenant or external data, knowledge read with someone else's access | Knowledge source list in the platform inventory; sensitivity labels on linked sites and folders |
| Action capability | None, or read-only lookups; any write is confirmed by the user each time | Writes, sends, deletes, approves, purchases or calls arbitrary HTTP endpoints | Actions, tools, connectors and custom connector definitions in the assistant configuration |
| Identity used | The signed-in user's own delegated token (per-user OAuth, user authentication) | Author or maker connection, builder-supplied API key, service principal, agent identity or agent user | Authentication setting per action or tool; connection owner; Entra or IdP sign-in logs for agent identities |
| Sharing scope | Builder only, or named people or a team inside the organisation | Organisation-wide, listed in a store or catalogue, external guests, public link, or unauthenticated channel | Sharing level in admin consoles; publisher type in agent registries |
| Autonomy | Responds only to a prompt typed by a user in session | Event triggers, schedules, proactive messaging, agent-to-agent delegation | Trigger configuration; activity and run history; credit or quota consumption with no user session |
Data access: whose permissions apply when it answers
The data question is not "what is attached" but "whose access is used to retrieve it, and who sees the answer". Three patterns exist:
- Copied knowledge: files uploaded into the assistant. Their source permissions no longer apply; the assistant's audience becomes the file's audience. Classify the assistant to its most sensitive file.
- Permission-aware retrieval in the user's context: the assistant queries a source with the current user's token, so each user only gets what they could already open. This stays inside the assistant category provided oversharing in the source is under control.
- Retrieval with another identity: the assistant reads with its author's connection or a shared credential. Every user now reaches data with the author's rights. This is the most common silent promotion into the agent category.
Treat the third pattern as an enterprise agent even when the assistant is read-only. For data controls on prompts and outputs, see the Generative AI Data Loss Prevention Guide.
Action capability: from answering to doing
The OWASP Top 10 for LLM Applications 2025 entry LLM06:2025 Excessive Agency names three root causes: excessive functionality, excessive permissions and excessive autonomy. Its prevention list maps directly to the boundary: limit extensions and their functions, avoid open-ended extensions such as URL fetching or shell access, run actions in the user's context, require user approval for high-impact actions, and enforce complete mediation in the downstream system rather than trusting the model. See the OWASP LLM Top 10 LLM06 Excessive Agency Guide.
| Action class | Example | Category | Minimum control |
|---|---|---|---|
| No actions | Policy Q&A from approved documents | Assistant | Knowledge classification, sharing scope |
| Read-only lookup, user context | Check my leave balance via per-user OAuth | Assistant | Approved domains, per-user authentication |
| Read-only lookup, shared credential | Weather or office locations via an API key | Assistant if the data is public; agent otherwise | Key in a vault or platform store, scoped to public data only |
| Write with per-action user confirmation | Draft an email the user reviews and sends | Assistant at team scope; agent at organisation scope | Confirmation step that cannot be skipped by instructions |
| Write without confirmation | Create tickets, update records, post to channels | Agent | Owner, least-privilege identity, logging, rate limits |
| High-impact or irreversible | Payments, access grants, deletions, external sends | Agent, high tier | Human approval, downstream authorisation checks, kill switch |
Two details catch reviewers out. First, a generic HTTP action or connector is open-ended: it is an agent capability even if the builder only intends one endpoint, unless the platform restricts it to approved domains. Second, "the assistant asks before acting" is only a control if the confirmation is enforced by the platform or the downstream system. A system prompt instruction can be overridden by prompt injection. Approval design is covered in the Human-in-the-Loop for AI Agents Guide.
Identity used: the sharpest line
Whose identity an assistant uses decides who is accountable for what it does and which controls apply. Each platform documents its options in its own terms. Platforms are listed alphabetically.
- Google Gemini Enterprise: agents are listed on the Agents page with states Private, Suspended, Enabled and Disabled. For custom agents registered by the organisation, admins can view an agent's SPIFFE ID where the publisher makes it available, or its Agent Registry resource ID. Record how each agent authenticates to its data sources in the inventory. See the Gemini for Google Workspace Security Guide.
- Microsoft Copilot Studio and Entra Agent ID: tools can use Agent author authentication, where the agent uses credentials provided by the author on behalf of users, or User authentication, where each user needs their own valid connection. Microsoft recommends author authentication only where access is implicit or low risk. Microsoft Entra Agent ID adds agent identities that act with autonomous access (rights granted to the agent identity) or delegated access (rights delegated by a user), and records the Copilot Studio creator as the agent's sponsor. See the Microsoft 365 Copilot Agents Security Guide and the Securing Microsoft Copilot Studio Agents Guide.
- OpenAI ChatGPT custom GPTs: GPT Actions support None (the default), API Key, entered once in the GPT editor and stored encrypted by OpenAI, and OAuth, where each user signs in and the user's token is passed on every request. Only OAuth ties a call to the individual user. See the ChatGPT Enterprise Security Guide.
The boundary rule that follows is platform-neutral: per-user delegated authentication keeps an assistant in the assistant category; any shared credential (author connection, builder API key) or any identity of the agent's own puts it in the agent category. Once there, apply a service account lifecycle: owner and sponsor, least privilege, rotation, review at owner change, and retirement that removes credentials and grants. See the Agent Identity and Access Guide and the AI Agent Identity vs Service Account comparison.
Consent grants are part of identity. The Vercel Context.ai OAuth breach began when an employee granted an AI office tool full access with a corporate Google account; when the tool's provider was breached, the stored token gave the attacker that account without a password or MFA. A user-installed AI tool holding a durable, broad OAuth grant is an agent acting with a human's identity, and it belongs on the agent side of the line.
Sharing scope and channel
Audience multiplies every other risk. An author-credentialed assistant shared with three colleagues is a small exposure; in an organisation-wide catalogue it is a privilege escalation path. Channel matters as much as audience: Microsoft documents that a Copilot Studio agent set to No authentication can be chatted with by anyone with the link and can access only public information, and that this option is unavailable where a Power Platform data policy requires authentication.
- Team scope, user identity: stays an assistant; govern through the builder platform's sharing controls.
- Organisation or catalogue scope: treat as an enterprise agent even if read-only, because the knowledge and instructions are exposed to everyone and the assistant becomes a dependency that needs an owner and support.
- External, public or unauthenticated channels: always an enterprise agent, with security review before publication.
The CoPhish technique documented by Datadog Security Labs showed that an agent hosted on a genuine vendor domain can present a sign-in button that leads to an attacker's OAuth consent prompt. The customer-side lessons are restricting user consent, limiting who can create and share agents on public demo pages, and reviewing consent grants.
Autonomy and triggers
Autonomy is a single-criterion promotion. Microsoft's documentation states that Copilot Studio event triggers need no user input and that an autonomous agent uses the maker's credentials for every trigger and action that requires authentication. Microsoft warns that users of a published agent with authenticated triggers might access information or prompt actions with the author's credentials, and shows a warning before publishing. Admins can block event triggers through data policies, and Microsoft recommends narrowing trigger scope with trigger parameters. Custom engine agents in Microsoft 365 can message proactively "without the need for user interaction".
Any assistant that runs on a trigger, schedule or another agent's request is an enterprise agent, needing an owner, a documented blast radius and a way to stop it. See the AI Agent Kill Switch and Containment Guide.
Threat model per side of the boundary
| Threat | Custom AI assistant | Enterprise agent |
|---|---|---|
| Prompt injection | Leaks instructions or knowledge to the person chatting; impact bounded by the user's own access | Indirect injection through documents, emails or trigger payloads drives actions with the agent's identity |
| Over-privilege | Knowledge files above the audience's classification | Author connection or agent identity with broad scopes reachable by every user (OWASP LLM06) |
| Exfiltration | Outbound action to an unapproved domain sends conversation content out | Automated, repeated transfer to a web service; maps to ATT&CK T1567 Exfiltration Over Web Service |
| Credential abuse | Builder API key pasted into instructions | Stolen agent or OAuth tokens used as valid cloud accounts (ATT&CK T1078.004 Cloud Accounts) |
| Orphaning | Assistant keeps sharing files after the builder leaves | Agent keeps running on a departed maker's connection; Microsoft's registry shows shared agents become ownerless when the creating user is deleted |
Inventory and review triggers
The boundary only works if both categories are in one inventory with the five dimensions recorded as attributes. Vendor registries provide the raw data: the Microsoft 365 agent Registry lists agents by publisher type (Microsoft, external partner-built, published by your org, shared by creator), shows an Agents without owners count and exports owner, channel, publisher and instructions; Gemini Enterprise lists agents and their states on the Agents page; ChatGPT Enterprise admins control GPT sharing and which third-party GPTs users can use. Pull these into one register, see the AI agent registry, and add shadow sources from the Shadow AI Discovery Guide.
Events that force reclassification, each detectable from configuration or audit logs:
- New or changed action, tool or connector, especially HTTP or custom connectors.
- Authentication mode change on any action, from per-user to author, API key or agent identity.
- Sharing widened to organisation, catalogue, external or unauthenticated channels.
- Trigger, schedule or proactive messaging added.
- New knowledge source carrying a higher sensitivity label than the current tier.
- Owner or sponsor leaves or changes role, or the agent becomes ownerless.
Decision guidance and worked scenario
Small organisation: keep the rule simple. Allow private and team assistants that use per-user authentication; anything with an author connection, a trigger or organisation-wide sharing goes through a one-page review by IT.
Large or regulated organisation: enforce the boundary with platform settings, not policy text: block author authentication and event triggers in default environments, require admin approval for catalogue publication, and route agent-category builds to managed environments with an identity team sign-off.
Worked scenario. A finance analyst builds an "Invoice helper" that answers questions about the accounts payable process from two policy documents and shares it with her team of eight. It is a custom AI assistant. Three months later she adds a tool that queries the ERP for invoice status using her own connection, configured as author authentication, and shares the helper with the 300-person finance function. Two criteria now fire: identity used (author connection) and sharing scope (organisation-wide in effect). The review trigger on authentication mode flags it; the platform owner reclassifies it as an enterprise agent, moves it to a managed environment, switches the tool to user authentication so each user sees only what the ERP grants them, records the analyst as owner and her manager as sponsor, and logs tool calls to the SIEM. A later "approve invoice" action falls in the high-impact tier and gets an approval step enforced in the ERP workflow.
Detection and measurement
- Log sources: agent registry exports, builder audit logs (sharing, publishing, action changes), connection inventories, IdP sign-in and OAuth consent logs, and downstream logs of actions by agent identities.
- Alerts: authentication mode changed to author or API key; trigger added; assistant shared to organisation, catalogue or external; agent with no owner still active; agent identity signing in from an unexpected location or calling unexpected resources.
| Metric | What it shows | Target direction |
|---|---|---|
| Assistants in inventory with all five dimensions recorded | Whether the boundary can be applied at all | Towards 100% |
| Agent-category items not yet reviewed, and their median age | Backlog of silent promotions | Down |
| Shared assistants using author or shared credentials | Privilege exposure through sharing | Down |
| Ownerless agents active in the last 30 days | Lifecycle failure | Zero |
| Reclassification events detected versus found later in audit | Whether review triggers work | Detected share up |
Framework mapping
| Framework | Reference | How it applies |
|---|---|---|
| NIST CSF 2.0 | ID.AM-02, GV.RR, PR.AA-05, DE.CM-03 | Inventory of assistants and agents as software and services; named roles and ownership; access permissions defined and reviewed; monitoring of technology usage |
| NIST SP 800-53 Rev 5 | CM-8, AC-2, AC-6, AC-21, AU-6 | Component inventory; account management for agent identities; least privilege for connections; information sharing decisions; audit review of agent actions |
| NIST AI RMF 1.0 and AI 600-1 | Govern, Map, Measure, Manage | Map the context and capability of each system before deciding its tier; govern ownership and accountability |
| OWASP Top 10 for LLM Applications 2025 | LLM06:2025 Excessive Agency | Functionality, permissions and autonomy criteria used for the boundary |
| MITRE ATT&CK v20 | T1567, T1078.004 | Exfiltration through actions; abuse of agent and OAuth tokens as cloud accounts |
Common failure patterns
- Classifying by builder tool: treating everything made in a "simple" builder as low risk, while author-authenticated tools and triggers turn some of them into autonomous agents.
- Read-only means safe: approving read-only assistants that retrieve with the author's access, which discloses the author's view to every user.
- Prompt-level approvals: relying on "always ask before acting" in instructions instead of a confirmation enforced by the platform or the downstream system.
- One-time review: reviewing an assistant at creation and never again, so later actions, connections or wider sharing go unnoticed.
- Departed makers' connections: triggers and tools keep running on a leaver's connection, or the agent becomes ownerless and keeps serving users.
- Ignoring user consent grants: AI tools installed by staff with broad OAuth scopes are not counted as agents at all, as the Vercel Context.ai case showed.
Practitioner checklist
- Publish the five-dimension boundary (data access, actions, identity, sharing, autonomy) with the rule that any one agent-side criterion promotes an assistant.
- Export every platform's assistant and agent inventory into one register with the five dimensions as fields.
- Default actions and tools to per-user authentication; require review for author authentication, builder API keys or agent identities.
- Block or gate event triggers and generic HTTP actions in default environments and workspaces.
- Require an owner and a sponsor for every agent-category item, and act on ownerless agents within a set period.
- Enforce approvals for high-impact actions in the platform or downstream system, not in prompts.
- Restrict user OAuth consent for AI tools and review existing grants.
- Implement the six review triggers as alerts and track the five metrics monthly.
Standards and references
- OWASP: LLM06:2025 Excessive Agency
- NIST: AI Risk Management Framework
- Microsoft Learn: Compare declarative and custom engine agents
- Microsoft Learn: Event triggers in Copilot Studio
- Microsoft Learn: Configure user authentication for actions
- Microsoft Learn: What is Microsoft Entra Agent ID
- Google Cloud: Gemini Enterprise agents overview
- Google Cloud: Register and manage an ADK agent
- OpenAI: GPT Actions authentication
Related NHI Mgmt Group resources: Custom GPTs and Gems Governance, Citizen Developer and Internal AI App Governance Guide, Citizen-Built AI Agents vs IT-Built Agents, Excessive Agency vs Excessive Permissions and AI Agent Registry vs CMDB vs IGA.