Oct 15, 2026Blog

What Your Teams Admin Needs to Approve Before Installing an AI Agent

PaigeContent Strategist, Appy.AI

If someone on your team wants to add an AI agent to Microsoft Teams, odds are they've already hit a wall: nothing happens when they try to install it, or there's a message about needing administrator approval. That's not a bug. Teams treats third-party apps as something IT provisions, not something any user adds on their own — and if you're the admin getting asked to approve one, here's what you're actually deciding and how to decide it quickly.

Why Teams gates this and Slack mostly doesn't

Slack's default assumes individual app installation is fine; workspace owners can lock it down, but most teams don't bother. Teams flips the default: a regular user typically can't add an app to a shared team or channel without an admin turning that on, either globally or for that specific app.

This isn't Microsoft being difficult. Teams skews toward larger, more regulated organizations where "anyone can install anything" is a real risk, not a theoretical one. If your organization already has strict governance in Teams, an AI agent inherits it automatically — which is the point.

What you're actually approving

When an app shows up in Teams admin center > Teams apps > Manage apps waiting on you, there are two separate things to evaluate: how the app gets access, and what it asks to access.

How access works: delegated vs. application permissions

Delegated permissions mean the app acts on behalf of a signed-in user and can only reach what that user could reach themselves. If Piper drafts an outreach email, she's acting as the person who asked her to, not reading everyone's mailbox.
Application permissions mean the app acts on its own, independent of any specific signed-in user. These are broader by nature and only a Global Administrator can grant consent for them — a Teams admin without that role can view what's requested but can't approve it.

Most of what a well-built agent needs is delegated: it acts when someone asks it to, scoped to what that person can already see.

What access looks like: resource-specific consent (RSC)

Beyond the Entra ID permissions above, Teams apps can also request resource-specific consent (RSC) — narrower permissions scoped to a single team or chat, defined in the app's manifest rather than at the tenant level. An app with RSC permissions can only touch the team or chat it's actually been added to, not your whole organization's data. A team owner, not just a Global Admin, can consent to these when adding the app to their team.

This is the detail worth remembering: a properly scoped agent should ask for RSC permissions tied to where it's installed, not blanket application permissions across your tenant. If an agent is requesting broad org-wide application access to do something that could clearly be done with scoped, delegated access, that's worth a second look before you approve it.

Where to actually check this

1
Go to Teams admin center > Teams apps > Manage apps.
2
Find the app and look at the Permissions column — it flags whether consent is needed.
3
Select View details, then the Permissions tab, to see every permission the app requests, broken into Application, Delegated, and RSC sections. You can export this as a CSV if you want it in front of a security reviewer before you decide.
4
Review what's requested against what the app is actually for. Does a content-drafting agent need to send email on your behalf, or read calendar data? If the request matches the job, that's a good sign. If it's asking for more than its stated purpose explains, ask the vendor why.
5
Select Accept to grant org-wide consent — this means individual users aren't separately prompted to review permissions every time they start the app, which is what you want for something meant to be used broadly.

A four-step mental checklist before you click Accept

1
Does the permission list match the stated use case? An AI agent for drafting content shouldn't need access to send email on a user's behalf unless that's explicitly part of what it does.
2
Is it asking for application permissions where delegated would do? Application permissions mean the app can act without any user in the loop — reasonable for some background automation, unusual for a chat-based assistant.
3
Is RSC used where possible? Scoped-to-team access limits the blast radius if something goes wrong, compared to tenant-wide access.
4
Who else has reviewed this? If your organization has a security or compliance review step for new vendors, run it before granting org-wide consent — not after a few hundred people are already using the app.

How Appy.AI handles this specifically

Appy.AI installs into Teams as a custom app your admin uploads and approves — Microsoft's standard path for third-party Teams apps, not a workaround. Setup takes about 10 minutes: an admin uploads the app package and reviews the permissions it requests before granting consent, same process described above. Once approved, admins can scope which teams or users have access using app permission policies — so a pilot with one department doesn't mean the whole org gets access on day one.

There's no separate per-user install step after that. Once the app has org-wide or team-scoped access, anyone covered by that scope can open a DM with Violet or @mention her in a channel and start working with the team — Piper, Sage, Scout, and the rest — without further IT involvement.

Getting it approved faster

If you're the person requesting the app, not the admin, a few things speed this up:

Bring the permissions list, not just the pitch. Admins move faster on a request that already shows what's being asked for than one that requires them to go dig it up.
Propose a scoped pilot. Asking for one team rather than the whole org lowers the stakes of the first yes, and app permission policies make that scoping easy to set up correctly.
Name the specific job. "I need competitive research pulled together weekly" gets approved faster than "we want an AI tool."