Microsoft Foundry-agents beheren: Identity-First controle voor hosted agents

Waarom hosted agents een controlepunt nodig hebben

Microsoft Foundry maakt het eenvoudig om een agent op te zetten en naar tools te verwijzen. Het risico is hetzelfde als bij elke krachtige agent: zodra deze een MCP-server met klantgegevens kan aanroepen, moet de vraag "wie deed dat, voor wie, en mocht dat?" beantwoord kunnen worden — en een rechtstreekse agent-naar-server-aanroep beantwoordt daar niets van. Door de MCP gateway in het pad te plaatsen, wordt elke tool-call een beheerde, toegewezen gebeurtenis, wat het hele uitgangspunt is van AI agent governance.

Twee modi: niet-beheerd vs. handelen namens een gebruiker

Welke modus u gebruikt, hangt af van de vraag of er een mens in de loop is:

Hoe de agent wordt gekoppeld aan een TrueFoundry-identiteit

Elke Foundry-agent heeft een Entra-agentidentiteit, beheerd door een agent identity blueprint. U spiegelt deze in de TrueFoundry Agent Registry als een identity-provider-backed entry — hetzelfde registratiepad dat elke extern uitgegeven agent gebruikt:

Entra geeft de identiteit uit; TrueFoundry dwingt het aanroep-pad af. Toegang wordt beheerd door de bekende collaborator grants — welke MCP-servers de agent mag aanroepen en voor welke gebruikers deze mag handelen — het model in enterprise MCP access control.

De Entra-registraties

Drie app-registraties voeren het werk uit, waarvan er twee worden gedeeld door beide modi:

Aan de TrueFoundry-zijde registreert u de MCP-server met Entra-inbound auth en een outbound configuratie van Client Credentials (scope /.default) of JWT Bearer voor on-behalf-of, voegt u vervolgens de agent toe aan de registry en verleent u deze toegang tot de server.

Waar teams de mist in gaan

De tokenversie op 1 laten staan. Stel requestedAccessTokenVersion: 2 in op agent-service, anders vallen de azp- en issuer-claims verkeerd uit en kan de gateway de agent niet oplossen.

Admin consent overslaan. Zonder dit ontbreekt de roles-claim simpelweg en mislukken client-credentials-aanroepen met een insufficient-role-fout.

Een credential opnieuw instellen zonder `--append`. Dit verwijdert bestaande secrets. En preAuthorizedApplications vervangt in plaats van dat het samenvoegt — het opnieuw toevoegen van één entry kan de andere laten vallen.

Scopes met komma's scheiden in Foundry. Scopes zijn daar spatie-gescheiden; client credentials gebruikt /.default, geen benoemde scopes. Kleine syntaxis-fouten hier leiden stroomafwaarts tot audience- of scope-fouten.

Wilt u Foundry-agents via uw MCP-servers routen?

TrueFoundry Gateway

Een uitgewerkt voorbeeld

Een team voert een niet-beheerde Foundry-agent uit die records verrijkt vanaf een interne MCP-server. Ze maken de mcp-api- en agent-service-registraties aan, stellen de app-rol Tool.Invoke beschikbaar op mcp-api, verlenen deze aan agent-service en geven hier admin-consent voor. In Foundry stellen ze de MCP-verbinding in op "Microsoft Entra — agent identity"; in TrueFoundry registreren ze de server met Entra-inbound en client-credentials-outbound (/.default), en voegen ze de agent toe aan de registry. Nu krijgt de agent een identiteitstoken, wisselt de gateway deze uit als agent-service, en ontvangt de MCP-server een zuiver Tool.Invoke-applicatietoken — waarbij het auditspoor van de gateway vastlegt welke agent de aanroep heeft gedaan. Wanneer ze later een gebruikersgerichte stroom toevoegen, voegen ze de on-behalf-of-registraties toe en schakelen ze die verbinding om naar identity passthrough.

Valkuilen om rekening mee te houden

• Foundry-agents voeren hun eigen uitwisseling uit, dus in tegenstelling tot Copilot Studio kan de eigen identiteit van de agent mee reizen met de aanroep — nuttig wanneer u wilt dat de agent stroomafwaarts bij naam wordt genoemd, niet alleen in het gateway-logboek.
• Niet-geregistreerde agents worden geweigerd, dus een agent die niet in de registry staat, kan simpelweg niet doorverbinden — deny-by-default, niet fail-open.
• Veelvoorkomende fouten hebben te maken met claims: missing_token, insufficient_scope, insufficient_role en audience mismatches zijn meestal terug te voeren op tokenversie, toestemming of scope-syntaxis.
• Gecachte tokens na een toestemmingswijziging kunnen een oplossing maskeren — forceer een nieuw token bij het valideren.
• Uitwisseling per hop is in ontwikkeling; controleer bij multi-agent-ketens hoe delegatie is ingericht in uw versie.

Wat de gateway concreet toevoegt

"Leid het via de gateway" is makkelijk gezegd; het is de moeite waard om precies te zijn over wat dat daadwerkelijk oplevert, omdat elk punt een controle is die een rechtstreekse agent-naar-server-aanroep simpelweg niet heeft:

