Yes, Copilot agents can be shared, and sharing is built into every major Copilot product Microsoft and GitHub ship today. You can hand an agent to a single coworker, a Microsoft Teams channel, your whole tenant, or even external guests, but each path has its own rules, license gates, and security guardrails.
Sharing sits at the intersection of three forces: the platform you built the agent on (like Microsoft Copilot Studio, Microsoft 365 Copilot, or GitHub Copilot Extensions), the license tier your recipient holds, and the governance policies set by your tenant admin through the Power Platform admin center. Miss any one of those, and the share button simply will not work, or worse, it will work and leak data you never meant to release.
A 2025 Microsoft Work Trend Index report found that 82% of leaders say their employees will need new AI agent skills within the next year, and sharing is the single feature that turns a private experiment into a team-wide productivity win.
- 🧭 How sharing works across Copilot Studio, Microsoft 365 Copilot, GitHub Copilot, and Security Copilot
- 🔐 The license, role, and admin policy checks that decide who can share and who can receive
- 🧪 Three real sharing scenarios with clear outcomes, plus three named examples you can copy
- ⚠️ The seven most common sharing mistakes and the exact consequence of each one
- 📋 A full do’s, don’ts, pros, cons, and FAQ breakdown you can hand to your team today
What a Copilot Agent Actually Is
A Copilot agent is a packaged AI assistant that lives inside a Microsoft or GitHub surface and performs tasks on behalf of a user. The agent bundles a system prompt, a set of knowledge sources, a group of actions or tools, and a publishing target into one shareable object. Microsoft defines an agent in the Copilot Studio documentation as a custom AI assistant that can answer questions, automate tasks, and connect to business data.
Agents come in two broad flavors today. The first is a declarative agent, which runs on the Microsoft 365 Copilot orchestrator and uses a simple manifest file. The second is a custom engine agent, which brings its own model and logic, often built in Copilot Studio or Azure AI Foundry. The Microsoft 365 agents overview explains both types in detail.
Sharing behaves very differently for each flavor. A declarative agent shares like a Microsoft 365 app, through Teams app policies and the Microsoft 365 admin center. A custom engine agent shares through Copilot Studio’s own access model, which maps to Microsoft Entra ID security groups. Understanding this split is the first step to sharing safely.
Declarative vs. Custom Engine Agents
A declarative agent is the lightweight option. It uses the Microsoft 365 Copilot license your user already owns, it runs on Microsoft’s hosted GPT models, and it inherits your tenant’s compliance posture automatically. You build it in the Copilot Studio agent builder or in Visual Studio Code with the Microsoft 365 Agents Toolkit.
A custom engine agent is the heavy-duty option. It can use any model, call any API, and live on any channel, but it needs its own Copilot Studio or Azure capacity. The Copilot Studio licensing guide shows that custom engine agents bill per message, not per user, which changes how you think about sharing widely.
The practical consequence is simple. A declarative agent shared with 10,000 people costs nothing extra if they already hold Microsoft 365 Copilot licenses. A custom engine agent shared with 10,000 people can burn through a message pack in hours if you do not cap usage.
Sharing in Microsoft Copilot Studio
Copilot Studio is the most common place people build agents, and it has the richest sharing model. Inside the maker portal, every agent has a Share button in the top-right corner that opens a dialog very similar to the SharePoint or OneDrive sharing experience. The Copilot Studio share documentation walks through each option.
You can share with named users, with Microsoft Entra security groups, or with your entire organization. You can also grant two different roles: user, which lets the recipient chat with the agent, and co-owner, which lets the recipient edit the agent’s topics, knowledge, and actions. A co-owner can also re-share the agent, which is a small detail with big security consequences.
Sharing a Copilot Studio agent does not automatically publish it to a channel. Publishing and sharing are two separate steps, and both must happen before a coworker can actually use the agent. Forgetting to publish is the number one reason shared agents appear broken.
Sharing to Microsoft Teams
Publishing a Copilot Studio agent to Microsoft Teams turns it into a Teams app that anyone in your tenant can add. The publish to Teams guide shows the four-step flow: enable the Teams channel, submit the agent for admin approval, wait for the admin to approve it in the Teams admin center, and then share the install link.
The consequence of skipping the admin approval step is that the agent sits in a “pending” state forever. A common misconception is that a Global Administrator can bypass this queue, but Microsoft routes all Copilot Studio Teams apps through the Teams app approval workflow by design.
A real example: Maya, an HR manager at a 3,000-person U.S. insurance firm, builds a “Benefits Buddy” agent in Copilot Studio. She clicks Share, adds the “All Employees” security group, publishes to Teams, and emails her IT admin the approval link. Within 48 hours every employee has Benefits Buddy pinned in their Teams sidebar.
Sharing to Microsoft 365 Copilot Chat
Publishing an agent to Microsoft 365 Copilot Chat makes it appear in the agent picker inside the Microsoft 365 Copilot app. The M365 Copilot extensibility docs explain that this channel requires a Microsoft 365 Copilot license on both the builder and the end user.
The consequence of missing that license is a silent failure: the agent appears in the picker, but any message returns a “this agent is not available for your license” error. A common misconception is that the free Microsoft 365 Chat experience can run custom agents, but Microsoft restricts custom agent execution to paid Copilot seats.
Take Jamal, a sales operations lead at a Chicago SaaS company. He builds a “Deal Desk Helper” agent that reads Salesforce and drafts approval memos. He shares it with his 40-person sales team, but only the 25 reps with Microsoft 365 Copilot licenses can actually run it. Jamal has to file a license request for the other 15 before they can use it.
Sharing Externally and Cross-Tenant
External sharing is possible but tightly controlled. Copilot Studio supports publishing agents to a public website, to a Facebook page, to a custom mobile app, and to authenticated external users through Microsoft Entra External ID. The secure access for external users guide lists every supported channel.
The consequence of enabling public web publishing without authentication is that anyone with the URL can chat with your agent and consume your message capacity. A common misconception is that the demo website is private, but the default web channel is fully public until you add an authentication provider.
Cross-tenant sharing, where a builder in Tenant A hands an agent to a user in Tenant B, is not supported for Microsoft 365 Copilot agents today. You must either export the agent as a solution and import it into the other tenant, or publish it as a Teams app through Microsoft AppSource.
Sharing in Microsoft 365 Copilot
Microsoft 365 Copilot ships a lightweight agent builder right inside the Copilot app, and its sharing model is simpler than Copilot Studio’s. You click the three dots on an agent card, choose Share, and pick people, groups, or the whole organization. The agent builder sharing docs cover every option.
Every recipient needs a Microsoft 365 Copilot license to run the agent, and the builder needs at least one Copilot license plus permission to create agents in the tenant. Admins can restrict who can build agents through the Copilot controls in the Microsoft 365 admin center.
Organization-Wide Publishing
Sharing an agent “with my organization” makes it discoverable in the Copilot agent store for every licensed user. This is a powerful setting because it turns a personal utility into a company asset. The agent store documentation shows how agents appear alongside Microsoft-built ones.
The consequence of publishing too widely is that bad or half-finished agents pollute the store and train users to ignore them. A common misconception is that org-wide sharing needs admin approval for every agent, but once an admin turns on the policy, every builder can publish freely unless you tighten the setting.
Consider Priya, a finance director at a Boston biotech. She publishes a “Month-End Close Checklist” agent to her whole organization, and within a week 400 employees have used it. Because she set herself as the only co-owner, no one can edit the prompt without her approval, which keeps the agent’s answers consistent.
Revoking and Auditing Access
Sharing is never one-way. Every Copilot sharing surface logs access events to the Microsoft Purview audit log, and owners can revoke access at any time from the same Share dialog they used to grant it. Revocation is immediate for declarative agents and near-immediate for custom engine agents.
The consequence of never auditing access is that former employees, contractors, or reorganized teams keep running agents that touch sensitive data. A common misconception is that deleting a user’s Microsoft 365 account automatically revokes every agent share, but orphaned shares can linger on security groups the user belonged to.
Sharing GitHub Copilot Agents and Extensions
GitHub Copilot has its own agent model, and the sharing rules look very different from the Microsoft 365 world. A Copilot Extension is a GitHub App that plugs into Copilot Chat, and it is shared by installing the app on a user, organization, or repository.
To share a private extension, the builder publishes the GitHub App privately and then installs it on the target organization. To share a public extension, the builder lists it on the GitHub Marketplace, where any Copilot user can install it.
Organization-Level Installation
A GitHub organization owner can install a Copilot Extension once and make it available to every member with a Copilot license. The managing Copilot policies guide shows how owners toggle extension access for the whole enterprise.
The consequence of installing an extension at the org level without reviewing its permissions is that the app may gain read or write access to every repo in the org. A common misconception is that Copilot Extensions only see the current chat window, but many request repo, issue, or pull request scopes.
Take Diego, an engineering manager at a 200-developer fintech. He installs a “Jira Sync” Copilot Extension across his GitHub organization, which lets every developer open Jira tickets from Copilot Chat. Because he reviewed the permissions first, the extension only gets issues:read and not contents:write.
Sharing Copilot Coding Agents
In 2025 GitHub launched the Copilot coding agent, a background agent that picks up issues and opens pull requests on its own. Sharing the coding agent means assigning it as a collaborator on a repository, which any repo admin can do.
The consequence of assigning the coding agent without branch protection rules is that it can push directly to main. A common misconception is that the agent always opens a pull request, but without proper rules it may commit straight to the default branch.
Sharing Microsoft Security Copilot Agents
Microsoft Security Copilot has its own agent catalog focused on security operations, and sharing follows a role-based model tied to Microsoft Entra roles. A Security Administrator can share a prompt book or agent with any user holding the Security Reader role or higher.
The consequence of over-sharing a Security Copilot agent is that low-privilege users can read incident details, threat intelligence, and identity data that should stay in the SOC. A common misconception is that Security Copilot agents honor the recipient’s underlying Defender permissions, but the agent can surface summarized data that the recipient could not normally query.
Security Copilot bills on Security Compute Units, and shared agents pull from the same pool. Heavy sharing without capacity planning leads to throttled responses during an active incident, which is exactly when you need the tool most.
Three Real-World Sharing Scenarios
Every sharing decision has a direct consequence. The three tables below show the most common scenarios and what happens at the end of each one.
Scenario 1: Internal Team Agent
| Sharing Choice | Business Outcome |
|---|---|
| Share with a 50-person Entra security group as “user” role | Group members chat with the agent but cannot edit it, and the builder keeps full control |
| Publish to the team’s Microsoft Teams channel | Agent appears as a pinned app for fast access during meetings and chats |
| Skip org-wide publishing | Agent stays invisible in the company-wide store, which prevents noise and confusion |
Scenario 2: Customer-Facing Agent
| Sharing Choice | Business Outcome |
|---|---|
| Enable the Copilot Studio web channel with Entra External ID | Only authenticated customers can chat, and each session is logged to Purview |
| Add a daily message cap through Copilot Studio capacity settings | Runaway traffic cannot drain your message pack and trigger overage billing |
| Add a DLP policy blocking the HTTP connector | Agent cannot call arbitrary external APIs, which reduces data exfiltration risk |
Scenario 3: Cross-Organization Agent Distribution
| Sharing Choice | Business Outcome |
|---|---|
| Export the agent as a managed solution and list it on Microsoft AppSource | Partner tenants install a signed, versioned copy they can trust |
| Provide a deployment template instead of raw source | Each partner keeps their own data residency and audit trail |
| Require a support contract for updates | You control the upgrade path and can push security fixes on a schedule |
Three Named Examples You Can Copy
Maya (HR, insurance company). Maya builds “Benefits Buddy” in Copilot Studio, shares it with the “All Employees” Entra group as user-role, publishes to Teams, and asks her IT admin to approve the Teams app. Result: 3,000 employees get instant benefits answers without flooding the HR inbox.
Jamal (Sales Ops, SaaS). Jamal builds “Deal Desk Helper” in the Microsoft 365 Copilot agent builder, shares it only with the 25 licensed reps on his team, and sets himself plus one backup as co-owners. Result: Copilot seats are protected and quote turnaround drops from 2 days to 4 hours.
Diego (Engineering, fintech). Diego installs a “Jira Sync” Copilot Extension at the GitHub organization level after reviewing its permissions, and he turns on Copilot Chat audit logs for his enterprise. Result: developers log tickets 40% faster and every action is traceable.
Mistakes to Avoid When Sharing
- Publishing without admin approval. The agent sits in pending and recipients blame you, not the admin queue. Always file the Teams or AppSource approval request the same day you share.
- Granting co-owner when user is enough. Co-owners can edit prompts and re-share, which widens the blast radius of any mistake. Default to the user role.
- Ignoring license tiers. Sharing a Microsoft 365 Copilot agent with unlicensed users produces silent failures that look like bugs. Check license assignments before sharing.
- Skipping DLP policies. Without a Power Platform DLP policy, your agent can mix business and non-business connectors and leak data. Apply a baseline policy to every environment.
- Leaving the default web channel public. The demo website is unauthenticated by default, so strangers can burn your message pack. Turn it off or add authentication before sharing.
- Forgetting capacity caps. A viral internal agent can drain a message pack in a day. Set a daily cap in Copilot Studio capacity management before you publish.
- Never auditing shares. Orphaned shares accumulate when employees leave or reorg, and stale agents touch live data. Run a quarterly access review in Purview.
- Sharing across tenants without a solution package. Copy-pasting prompts breaks lineage and kills update paths. Export a managed solution and version it properly.
- Over-sharing Security Copilot data. Summaries can expose details low-privilege users should never see. Limit to Security Reader or higher.
- Pushing code with the Copilot coding agent to an unprotected branch. Without branch protection, the agent commits straight to
main. Always protect the default branch first.
Do’s and Don’ts of Copilot Agent Sharing
Do’s
- Do start with the smallest audience that delivers value, because you can always widen access later.
- Do use Entra security groups instead of naming individuals, because group membership updates automatically when people move teams.
- Do publish a changelog with every version bump, because users need to know what changed and why.
- Do test the share with a pilot group of five people, because you catch license gaps before a company-wide rollout.
- Do document the agent’s data sources in the description field, because governance teams need that record for compliance reviews.
Don’ts
- Don’t share agents from personal Microsoft accounts, because those shares bypass your tenant’s audit and DLP controls.
- Don’t rely on obscurity, because an agent URL will eventually leak and you need real authentication.
- Don’t mix production and sandbox agents in the same environment, because a sandbox share can overwrite a production one.
- Don’t share agents that call unapproved connectors, because a single rogue connector can exfiltrate data at machine speed.
- Don’t forget to revoke access when employees change roles, because dormant shares are a top audit finding.
Pros and Cons of Broad Sharing
Pros
- Wider sharing drives faster adoption, because every new user amplifies the return on your build time.
- Shared agents surface new use cases you never imagined, because users push the prompt in directions you did not test.
- Shared agents reduce duplicate work, because ten teams stop each building their own version of the same helper.
- Shared agents create a library effect, because popular agents become templates for the next generation of builders.
- Shared agents build AI literacy across the company, because every interaction teaches users how to prompt well.
Cons
- Broad sharing raises your blast radius, because a single bad prompt or leaked secret reaches everyone at once.
- Broad sharing increases message consumption, because custom engine agents bill per message regardless of who sends it.
- Broad sharing complicates governance, because Purview reviews and DLP updates now span every team.
- Broad sharing invites shadow IT, because users start demanding features you never promised to support.
- Broad sharing can dilute quality, because co-owners may edit prompts without testing the changes.
The Step-by-Step Sharing Process
Every Copilot sharing workflow follows the same five steps. Missing any one step breaks the share, and the error messages rarely tell you which step you skipped.
Step 1: Confirm licenses. Check that you and every recipient hold the right license. The Microsoft 365 Copilot license guide lists the SKUs that unlock agent features.
Step 2: Configure the channel. Enable the target channel, such as Teams, Microsoft 365 Chat, or a public website, inside the agent’s settings. Each channel has its own authentication and branding options.
Step 3: Apply governance policies. Confirm that your environment’s DLP policy allows every connector the agent uses. If any connector is blocked, the agent fails silently when a user triggers that action.
Step 4: Click Share. Choose named users, security groups, or the whole organization, and pick the right role. Add a short message so recipients know why they are getting the agent.
Step 5: Announce and monitor. Post an announcement in the target Teams channel, then watch the Copilot Studio analytics dashboard for the first 48 hours to catch errors early.
Key Entities to Know
Microsoft Copilot Studio is the low-code builder for custom agents, and it owns the primary sharing dialog for most Microsoft agents. Microsoft 365 Copilot is the paid productivity assistant that hosts declarative agents and enforces the per-user license. Microsoft Entra ID supplies the identities, groups, and external identity providers that every share depends on.
GitHub Copilot delivers the developer agent experience through Copilot Chat and Copilot Extensions, and it shares through GitHub App installation. Microsoft Purview logs every sharing event and every agent interaction for compliance teams. Microsoft AppSource is the public marketplace where partners distribute agents to other tenants.
The Power Platform admin center is where tenant admins set environment policies, DLP rules, and capacity caps. Microsoft Teams is the most popular channel for shared agents, and its own app approval workflow gates every published agent. Understanding how these entities connect prevents most sharing headaches before they start.
FAQs
Can I share a Copilot Studio agent with my entire company?
Yes. The Share dialog lets you pick “Everyone in my organization” as the audience, which grants user-role access to every licensed employee in your Microsoft Entra tenant through a single click.
Can I share a Copilot agent with external users or customers?
Yes. Copilot Studio supports public web, Facebook, custom app, and Entra External ID channels, but you must add authentication and capacity caps before exposing any agent to users outside your tenant.
Can I share an agent across Microsoft 365 tenants?
No. Direct cross-tenant sharing is not supported today, so you must export the agent as a managed solution or publish it to AppSource for another tenant to install it cleanly.
Can a coworker edit a Copilot agent I shared with them?
Yes. But only if you granted them the co-owner role, because user-role recipients can chat with the agent but cannot change its topics, knowledge sources, actions, or publication channels.
Can admins block agent sharing for specific users?
Yes. Tenant admins use the Power Platform admin center and Microsoft 365 admin center to restrict who can create, share, or install agents at the user, group, or environment level.
Can I revoke access to an agent I already shared?
Yes. The same Share dialog that grants access also removes it, and revocation takes effect within minutes for declarative agents and near-immediately for Copilot Studio custom engine agents.
Can shared agents see my private files in OneDrive or SharePoint?
No. Microsoft 365 Copilot agents respect the recipient’s own file permissions, so a shared agent can only read content the individual user already has the right to read.
Can I share GitHub Copilot Extensions with my whole organization?
Yes. A GitHub organization owner installs the Copilot Extension at the org level, which makes it available to every member holding a GitHub Copilot Business or Enterprise license.
Can I charge other companies for a Copilot agent I built?
Yes. You can publish paid agents through Microsoft AppSource or GitHub Marketplace, but you must meet the publisher requirements and comply with each store’s review process.
Can sharing a custom engine agent increase my bill?
Yes. Custom engine agents consume Copilot Studio messages per interaction, so wider sharing means more messages, and you should set daily caps before publishing to a large audience.
Can Security Copilot agents be shared with non-security staff?
No. Microsoft restricts Security Copilot access to users holding the Security Reader role or higher, so general employees cannot run or receive shared Security Copilot agents.
Can I audit who used a shared Copilot agent?
Yes. Every agent interaction flows into the Microsoft Purview audit log and the Copilot Studio analytics dashboard, which together show user, timestamp, prompt, and action-level detail.