Every Third-Party App in Your Tenant Is About to Grow an Agent. Audit the Consent Grants First.

Every Third-Party App in Your Tenant Is About to Grow an Agent. Audit the Consent Grants First.

Picture the help desk ticket six months from now: “Why does the Contoso CRM agent have read access to every user’s calendar and files, and who approved that?” Nobody approved it, exactly. A Teams admin clicked Enable on a recommended agent, breezed past a consent prompt that looked like every other consent prompt, and now a third-party service principal is sitting in your tenant with delegated Graph permissions you never inventoried.

That scenario is coming to a Teams Admin Center near you.

What’s actually shipping

The roadmap item is “Microsoft Teams: Enable agents for existing applications in your organization” (Microsoft 365 Roadmap ID 569608), slated for General Availability in October CY2026. It targets standard commercial (worldwide) tenants using Teams with third-party apps already deployed.

The pitch is reasonable on its face. If your org already runs a third-party app — a CRM, a ticketing system, a knowledge base — Microsoft will surface the matching Teams agent for it inside the Teams Admin Center, recommend the “high-value” ones, and walk an admin through enablement including “any required configuration changes.” The goal is to get more mileage out of software you already pay for by pulling it into the flow of work in Teams.

Here’s the part the summary glosses over: an agent is not a UI toggle. An agent is an identity. When you enable one, you’re consenting a service principal in Microsoft Entra ID — granting it OAuth scopes, wiring it to sign-in, and in the newer models, giving it its own workload identity that can act on a user’s behalf. The Teams Admin Center is going to make that feel like enabling a feature flag. Entra is where the actual security decision lands.

Why this is an Entra problem, not a Teams problem

Every agent you enable does one of two things behind the scenes:

  • Extends an existing enterprise application with new delegated or application permissions — meaning the service principal you already consented gets more scope.
  • Registers a new service principal for the agent runtime, which then needs its own admin consent.

Either way, the blast radius shows up under Entra admin center → Identity → Applications → Enterprise applications, not in Teams. And if your user consent settings are still on the old permissive default — “allow user consent for apps” — a chunk of these agents can be lit up without an admin ever seeing the request. Microsoft moved the default to “allow limited user consent” for tenants created after late 2020, but plenty of older tenants never touched it. Check yours before October, because agent enablement is exactly the workflow that will exploit a loose consent policy.

The bigger shift Microsoft isn’t putting in this roadmap card: Entra Agent ID

This item doesn’t exist in a vacuum. It’s the consumer-facing edge of Microsoft’s much larger bet on agent identity. Microsoft Entra Agent ID, announced at Build and expanding through preview across this year, gives AI agents — Copilot Studio agents, Azure AI Foundry agents, and increasingly third-party ones — first-class identities in your directory. They get their own entries, their own lifecycle, and eventually their own Conditional Access enforcement and access reviews.

Translation: the agents you enable from Teams Admin Center in October are the leading edge of a directory that’s about to fill up with non-human identities. Today you count users and maybe track your service principals loosely. Within a year you’ll be governing a third population — agents — that authenticate, hold permissions, and drift out of scope just like the guest accounts you forgot to review.

Start treating agents as identities now, while the count is small enough to actually inventory.

Audit what you have before the button exists

You want a baseline of every enterprise application, its consent posture, and its delegated grants — so that when agents start appearing, you can tell new from old. Modern Microsoft.Graph module only. This reports; it changes nothing.

#requires -Modules Microsoft.Graph.Applications, Microsoft.Graph.Authentication
# Baseline: enterprise apps + delegated OAuth grants + consent posture
Connect-MgGraph -Scopes @(
    'Application.Read.All',
    'DelegatedPermissionGrant.Read.All',
    'Directory.Read.All'
) -NoWelcome

$report = [System.Collections.Generic.List[object]]::new()