• Authenticatie van de aanroeper en agent-resolutie — het inkomende token wordt geauthenticeerd en aan de hand van de claims gekoppeld aan een geregistreerde agent; een niet-geregistreerde agent wordt geweigerd.
• Tool-scoping per agent — u beperkt welke tools een agent mag aanroepen, niet alleen welke servers, zodat een read-only agent geen write-tool kan bereiken die toevallig op dezelfde server staat.
• Limieten voor gebruikersdelegatie — in de on-behalf-of-modus kan de agent alleen handelen namens gebruikers die de agent toegang hebben verleend, ongeacht wat de gebruiker rechtstreeks zou kunnen bereiken.
• Rate limits en guardrails — toegepast per server of tool, zodat een agent in een lus een stroomafwaarts systeem niet kan uitputten of ongecontroleerd gegevens kan exfiltreren.
• Token-uitwisseling — de gateway genereert het exacte token dat de MCP-server verwacht, zodat de server nooit specifieke Foundry- of Entra-details hoeft te begrijpen.
• Auditattributie per agent — elke aanroep wordt geregistreerd op naam van de agent (en, in OBO-modus, de gebruiker), wat het bewijs is waarnaar een auditor vraagt.

Deze blijven in beide modi op dezelfde manier van kracht; alleen de token-brokering verschilt. Die consistentie is het punt — u denkt één keer na over toegang, en het geldt ongeacht of de agent niet-beheerd draait of namens een persoon.

De installatie, stap voor stap

De documentatie splitst de configuratie op in twee delen: eerst client-credentials, daarna on-behalf-of daar bovenop gebouwd. Client credentials is het kortere pad — ongeveer elf stappen — en het is de moeite waard om dit eerst te doen, zelfs als u uiteindelijk OBO wilt, omdat het de werking bewijst voordat u de gebruikersdimensie toevoegt.

1. Maak de mcp-api- en agent-service-registraties en hun service principals aan.
2. Configureer agent-service met een identifier-URI, tokenversie 2 en een access_as_user-scope.
3. Stel de app-rol Tool.Invoke beschikbaar op mcp-api, verleen deze aan agent-service en geef hier admin-consent voor.
4. Pre-autoriseer de agent blueprint op agent-service als een afzonderlijke aanroep, en maak een credential aan op agent-service met --append.
5. Stel in Foundry de MCP-verbinding in op "Microsoft Entra — agent identity" met audience api:// plus het agent-service-ID.
6. Registreer in TrueFoundry de MCP-server met Entra-inbound en "OAuth2 → Microsoft Entra → Client Credentials" outbound (scope /.default), en voeg vervolgens de agent toe aan de registry.

On-behalf-of (deel twee) bouwt daarop voort: voeg een gedelegeerde Tool.Write-scope toe op mcp-api, maak de agent-client-registratie aan met access_as_user en offline_access, pre-autoriseer agent-client op agent-service (toegevoegd, niet vervangen), stel de Foundry-verbinding in op "OAuth identity passthrough → custom OAuth", en schakel de TrueFoundry outbound-configuratie om naar "JWT Bearer".

Problemen met veelvoorkomende fouten oplossen

Vrijwel elke fout hier heeft te maken met claims — de aanroep wordt geweigerd omdat een token is gegenereerd met de verkeerde versie, audience of scope. De oplossingen zijn specifiek:

Nog een punt dat een juiste oplossing kan maskeren: na het wijzigen van de toestemming kan een gecached token blijven mislukken — forceer een nieuw token voordat u concludeert dat de configuratie onjuist is. Als de gateway weigert vanwege een mismatch in het registry subject, controleer dan of het registry subject overeenkomt met het agent identity object ID (client credentials) of het agent-client application ID op azp (on-behalf-of).

Gerelateerde artikelen

• Agent Identity en On-Behalf-Of-delegatie — het onderliggende delegatiemodel
• Microsoft Copilot Studio-agents beheren — de no-code variant
• Wat is een MCP Gateway? — het beheren van tool-calls
• Enterprise MCP Access Control — de bevoegdheden achter elke aanroep
• AI Agent Governance — de vijf pijlers waar dit in past

Conclusie

Foundry maakt het eenvoudig om agents te bouwen; de gateway zorgt ervoor dat ze veilig draaien. Door de TrueFoundry MCP Gateway in het pad te plaatsen, krijgen de tool-calls van een Foundry-agent een door Entra uitgegeven identiteit, een door TrueFoundry afgedwongen beslissing, de juiste token-uitwisseling voor de MCP-server en een auditregel waarin de agent wordt genoemd — en in de on-behalf-of-modus ook de gebruiker. Client credentials heeft betrekking op niet-beheerd werk; on-behalf-of omvat het handelen namens een persoon. Niet-geregistreerde agents komen er simpelweg niet doorheen.

Dat is het verschil tussen een hosted agent die uw systemen kan bereiken en een agent die ze bereikt onder governance.

Beheer de tool-calls van elke Foundry-agent.

Plan een demo