Controlul Teams pentru accesul API la transcripturi este dezactivat implicit, iar după 29 iulie 2026 acest implicit nu mai este inofensiv. Dacă ai orice aplicație, agent sau integrare care citește transcripturi din meetinguri sau apeluri Teams prin Microsoft Graph, poate începe să pice cu erori 403 dacă un admin Teams nu activează explicit setarea.
Este o schimbare bună. Și este exact genul de schimbare care produce incidente tăcute dacă nu are nimeni ownership.
Topedia a semnalat timeline-ul, iar documentația Microsoft confirmă părțile importante: administratorii de tenant au acum un control separat pentru accesul la transcripturi prin API, plus un control separat pentru speaker attribution. Permisiunile aplicației nu mai sunt toată povestea.
Ce se schimbă?
Acum există două setări la nivel de tenant în Teams admin center, în Meetings și Meeting settings, pentru accesul la transcripturi prin API:
| Setare | Implicit | Ce face |
|---|---|---|
| Microsoft Graph access | Off | Blochează sau permite aplicațiilor și agenților să acceseze transcripturi de meeting prin Graph APIs |
| Include speaker attribution | Off | Controlează dacă transcripturile luate prin Graph includ numele vorbitorilor |
Implicitul acesta contează. Microsoft documentează că atunci când Graph access este off, cererile pentru transcripturi întorc 403 Forbidden cu 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"
}
}
}
Asta se aplică permisiunilor uzuale pentru transcripturi pe care mulți le-au acordat deja, inclusiv OnlineMeetingTranscript.Read.All, OnlineMeetingTranscript.Read.Chat și CallTranscripts.Read.All.
De ce ar trebui să-ți pese ca inginer
Multe fluxuri bazate pe transcripturi Teams au fost construite pe presupunerea că Entra consent plus permisiunile Graph sunt suficiente. Presupunerea asta nu mai este sigură.
Dacă ai construit Microsoft Copilot și AI agents, generatoare de notițe de meeting, exporturi de conformitate, sincronizări CRM sau orice workflow de automatizare care consumă transcripturi, verifică acum. Pentru majoritatea tenanturilor nu există impact vizibil pentru utilizatori în clientul Teams. Generarea transcripturilor, politicile de înregistrare și experiența transcripturilor în Teams nu sunt afectate de această setare. Ruperea apare la nivel de API.
Tocmai această diferență face schimbarea ușor de ratat: utilizatorii încă văd transcripturile în Teams, în timp ce aplicația ta downstream nu le mai vede.
Efectul de ordinul doi: este încă un pas prin care accesul larg la nivel de tenant încetează să mai fie considerat normal. Pentru scheduled private chat meetings, Microsoft suportă deja permisiunea mai restrânsă OnlineMeetingTranscript.Read.Chat prin resource-specific consent. În practică, asta face designul least-privilege mai atractiv și granturile largi la nivel de tenant mai greu de justificat. Pentru date care sunt, literalmente, transcripturi de meeting, era și timpul.
Dar speaker attribution?
Speaker attribution este controlat separat, iar asta mi se pare partea mai interesantă a designului.
Dacă Graph access este permis, dar speaker attribution este off, Microsoft spune că aplicațiile pot totuși să preia transcriptul, dar doar în formatul fără atribuire, folosind headerul Accept application/vnd.microsoft.graph.transcript+text. Dacă aplicația cere text/vtt, primește un alt 403 cu SpeakerAttributionNotAllowed.
Deci nu este doar on sau off. Le permite administratorilor să accepte procesarea bazată pe transcript, dar fără stratul de identitate. Pentru unele organizații, acesta va fi compromisul corect.
Ce aș verifica acum
Dacă deții orice integrare care citește transcripturi Teams, fă trei verificări înainte de 29 iulie:
- Confirmă dacă tenantul are activat Microsoft Graph access pentru transcripturi.
- Testează dacă aplicația ta poate gestiona transcripturi fără speaker attribution dacă acea setare rămâne off.
- Revizuiește dacă ai nevoie cu adevărat de permisiuni la nivel de tenant sau dacă un model mai restrâns este mai potrivit pe termen lung. Dacă nu ești sigur, exact aici ajută un automation audit.
Este una dintre acele schimbări administrative în care partea de securitate este solidă, iar riscul operațional este foarte real. Părerea mea: activează doar unde există o nevoie clară de business, păstrează speaker attribution off dacă nu ai nevoie reală de el și fă aplicațiile să trateze innerError.code explicit, în loc să presupună că orice eșec la transcripturi este doar o problemă generică de autentificare.
