Custom GPTs and Gems Governance: Controlling sharing, knowledge files and actions in user built assistants

Every licensed user can now build an assistant, give it company files, connect it to an external API and share it with colleagues or the public, usually without a security review. Custom GPTs in ChatGPT, Gems in Gemini and agents built in Microsoft 365 Copilot are the most common of these user built assistants. Each one is a small application with its own instructions, its own data store and sometimes its own outbound connections, and each is published by someone whose job is not application security. This guide is for AI governance, Microsoft 365 and Google Workspace administrators and security teams who need to control sharing, knowledge file exposure, actions and lifecycle across all three platforms. Platforms are listed alphabetically; order is never a ranking. The broader low-code and internal AI app model is covered in the Citizen Developer and Internal AI App Governance Guide; this page goes deeper on the assistant builders themselves.

Key takeaways

• A shared assistant is a file share with a chat interface. Anyone who can talk to an assistant can try to get its instructions and knowledge files out of it, so share scope must follow the classification of the most sensitive file attached.
• Sharing settings live in more than one place. Gems inherit Google Drive sharing, Copilot agent knowledge depends on SharePoint permissions, and GPT sharing sits in workspace roles; check all of them, not only the assistant toggle.
• Actions are the highest risk feature. An assistant that calls an external API can send conversation content out of your tenant; allow actions only to approved domains and only with per-user authentication.
• Turning a setting off rarely cleans up the past. Disabling Gem sharing leaves earlier shares in Drive, and Microsoft 365 sharing policy changes apply only to new sharing actions, so pair every policy change with a review of existing assistants.
• Lifecycle is changing under you. OpenAI has announced retirement of custom GPTs for affected Enterprise workspaces and Google is moving personal account Gems to skills, so inventory now and plan migrations rather than rebuilding blind.

Why user built assistants need their own governance

A user built assistant packages four things that used to need a developer: a system prompt, a set of reference files, optional tools or actions, and a sharing scope. The platforms make each step a form field, which is the point, and also the problem. Three properties make these assistants different from ordinary document sharing:

• Instructions are not secret: the OWASP Top 10 for LLM Applications 2025 entry LLM07:2025 System Prompt Leakage says system prompts should not be treated as secrets or used as a security control. Builders routinely paste API keys, internal URLs and escalation contacts into instructions. See the OWASP LLM Top 10 LLM07 System Prompt Leakage Guide.
• Knowledge files are reachable through the conversation: OpenAI's own builder guidance warns that "content from the files that are uploaded could be included in the output", and its GPT Builder article tells builders: "Don't include information you do not want the user to know." Research published in 2023, Assessing Prompt Injection Risks in 200+ Custom GPTs, tested over 200 user designed GPTs with adversarial prompts and showed that both customised system prompts and uploaded files could be extracted.
• Sharing compounds: a builder shares an assistant, a colleague shares it onwards, and the knowledge files travel with the assistant rather than with the document management system that normally governs them. The audience of a file quietly becomes the audience of the assistant.

The practical rule follows from these: treat the assistant's audience as the audience of every file and instruction inside it. If a file is too sensitive for that audience, it does not belong in the assistant, whatever the builder writes in the instructions about refusing to reveal it.

How the three platforms handle sharing

The table below summarises the sharing model each vendor documents. Settings names are as published in each vendor's help pages when checked on 8 November 2026; menus move, so confirm in your own admin console.

Availability: OpenAI's GPT admin article covers Enterprise and Edu workspaces. Google's Gem sharing control requires the Gemini Settings administrator privilege. Microsoft states that users need the Microsoft 365 Copilot licence that matches an agent's configured capabilities.

Choosing a sharing policy

• Small organisation, one platform: allow building, restrict sharing to named people or groups, block public or external sharing, and review the list of shared assistants monthly. The overhead is low and it closes the riskiest path.
• Large organisation: tier the builders. Most users can build private assistants; organisation-wide or Store listing needs a named owner, a data classification statement and a short review, in the same way Microsoft's restricted sharing mode requires an admin to approve and deploy an agent before others can use it.
• Regulated data: keep assistants that touch regulated data on a separate group or organisational unit with sharing off, so the policy can be stricter without blocking everyone else.

Knowledge files: where the leakage happens

Most "custom GPT data leak" incidents are not platform bugs. They are builders attaching a file to an assistant whose audience should never have seen it. The mechanics differ by platform, and the difference matters.

