Teams transcript API access control is off by default, and after 29 July 2026 that stops being a harmless default. If you have any app, agent, or integration pulling Teams meeting or call transcripts through Microsoft Graph, it can start failing with 403 errors unless a Teams admin turns this on.
This is a good change. It is also the kind of change that breaks quietly if nobody owns it.
Topedia called out the timeline, and Microsoft’s docs confirm the important bits: tenant admins now have a separate control for transcript API access, plus a separate toggle for speaker attribution. App permissions alone are no longer the whole story.
What is changing?
There are now two tenant-level settings under Teams admin center, in Meetings and Meeting settings, for transcript API access:
| Setting | Default | What it does |
|---|---|---|
| Microsoft Graph access | Off | Blocks or allows apps and agents to access meeting transcripts through Graph APIs |
| Include speaker attribution | Off | Controls whether transcript content retrieved through Graph includes speaker names |
That default matters. Microsoft documents that when Graph access is off, transcript requests return 403 Forbidden with the inner error GraphAccessToTranscriptsDisabled.
HTTP/1.1 403 Forbidden
Content-Type: application/json
{
"error": {
"code": "Forbidden",
"message": "Graph API access to transcripts is disabled for this tenant.",
"innerError": {
"code": "GraphAccessToTranscriptsDisabled"
}
}
}
This applies to the usual transcript permissions people have already granted, including OnlineMeetingTranscript.Read.All, OnlineMeetingTranscript.Read.Chat, and CallTranscripts.Read.All.
Why engineers should care
A lot of Teams transcript workflows were built on the assumption that Entra consent plus Graph permissions were enough. That assumption is no longer safe.
If you built Microsoft Copilot and AI agents, meeting note generators, compliance exports, CRM sync, or any automation workflow that consumes transcripts, check it now. For most tenants there is no user-facing impact inside the Teams client. Transcription itself, recording policies, and the transcript experience in Teams are not what this setting changes. The break happens at the API layer.
That distinction is exactly why this can be missed: users still see transcripts in Teams, while your downstream app suddenly stops seeing them.
Second-order effect: this is another nudge away from broad tenant-wide app access being treated as normal. For scheduled private chat meetings, Microsoft already supports the more scoped OnlineMeetingTranscript.Read.Chat permission via resource-specific consent. In practice, this makes least-privilege designs look better and lazy tenant-wide grants look worse. That is overdue when the data in question is literally meeting transcripts.
What about speaker attribution?
Speaker attribution is controlled separately, and that is the more interesting design choice here.
If Graph access is allowed but speaker attribution is off, Microsoft says apps can still retrieve transcript content, but only in the unattributed format using the Accept header application/vnd.microsoft.graph.transcript+text. If the app asks for text/vtt, it gets a different 403 with SpeakerAttributionNotAllowed.
So this is not just on or off. It lets admins allow transcript-based processing while withholding the identity layer. For some orgs, that will be the right compromise.
What I’d verify now
If you own anything that reads Teams transcripts, do three checks before 29 July:
- Confirm whether the tenant has Microsoft Graph access enabled for transcripts.
- Test whether your app can handle unattributed transcript content if speaker attribution stays off.
- Review whether you really need tenant-wide permissions, or whether a more scoped model is the better long-term fit. If you are unsure, this is exactly the kind of thing worth an automation audit.
This is one of those admin changes where the security story is sensible and the operational risk is very real. My take: enable it only where there is a clear business need, keep speaker attribution off unless you genuinely need it, and make your apps branch on innerError.code instead of assuming every transcript failure is a generic auth problem.
