Partea interesantă la Foundry Toolboxes nu este consolidarea endpoint-urilor. Este faptul că Microsoft tratează în sfârșit fluxul de identitate ca pe o problemă de design pentru agenți.
Asta contează pentru că mulți agenți arată bine în demo-uri până când trebuie să facă muncă reală: să apeleze un server MCP protejat cu Entra, să citească context din Microsoft 365 sau să execute o acțiune în numele unui utilizator. Din acel moment, problema nu mai este calitatea promptului. Problema este: ce identitate trece efectiv granița de încredere?
Postarea Foundry este despre exact acest transfer. Modelul este simplu: pui mai multe unelte în spatele unui endpoint Toolbox, iar toolbox-ul gestionează conexiunea și modelul de autentificare pentru fiecare unealtă. În documentația oficială, conexiunile MCP suportă CustomKeys, OAuth2, AgenticIdentityToken și UserEntraToken. Pentru hosted agents, Microsoft cere și rolul Foundry User pe proiect pentru dezvoltator, identitatea agentului și utilizatorul final atunci când sunt implicate fluxuri bazate pe OAuth.
Ce rezolvă de fapt Toolboxes
Ca bloc de construcție, asta este bine gândit. Refolosirea unei suprafețe curate de unelte între agenți este mai bună decât să refaci aceleași legături MCP și API în fiecare proiect. Dacă construiești Microsoft Copilot și AI agents, reduci configurația duplicată și obții o graniță de încredere mai clară.
Cel mai util detaliu este că un toolbox poate expune conexiuni cu stiluri diferite de autentificare. Asta înseamnă că un singur agent poate vorbi cu un MCP server privat și poate apela și unelte orientate spre Microsoft 365, cum este Work IQ, fără ca fiecare autor de agent să reinventeze toată partea de token-uri.
O definiție minimă pentru un MCP tool din documentație arată așa:
{
"description": "MCP server with OAuth/identity auth",
"tools": [
{
"type": "mcp",
"server_label": "myserver",
"server_url": "https://your-mcp-server.example.com",
"project_connection_id": "<OAUTH_OR_IDENTITY_CONNECTION_NAME>"
}
]
}
Iar opțiunile de autentificare din CLI sunt explicite:
| Auth type | Ce înseamnă în practică |
|---|---|
user-entra-token | passthrough al utilizatorului către resursa downstream |
project-managed-identity | identitatea proiectului apelează resursa downstream |
agentic-identity | identitatea agentului apelează resursa downstream |
oauth2 | flux delegat cu consimțământ |
Asta este direcția corectă. Agenții nu ar trebui să amestece aceste cazuri.
Ce aș verifica înainte să îl standardizez
Reacția din comunitate este corectă: centralizarea și reutilizarea există deja, dar partea serioasă de guvernanță încă se construiește. Microsoft însăși a prezentat discoverability și governance ca elemente de roadmap, iar asta contează mai mult decât partea lucioasă din anunț.
În practică, problemele grele rămân aceleași:
- cine poate publica sau modifica un toolbox partajat
- cum auditezi apelurile de tool între agenți
- dacă fluxul delegat de utilizator lărgește în tăcere accesul mai mult decât ai vrut
- cât din acest model rămâne bazat în primul rând pe endpoint-uri publice
Ultimul punct nu este teoretic. Microsoft documentează că hosted Foundry MCP Server nu suportă în prezent network isolation și folosește endpoint-ul public https://mcp.ai.azure.com. Tot Microsoft spune că cererile și răspunsurile pot fi procesate în centre de date din UE sau SUA și că, dacă ai nevoie de procesare strict în regiune, nu ar trebui să folosești această funcție preview. Pentru unele organizații, nu este o problemă. Pentru altele, doar asta scoate scenariul din producție.
Mai există și un detaliu practic pentru OAuth: primul apel poate întoarce CONSENT_REQUIRED cu codul -32006, iar utilizatorul trebuie să finalizeze consimțământul înainte de retry. Dacă construiești custom MCP servers sau automatizări mai largi de tip AI workflow automation, planifică experiența asta de la început, nu o descoperi în pilot.
Părerea mea
Acesta este unul dintre adaosurile mai bune din Foundry pentru că rezolvă un haos real de inginerie, nu doar ambalarea agenților. Centralizarea tool-urilor este utilă. Centralizarea deciziilor de identitate este câștigul mai important.
Eu aș folosi Toolboxes acum pentru compunerea de tool-uri enterprise partajate, dar nu aș confunda asta cu o guvernanță terminată. Dacă ai construit propriul haos de autentificare per agent, aici ai un model mai curat. Dacă ai nevoie de observabilitate serioasă, garanții regionale stricte sau modele exclusiv private, trebuie încă să verifici atent marginile înainte să îl numești standard.