Four controls reduce exposure on every platform:

1. No secrets in instructions or files: scan new and existing assistants for credentials, connection strings and personal data. Treat any key found as compromised and rotate it. See the Generative AI Data Loss Prevention Guide.
2. Link to the system of record where possible: knowledge that stays in SharePoint or Drive keeps its labels and audit trail; uploaded copies do not. Prefer permission-aware sources for anything above public or internal.
3. Classify the assistant, not just the files: record the highest classification of attached knowledge as an attribute of the assistant and block wider sharing when it exceeds the audience.
4. Retest after sharing changes: when an assistant moves from a team to the whole organisation, ask a member of the new audience to request its instructions and file list. If the assistant complies, the audience change was wrong, not the prompt.

Actions, connectors and outbound data

Actions turn an assistant from a reader into an actor. A GPT action calls a third-party API described by an OpenAPI schema; Copilot agents can use plugins and connectors; Gems can work with connected Google apps. Each path can move conversation content, and sometimes knowledge content, to another service. That maps to MITRE ATT&CK T1567 Exfiltration Over Web Service when abused, and to ATLAS AML.T0057 LLM Data Leakage when the model is the route.

• ChatGPT: under Workspace settings, GPTs, owners can set a domain allowlist for actions. OpenAI documents that with no domains added, GPT actions are not allowed, and that allowing a parent domain also allows its subdomains, so list specific hosts rather than broad parents. A separate Apps setting decides whether GPTs created in the workspace can use apps.
• Gemini: Gems inherit what the Gemini app is allowed to reach. Review which Google apps and connected apps are on for each organisational unit before allowing Gem sharing, because a shared Gem runs with whatever the recipient's Gemini app can access. See the Gemini for Google Workspace Security Guide.
• Microsoft 365 Copilot: plugins and their capabilities are governed under Agents, Tools, Plugins, with organisation-wide blocking, per-user availability and an access request queue. Microsoft notes that blocking a plugin does not revoke consent, stop a remote service, remove indexed connector data, or stop another plugin from using the same MCP server or connector, so revoke consents and connections as a separate step. See the Securing Microsoft Copilot Studio Agents Guide.

Where identity fits

Every action is an identity decision. An action that authenticates with a single API key embedded by the builder gives every user of the assistant the builder's access to the target system, a shared non-human credential with no owner once the builder leaves. Require per-user OAuth with narrow scopes for actions that touch company systems, register the client in your identity provider, and record the assistant as the consuming application. Consent phishing is the mirror risk: the CoPhish research showed a malicious Copilot Studio agent, shared through a demo page on a Microsoft domain, steering users to an attacker's consent prompt and forwarding the token. Restricting user consent and requiring admin approval for sensitive permissions blunts both. See the Agent Identity and Access Guide.

Inventory, ownership and lifecycle

You cannot govern assistants you cannot list. Each platform gives admins a different inventory view:

• ChatGPT: workspace owners can view published GPTs and edit ownership and access for each from the GPTs table in workspace settings; workspace analytics includes a GPTs section for adoption, and GPT conversations are available in the Compliance Platform. See the ChatGPT Enterprise Security Guide.
• Gemini: shared Gems are Drive items, so Drive inventory, sharing reports and audit logs are the starting point for finding Gems shared widely or externally.
• Microsoft 365 Copilot: the Agent Registry under Agents, All agents, Registry lists agents by publisher type (Microsoft, external partner, published by your org, and shared by creator) with tiles for agents without owners, unmanaged agents and agents at risk. Admins can block or delete ownerless agents, and a preview Microsoft Graph API lists agent packages.

Ownership is the most common gap. Microsoft notes that agents can become ownerless when their creator is deleted from the organisation; the same happens to GPTs and Gems when a builder leaves. Add assistant ownership transfer to the leaver process and review ownerless assistants monthly. See the Joiner-Mover-Leaver Guide.

Platform changes to plan for

