Microsoft Foundry monitoring: tracing, RBAC en evals voor agents

Microsoft Foundry monitoring begint niet met een dashboard. Begin met de vraag welke gegevens je werkelijk nodig hebt om een agent te begrijpen, wie ze mag lezen en wanneer een trace te gevoelig is om te bewaren. Pas daarna is tracing via Foundry, OpenTelemetry en Application Insights nuttig.

Voor een eerste veilige inrichting heb je vijf grenzen nodig: een klein tracecontract, redactieregels, beperkte rollen, een korte bewaartermijn en een eval die een onveilige wijziging blokkeert. Deze tutorial is een neutrale demo, geen beschrijving van een klantomgeving of persoonlijk uitgevoerde Azure-implementatie.

Waarom een agenttrace anders is dan gewone applicatielogging

Een traditionele servicelog bevat vaak een route, statuscode en duur. Een agenttrace kan daarnaast een conversation, modelstappen, toolcalls, tussenresultaten en mogelijk klantinhoud bevatten. Dat maakt debugging rijker én gevoeliger.

Microsofts tracinghandleiding beschrijft server-side tracing in de Foundry-portal en client-side tracing met de SDK en OpenTelemetry. Server-side tracing kan prompts, toolargumenten en resultaten vastleggen; kies die route dus pas nadat de datagrens en toegang zijn ingericht. De trace is geen audit van je privacy- of autorisatieontwerp.

Het mentale model: meten is een ontwerpkeuze

Maak onderscheid tussen deze lagen:

Microsoft waarschuwt dat tracegegevens klantinhoud kunnen bevatten. “We zetten tracing aan” is dus geen dataminimalisatieplan. Leg vooraf vast welke velden worden vastgelegd, welke worden geredigeerd en wie ze kan raadplegen.

Stap 1: definieer een klein tracecontract

Start met gegevens die een storing of regressie kunnen uitleggen zonder standaard de inhoud van een gesprek te bewaren:

run_id_hash, agent_version, prompt_version, model_id,
tool_class, tool_authorized, outcome_class, error_class,
latency_ms, token_band, eval_case_id, release_gate

Gebruik run_id_hash als correlatiepunt, niet een e-mailadres of volledig conversation-ID. Groepeer tokens in banden wanneer een exact getal niet nodig is. Leg inhoudelijke capture achter een afzonderlijke, tijdelijke debugroute met expliciete toegang.

Een bruikbare redactieregel in een demo is simpel: e-mailadressen, bearer-tokens, API-sleutels en complete toolargumenten worden vóór export gemaskeerd. Redactie achteraf is zwakker, omdat de ruwe inhoud dan al in de observability-opslag kan staan.

Stap 2: kies server-side of client-side tracing bewust

Foundry kan server-side traces voor ondersteunde agent- en workflowscenario's tonen. Client-side tracing is nuttig wanneer je eigen code, SDK-calls of een andere agentframeworklaag wilt instrumenteren. Microsoft koppelt die route aan OpenTelemetry en Application Insights.

Een minimale, conceptuele configuratie houdt het projectendpoint buiten de broncode:

# demo: gebruik managed identity en beheerde configuratie; geen secret of endpoint in broncode
import os
from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient

project = AIProjectClient(
    credential=DefaultAzureCredential(),
    endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
)

# Instrumenteer alleen de lagen die je in het tracecontract hebt toegestaan.
# Controleer actuele SDK- en previewdetails in de Microsoft-documentatie.

Dit is geen kopieerklare productieconfiguratie. De veilige default is dat identity en endpoint via beheerde configuratie komen, dat de gebruikte principal zo weinig mogelijk rechten heeft en dat je SDK-versie op de publicatiedag opnieuw wordt gecontroleerd.

Koppel Application Insights pas nadat je testdata en redactieregels werken. Anders maak je een groot, moeilijk op te ruimen spoor van onnodige inhoud.

Stap 3: scheid ontwikkelaar, operator en auditor met RBAC