try {
    # Pull all service principals (auto-pagination via -All)
    $sps = Get-MgServicePrincipal -All -Property Id,AppId,DisplayName,AppOwnerOrganizationId,`
        ServicePrincipalType,SignInAudience,Tags -ErrorAction Stop

    # Your own tenant id, to flag first-party vs third-party
    $tenantId = (Get-MgContext).TenantId

    foreach ($sp in $sps) {
        # Delegated (user) permission grants for this SP
        $grants = Get-MgOauth2PermissionGrant -All `
            -Filter "clientId eq '$($sp.Id)'" -ErrorAction SilentlyContinue

        $adminScopes = ($grants | Where-Object ConsentType -eq 'AllPrincipals' |
                        ForEach-Object { $_.Scope -split ' ' } | Sort-Object -Unique)

        $isThirdParty = $sp.AppOwnerOrganizationId -and `
                        $sp.AppOwnerOrganizationId -ne $tenantId

        $report.Add([pscustomobject]@{
            DisplayName      = $sp.DisplayName
            AppId            = $sp.AppId
            ThirdParty       = [bool]$isThirdParty
            Type             = $sp.ServicePrincipalType
            TenantWideConsent= [bool]($grants | Where-Object ConsentType -eq 'AllPrincipals')
            AdminScopeCount  = $adminScopes.Count
            HighRiskScopes   = (($adminScopes | Where-Object {
                                 $_ -match 'ReadWrite\.All|Mail\.|Files\.|Calendars\.|Directory\.'
                               }) -join '; ')
        })
    }
}
catch {
    Write-Error "Audit failed: $($_.Exception.Message)"
}
finally {
    Disconnect-MgGraph | Out-Null
}

$report |
    Sort-Object -Property @{E='HighRiskScopes';Descending=$true}, ThirdParty |
    Format-Table DisplayName, ThirdParty, TenantWideConsent, AdminScopeCount, HighRiskScopes -AutoSize

# Snapshot to diff against after agents roll out
$report | Export-Csv ".\entra-app-baseline-$(Get-Date -f yyyyMMdd).csv" -NoTypeInformation

Run that today and again the week after your tenant picks up the October release. Diff the CSVs. Any new third-party service principal or any existing app that suddenly grew high-risk delegated scopes is an agent someone enabled — or wanted to.

Check your consent gate

The single most useful thing you can do before this ships is confirm users can’t self-consent risky agents. Report on the current admin consent request policy:

#requires -Modules Microsoft.Graph.Identity.SignIns, Microsoft.Graph.Authentication
Connect-MgGraph -Scopes 'Policy.Read.All' -NoWelcome

try {
    $policy = Get-MgPolicyAdminConsentRequestPolicy -ErrorAction Stop
    [pscustomobject]@{
        AdminConsentWorkflowEnabled = $policy.IsEnabled
        RequestsExpireAfterDays     = $policy.RequestDurationInDays
        NotifyReviewers             = $policy.NotifyReviewers
        ReviewerCount               = $policy.Reviewers.Count
    } | Format-List
}
catch {
    Write-Error "Could not read admin consent policy: $($_.Exception.Message)"
}
finally {
    Disconnect-MgGraph | Out-Null
}

If AdminConsentWorkflowEnabled comes back False, turn it on before October. That routes every “I want this agent” request to a named reviewer instead of letting it silently succeed or silently fail. You configure it under Entra admin center → Identity → Applications → Enterprise applications → Consent and permissions → Admin consent settings. I’m deliberately not scripting the enable step here — this is a governance control you should set by hand, with a real reviewer group behind it, not fire from a pipeline. If you must automate it, wrap the Update-MgPolicyAdminConsentRequestPolicy call in -WhatIf and test in a non-production tenant first.

Conditional Access still mostly can’t see agents — plan for it anyway

Here’s what will bite you in six months. Conditional Access for workload identities exists (it needs the Workload Identities Premium add-on), and it lets you scope policy to service principals — block by location, require the SP to come from named IP ranges. But it’s a per-app add and it does not yet fluidly cover the agent-on-behalf-of-user pattern that these Teams agents use. As Entra Agent ID matures, expect agent-aware Conditional Access and agent-scoped access reviews to land. Budget for the Workload Identities licensing conversation now, because “we’ll govern the agents later” is how you end up with 400 un-reviewed non-human identities and no policy touching any of them.

Where to verify all of this

  • Teams Admin Center → Teams apps → Manage apps — where the agent discovery and enablement workflow will surface.
  • Entra admin center → Identity → Applications → Enterprise applications — the actual service principals and their permissions.
  • Enterprise applications → Consent and permissions — user consent settings and the admin consent workflow.
  • Identity → Monitoring & health → Audit logs — filter on “Consent to application” and “Add service principal” to catch agent enablement after the fact.
  • Microsoft 365 Roadmap ID 569608 for the GA slip risk; roadmap dates move, and October is a “CY2026” target, not a committed day.

Bottom line

  1. Fix your user consent setting first. If older tenants are still on “allow user consent for apps,” this feature is a self-service door into your directory. Move to admin-approval or limited consent before October.
  2. Baseline your enterprise apps now. Run the audit script, save the CSV, and diff after the rollout so new agents can’t hide among old apps.
  3. Turn on the admin consent workflow with real reviewers. One-click enablement in Teams deserves a human in the loop in Entra.
  4. Treat this as the front edge of Entra Agent ID. The agent population is small today and won’t be next year. Get your inventory and access-review muscle working while it’s still countable.

The feature itself is fine. Bringing tools users already have into Teams is genuinely useful. Just don’t let “enable” in one console quietly rewrite the permission grants in another.

Related Post