• ChatGPT: OpenAI's GPT admin article, checked on 8 November 2026, states that for affected Enterprise workspaces retirement of custom GPTs is planned for 11 December 2026, recommends moving workflows to plugins, and says other plans may follow the same transition timeline (no dates announced for them yet). Inventory GPTs, their knowledge and their action domains before migration, and re-apply restrictions to the replacement, since plugin availability is set separately under Workspace settings, Plugins.
• Gemini: Google's Gems help page, checked on the same date, says that Gems on personal accounts are scheduled to become skills, with Google stating automatic migration begins on 17 November 2026; confirm the position for work or school accounts with your Google Workspace admin console, as the announcement focuses on personal accounts. Expect staff who used personal Gems for work to look for a replacement, which is a shadow AI signal worth watching.
• Microsoft 365 Copilot: agent and plugin governance is consolidated in the Microsoft 365 admin center Agents area; track the registry's risk tiles and the plugin request queue as the tools change.

Dates move. Treat these as announced positions and recheck the vendor pages before acting on them.

A phased rollout

1. Discover (weeks 1 to 2): export every assistant from the three inventories, with owner, sharing scope, knowledge sources and actions. Flag public, external, organisation-wide and ownerless assistants first.
2. Contain the worst exposure (weeks 2 to 3): remove external and public sharing for assistants holding internal or higher data, set the GPT action domain allowlist, and restrict the Microsoft 365 sharing control to a pilot group. Announce the change; existing shares will not reset themselves.
3. Set the standard (weeks 3 to 6): publish a builder standard: no secrets, classification statement, named owner and deputy, approved action domains, review before organisation-wide sharing. Fold it into the AI Acceptable Use Policy Template.
4. Pilot the review path: run the approval flow for one business unit, measure turnaround and fix friction before widening. Keep a rollback: if the review queue backs up, return sharing to the previous group setting rather than letting users route around it.
5. Monitor and recertify: quarterly owner attestation for shared assistants, monthly ownerless review, and automatic alerts on new external shares.

Detection and measurement

Useful metrics: percentage of shared assistants with a named owner (target 100%), number of externally shared assistants holding internal or higher data (target zero), median days to review an organisation-wide sharing request, ownerless assistants older than 30 days, and the share of assistants whose actions authenticate per user rather than with an embedded key. See the AI Usage Monitoring Guide.

Framework mapping

Common failure patterns

• "Do not reveal your files" as the control: an instruction is not access control; the 2023 research above extracted files from GPTs whose builders relied on it.
• Turning off sharing and declaring victory: Gems shared before the switch stay shared in Drive, and Microsoft sharing changes apply only to new actions. The old exposure remains until someone reviews it.
• Builder keys in actions: a personal API key behind an action gives every user the builder's rights and survives the builder's departure.
• Broad parent domains in the allowlist: allowing a parent domain also allows its subdomains, including ones run by other tenants on shared platforms.
• Assuming agent removal removes file access: files shared automatically with an agent's users stay shared in SharePoint after a user is removed from the agent.
• Migrating without inventory: rebuilding retired GPTs as plugins or skills without carrying over owner, classification and action limits recreates the sprawl with fewer records.

Practitioner checklist

• Export every custom GPT, Gem and Copilot agent with owner, sharing scope, knowledge and actions.
• Remove public and external sharing for any assistant holding internal or higher data.
• Set the ChatGPT action domain allowlist to specific hosts and review the third-party GPT setting.
• Decide whether "Allow users to share Gems" is on per organisational unit and check Drive external sharing alongside it.
• Restrict Microsoft 365 agent org-wide sharing to approved users or groups and use the registry to block ownerless agents.
• Scan instructions and knowledge files for secrets; rotate anything found.
• Require per-user OAuth for actions touching company systems and restrict user consent.
• Add assistant ownership transfer to the leaver process and review ownerless assistants monthly.
• Plan migrations for announced GPT and personal Gem changes with inventory carried over.

Standards and references

• OpenAI Help Center: GPTs, ChatGPT Enterprise version
• OpenAI Help Center: Creating a GPT
• Google Workspace Admin Help: Turn Gem sharing on or off
• Google Gemini Apps Help: Use Gems in Gemini Apps
• Microsoft Learn: Agent Registry in the Microsoft 365 admin center
• Microsoft Learn: Share and manage agents built in agent builder
• OWASP: LLM07:2025 System Prompt Leakage
• arXiv: Assessing Prompt Injection Risks in 200+ Custom GPTs

Related NHI Mgmt Group resources: Citizen Developer and Internal AI App Governance Guide · Shadow AI Discovery Guide · Generative AI Data Loss Prevention Guide · Top 10 Shadow AI Risks