Microsoft Teams apps and tabs

Microsoft Teams is a platform as well as a client. Apps extend Teams into other systems, and they show up in several different forms — tabs, bots, message extensions, personal apps, and meeting extensions. Knowing the shapes helps both users and admins.

Which apps are allowed is set in app permission policies; building your own is covered in Teams app development for Copilot, and the Copilot-era equivalent is agents and the Agent Store. Tabs most often surface SharePoint pages and Microsoft Lists.

The forms an app can take

• Personal app — a private app on your sidebar, accessible only to you (Planner, Lists, OneNote in personal mode).
• Tab — a pinned page inside a channel or chat (a SharePoint page, a Power BI report, a web app, a wiki).
• Bot — a conversational agent in a chat or channel that responds to messages or events.
• Message extension — actions in the message composer (search a system, share a card, run a workflow).
• Meeting extension — apps that load inside a meeting's side panel or stage (polls, whiteboards, third-party tools).

Many published apps include multiple forms — for example, an HR system might offer a personal app, a tab, and a message extension.

Where apps come from

• Microsoft and partner apps — published in the Teams store, ready to install with one click.
• Custom apps — built by your organisation with the Teams Toolkit or Developer Portal and side-loaded or distributed internally.
• Power Apps and Power Automate — canvas apps and flows can be deployed as Teams apps without writing code.

Governance

Apps run with user permissions, so they can read what the signed-in user can read. Governance therefore matters:

• App permission policies decide which apps users can install.
• App setup policies pin a default set of apps to specific user groups.
• App centric management in the Teams admin center provides per-app, per-user controls.
• Defender for Cloud Apps integrates for monitoring and risk scoring.

For Microsoft 365 Copilot, Copilot agents also surface through this app model — they're Teams apps with grounding and reasoning capabilities.

Lifecycle

Custom apps go through a manifest (.zip package) deployed via the Developer Portal or the Teams admin center. Apps can also be published to the organisation's catalog so users see only your approved third-party plus internal apps.

Get app governance right early. Once apps spread, retrofitting permission policies is much harder than starting strict and loosening as needed.

Why "runs with user permissions" is the key governance fact

The single most important thing to understand about Teams apps from a security standpoint is that most apps operate under delegated permissions — they see and act on exactly what the signed-in user could see and do themselves, no more. This means app governance isn't really about "is this app trustworthy in the abstract" so much as "what Graph permissions does it request, and does the population it's assigned to actually need that access" — a seemingly innocuous productivity app requesting broad Mail.Read or Files.ReadWrite.All scope is a materially different risk than one requesting nothing beyond posting messages to a channel it's explicitly added to, regardless of how polished either app's interface looks.

Frequently asked questions

Can a custom-built internal app be restricted to specific departments only? Yes — publishing it to the organisation's app catalog and then using app setup or app permission policies scoped to specific user groups controls both who can see it in the store and who it's automatically pinned for, so a finance-specific tool doesn't need to be visible to the whole tenant.

Do Copilot agents go through the same governance surface as ordinary Teams apps? Largely yes — agents surface through the same app model (app permission policies, the admin center's app-centric management) with an additional layer specific to agent grounding and data access, which is why the Agent Store is treated as an extension of existing Teams app governance rather than a wholly separate system administrators need to learn from scratch.