Cel mai bun argument pentru MCP ar putea fi mult mai mic decât hype-ul: să ții autentificarea în afara ferestrei de context a modelului. Sună aproape prea îngust ca să impresioneze, dar cred că Sean Lynch are în mare parte dreptate.
Dacă elimini promisiunile mari despre un strat universal pentru tool-uri, valoarea concretă este securitatea și controlul. Un agent nu ar trebui să primească API keys brute, bearer tokens sau acces larg în tenant direct în prompt sau în harness dacă există o variantă mai curată. Și ghidajul Microsoft pentru MCP merge exact în direcția asta: Foundry suportă project connections pentru autentificare pe bază de cheie, identități Microsoft Entra și OAuth identity passthrough, tocmai ca să nu codifici credențialele în aplicație și ca să poți limita accesul per agent, per proiect sau per utilizator.
Asta este partea pe care aș lua-o în serios. Restul este încă destul de neclar.
De ce este util MCP ca graniță de autentificare?
Câștigul practic nu este „agenții pot apela tool-uri”. Asta exista deja prin skills, plugin-uri, wrappere CLI și API-uri clasice. Schimbarea utilă este că MCP oferă o graniță mai curată pentru intermedierea accesului.
În Microsoft Foundry, de exemplu, autentificarea MCP poate fi configurată printr-un project connection, iar require_approval are implicit valoarea always. Detaliul ăsta contează. Înseamnă că platforma pornește de la premisa corectă: folosirea tool-urilor este riscantă până când decizi explicit altceva. Pentru echipe care construiesc Microsoft Copilot și AI agents, acesta este un punct de plecare mult mai sănătos decât să împingi secretele în codul de orchestrare și să speri că nu ajung în loguri.
Mai este un detaliu important din documentația Microsoft: cu OAuth identity passthrough, consimțământul este per utilizator și per conexiune de tool, iar Foundry blochează trimiterea token-urilor Microsoft către endpoint-uri MCP custom sau third-party neîncrezute. Foarte bine. Un agent nu ar trebui să primească un cec în alb în tenant doar pentru că cineva a conectat un nou server interesant.
Care este limita?
MCP nu rezolvă magic supra-permisionarea. Doar îți oferă un loc mai bun în care să o rezolvi.
Dacă atașezi un service principal prost delimitat, o managed identity cu privilegii mari sau un project connection cu acces prea larg, MCP poate deveni în continuare un mecanism foarte ordonat pentru decizii slabe de securitate. Protocolul nu este guardrail-ul; modelul tău de identitate este.
De aceea mă interesează mai mult MCP servers custom, înguste și politici explicite de aprobare decât demo-uri mari de tipul „conectează tot”. În practică, cel mai bun server MCP este adesea un broker subțire peste un set mic de acțiuni construite pentru un scop clar. Ideea lui Sean că „forma idealizată a MCP este doar un auth gateway” funcționează tocmai pentru că majoritatea organizațiilor enterprise nu au nevoie de mai multă autonomie pentru agenți. Au nevoie de limitare mai bună.
Ce aș reține
Verdictul meu este simplu: acesta este modelul mental corect.
Tratează MCP în primul rând ca un pattern de securitate și autorizare, nu ca o poveste grandioasă de unificare a tool-urilor AI. Dacă te ajută să scoți credențialele din prompturi, să aplici consimțământ per utilizator, să folosești least privilege și să adaugi aprobare unde trebuie, este util. Dacă devine încă un strat de abstracție care ascunde permisiuni largi și ownership neclar, este mai slab decât un API direct.
Pentru echipe care construiesc workflows de automatizare, diferența asta contează. Efectul de ordinul doi este guvernanța: odată ce autentificarea este centralizată, o poți audita, o poți roti și poți înțelege cine a aprobat ce. Asta este mult mai valoros decât încă un demo în care un model apasă prin cinci sisteme.
Deci da, MCP este promițător. Dar mai ales pentru că poate fi plictisitor.