Een developer die aan prompts werkt, hoeft niet alle productieconversaties te lezen. Een operator die incidenten onderzoekt, hoeft niet automatisch deploymentrechten te hebben. Ontwerp daarom rollen rondom handelingen in plaats van functies of teams.

Microsofts documentatie benoemt Entra-identity en vereiste Azure-rollen voor toegang tot tracing. Gebruik dat als beginpunt, maar toets in je eigen tenant altijd de effectieve toegang. Groepslidmaatschap, inherited rollen en exportrechten kunnen het model breder maken dan de tabel op papier.

Stap 4: verbind observability met een eval-releasegate

Een trace vertelt dat iets gebeurde. Een eval vertelt of het voor een bekende case acceptabel was. Koppel die twee zonder te doen alsof monitoring een test vervangt.

Voor een read-only kennisbankagent kan een kleine gate zijn:

1. De agent haalt de juiste bron op bij een bekende vraag.
2. De agent doet een handoff bij ontbrekende context.
3. Een tooloutput met een injectie-instructie leidt niet tot een extra toolcall.
4. Een tooltimeout levert een geredigeerde trace, foutklasse en veilige reactie op.
5. Geen testcase schrijft data of leest een trace waarvoor de testprincipal geen recht heeft.

Laat een harde safety- of RBAC-fout de release blokkeren. Volg latency en kwaliteit als trends en beoordeel een onverwachte verandering met een steekproef. De Agent Monitoring Dashboard-documentatie noemt evals, red-teamscans en alerts als operationele mogelijkheden; controleer previewstatus en limieten opnieuw voordat je ze als releasevoorwaarde gebruikt.

Stap 5: test de observability zelf

Observability is code en configuratie. Test dus ook de observabilitylaag.

Meet ook het kosten- en prestatierisico. Meer spans, langere retentie en volledige payloads maken onderzoek soms gemakkelijker, maar verhogen opslag, zoekkosten en privacyrisico. Begin met diagnostische metadata. Voeg inhoud alleen tijdelijk toe wanneer het incident niet anders kan worden begrepen.

Veelgemaakte fouten

Alles loggen “voor later”

Dat vergroot de kans dat prompts, persoonsgegevens of gevoelige tooloutput langer dan nodig beschikbaar blijven. Maak het tracecontract klein en een uitzondering expliciet.

Eén brede readerrol voor het hele team

Brede leesrechten veranderen een foutdiagnose in een onnodige datatoegang. Gebruik gescheiden rollen, test effectieve rechten en controleer exports.

Een dashboard verwarren met een releasegate

Een grafiek achteraf voorkomt geen onveilige toolcall. Laat bekende safety-, autorisatie- en regressietests vooraf hard falen.

Previewdocumentatie als vaste productiebelofte behandelen

Foundry- en portalfeatures veranderen. Leg de versie, datum en beperking vast en hercontroleer de primaire documentatie op de publicatiedag.

Besliskader: wanneer is meer tracing verstandig?

Kies voor meer detail wanneer een beperkt incidentonderzoek dat vereist, er een concrete eigenaar is en de bewaartermijn kort is. Kies voor minder wanneer de trace vooral “misschien later nuttig” lijkt of inhoudelijke data bevat die niet voor diagnose nodig is.

Zet eerst een kleine, geredigeerde eval- en traceketen op in een testproject. Voeg daarna server-side tracing, eigen spans en dashboards toe waar ze een duidelijke operationele vraag beantwoorden. Dat sluit aan bij de bredere controlelus uit AI-agenten in productie en bij de keuzes rond LLM-workflows.

Samenvatting

Microsoft Foundry monitoring is waardevol wanneer je tracecontract, redactieregels, RBAC en eval-releasegate samen ontwerpt. Start met minimale metadata, beperkte lezers en harde tests voor ongeoorloofd gedrag. Een dashboard komt pas daarna.

Werk je aan een Azure-agent en wil je tracing, identity en releasecontroles in één ontwerp beoordelen? Bekijk hoe een Azure AI engineer deze architectuurvragen kan helpen structureren. Of neem contact op.