Purview kan Claude Code tegenhouden bij het lezen van je gelabelde bestanden

Eerder beschreef ik de Microsoft Purview-connector voor Anthropic Claude en betoogde ik dat de 9 kruisjes ❌ de beperkingen van één integratie beschrijven, niet de beperkingen van Purview. Dit artikel duikt in de controle die Purview daadwerkelijk over Claude heeft.

Wanneer we in het connector-overzicht “not supported” lezen, interpreteren we dat al snel als “Purview kan deze aspecten binnen Claude wel zien, maar niet controleren”, en uiteindelijk denkt iemand dan dat er een ander product nodig is om dat gat te dichten. Die redenering kan voor sommige organisaties kloppen, maar voor de meeste is hij om één specifieke reden onjuist: de DSPM-capability-tabel beschrijft een connector, en sommigen behandelen die tabel alsof hij Purview zelf beschrijft. De meeste controles die we hier bespreken bestaan al jaren.

Hieronder een overzicht van het type architectuur dat we gaan verkennen.

Laten we per laag bekijken wat deze voor Claude betekent.

1. Identiteit: Entra SSO, SCIM, Conditional Access die een compliant device vereist

2. Endpoint: Endpoint DLP restricted app groups die Claude-processen blokkeren bij het openen van gevoelige bestanden, plus via MDM uitgerolde managed settings

3. Netwerk: SSE of SASE die Purview Network Data Security voedt. Bestemmingsbeheer (destination governance) over elk oppervlak, inclusief de Claude CLI

4. Connector: Compliance API naar DSPM for AI. Alleen zichtbaarheid, zoals ik in mijn vorige artikel beschreef.

5. Agent-telemetrie: OpenTelemetry vanuit Cowork en Claude naar je SIEM. Gedetailleerd, real-time, en standaard uitgeschakeld tot iemand het aanzet.

Laag 4, de connector, is de laag die in mei live ging en de enige waarover ik in deel 1 schreef. Laag 2 is de laag die daadwerkelijk dingen tegenhoudt.

Zonder twijfel de belangrijkste laag, want alles daarna rust hierop. Identiteit is en blijft de basis van ons control plane, en staat daarom bovenaan, ook al is het niet de laag waar iemand enthousiast van wordt. Op E7 is deze laag ook het meest volledige deel van je hele omgeving, omdat de Frontier Suite de Entra Suite en Agent 365 native meelevert, en juist die twee onderdelen maken identiteit van een puur menselijke controle tot een agent-bewuste controle.

Entra SSO naar Claude Enterprise, SCIM voor joiner-mover-leaver, en een Conditional Access-beleid dat een compliant device vereist. Die combinatie garandeert dat je managed settings het apparaat bereiken, dat je endpoint-telemetrie blijft stromen, en dat elke interactieve Claude-sessie start vanaf een apparaat dat je zelf beheert. Krijg je dit goed voor elkaar, dan heeft de rest van de architectuur ergens om op te staan. Er zijn twee gaten in deze menselijke helft die vaak over het hoofd worden gezien:

1. API-keys omzeilen Conditional Access volledig, omdat een bearer token geen interactieve aanmelding met zich meedraagt waarop CA kan evalueren. Een engineer met een Console-key draait Claude Code vanaf een privélaptop, en je identiteitslaag ziet dat nooit. Dit sluit je in de Anthropic Console, niet in Entra: beperk wie sleutels mag aanmaken en zet een alert op key-creation events, die de Activity Feed van de connector al bevat.

2. Conditional Access grijpt niet in op het consumentenproduct. Domeinverificatie stopt een werkaccount op jouw domein. Het stopt geen persoonlijk Pro-abonnement op een Gmail-adres, geopend op een bedrijfslaptop. Dat lek sluit je op het netwerkvlak, laag 3.

Wanneer een autonome agent handelt in plaats van een mens, is de vraag wiens identiteit die agent draagt en welk beleid daarop van toepassing is. Agent 365, inbegrepen in ME7, is het antwoord van Microsoft, en een oprecht goed antwoord. Het geeft elke agent een eersteklas Entra Agent ID, gebouwd op service-principal-infrastructuur, houdt één register bij van elke agent in de tenant ongeacht waar die is gebouwd, en laat je Conditional Access voor agents toepassen die elke autorisatie-aanvraag van een agent beoordeelt voordat verbinding wordt gemaakt.

Het AI Security Dashboard correleert vervolgens signalen uit Entra, Purview en Defender tot één risicobeeld, en het voorbeeld dat Microsoft zelf uitwerkt is de moeite van het onthouden waard: één DLP-overtreding triggert Purview om de data-toegang te blokkeren, én Agent 365 via Entra om de aanroep van de agent te blokkeren, waarna het dashboard de verlaagde risicoscore weergeeft. Twee handhavingspunten, één gecoördineerde reactie. Dat is het control plane waar deze hele architectuur naartoe wil rapporteren.

Twee eerlijke beperkingen, ook op E7. Conditional Access voor agents is bewust smal vandaag: de enige voorwaarde is het agent-risiconiveau uit Entra ID Protection, en de enige grant control is Block. Het is een noodstop voor risicovolle agents, niet de conditionele beleidssuite die je voor mensen hebt. En netwerkcontroles specifiek voor agents vereisen Entra Internet Access, waarbij device compliance voor agents alleen geldt wanneer de agent draait op een managed endpoint, zoals een Windows 365 Cloud PC for Agents. Agent 365 orkestreert dus bestaande handhaving, het vervangt de endpoint- en netwerklaag daaronder niet. Purview stopt nog steeds de data. Agent 365 stopt de agent.

Voorlopig hebben AI-oplossingen nog altijd een endpoint nodig, en zolang we het over bedrijfsbeheerde endpoints hebben, zijn er veel controles beschikbaar. Laten we er een paar uitlichten.

Dit is de meest substantiële controle die de meeste organisaties vandaag al beschikbaar hebben. Purview Endpoint DLP laat je een proces identificeren op executable-naam en voorkomt vervolgens dat dat proces bestanden opent die aan een DLP-voorwaarde voldoen. Niet de browser, niet een clouddienst, maar de executable zelf. Dit heeft niets te maken met de connector, niets met DSPM for AI, en werkt ongeacht of je de connector-integratie hebt gebouwd.

De configuratie bestaat uit twee stappen:

1. Definieer de restricted app group. Voeg in de Purview-portal de app toe met een herkenbare naam en de executable-naam, die exact moet overeenkomen met de procesnaam. Denk aan zowel Windows- als macOS-gebruikers.

2. Verwijs naar de group in een DLP-regel. Maak een “Devices”-DLP-beleid en stel je voorwaarde in: een sensitivity label of een Sensitive Information Type. Kies bij acties voor audit of restrict activities on devices, en configureer daarbinnen de bestandsactiviteiten voor apps in restricted app groups. Zet de actie, afhankelijk van het gewenste beheersniveau, op Audit, Block with Override, of Block.

Het resultaat: zodra het proces probeert een bestand te openen dat aan de voorwaarde voldoet, houdt Endpoint DLP dit tegen en komt de gebeurtenis terecht in Activity Explorer.

Restricted app groups beheren bestandstoegang. Ze zitten tussen een proces en het bestandssysteem. Ze zien niet wat een developer intypt in Claude Code. Ze zien niet wat er in de desktop-app wordt geplakt. Ze inspecteren niet wat het proces over de lijn verzendt. Getypte en programmatisch verzonden inhoud vanuit een CLI is onzichtbaar voor Endpoint DLP, en geen enkele configuratie verandert dat.

Restricted app groups stoppen een agent die autonoom beschermde bestanden leest. Claude Code kan het salarisoverzicht niet openen, kan het gelabelde contract niet lezen, kan de klantexport die in de repository staat niet inlezen. Dat is een reële en substantiële controle, en die adresseert specifiek het agentische risico: een autonoom proces met brede toegang tot het bestandssysteem, dat alles opzuigt wat in zijn werkmap staat.

Wat het niet tegenhoudt, is een mens die besluit de inhoud van dat spreadsheet in een prompt te plakken. Dat is een ander soort dreiging, op een ander vlak, en die landt bij de browser- en netwerkcontroles die we straks bespreken.

Mijn advies: begin alleen in Audit, met de group gedefinieerd en zonder te blokkeren. Twee weken data uit Activity Explorer leren je meer over wat Claude Code leest dan welk beleidsontwerp dan ook. Ga daarna naar Block with override op gelabelde inhoud, en pas daarna naar Block. Dit is hetzelfde volwassenheidspad dat je voor elke restricted app group zou volgen, en Claude verdient geen ander traject.

Twee ontwikkelingen om in de gaten te houden voor de toekomst:

1. Restricted app groups zijn sinds april 2025 afdwingbaar in Edge, waardoor dezelfde group nu zowel een lokaal proces als een browser die een beschermd bestand benadert kan beheren. Die samensmelting is de richting waarin dit zich ontwikkelt: minder losse controle-oppervlakken, meer app-onafhankelijk beleid.

2. Advanced label-based protection op onboarded Windows-devices blijft toegangscontrole afdwingen op gelabelde bestanden, ook wanneer die onversleuteld op de schijf staan, en versleutelt ze bij overdracht van het apparaat af. Voor een agent die by design lokale bestanden leest, is dat de duurzamere controle dan welke per-app-blocklist dan ook, omdat je niet elke AI-executable die volgend jaar bestaat hoeft op te sommen. Bouw je voor een horizon van drie jaar in plaats van drie maanden, investeer daar dan in.

Waar we gewend zijn binnen onze Office-productiviteitssuite met M365 Copilot te werken, heeft Anthropic ook eigen Office-add-ins gelanceerd. Ze zijn een beetje een rare eend in de bijt, want ze vallen blijkbaar buiten de Claude Enterprise-auditlogs en de Compliance API. Observability is hier een reëel gat, maar gelukkig kunnen we de uitrol wel beheersen.

De uitrolcontrole zelf is eenvoudig. Binnen Integrated Apps in het M365 Admin Center bepaalt de beheerder wie welke applicatie mag gebruiken. Daarnaast kun je gebruikers ook verhinderen add-ins uit de Office Apps Store te betrekken. Rol alleen uit wat je hebt goedgekeurd, en de Claude-add-ins staan simpelweg niet op je beheerde clients.

Toch blijf je monitoring nodig hebben, niet voor de uitrol zelf, maar om gebruikers te identificeren die proberen je controles te omzeilen. Het blokkeren van de add-in in het admin center beheert het beheerde oppervlak van je tenant. Het beheert niet een gebruiker die de add-in sideload.

Defender for Cloud Apps zal de Anthropic API-endpoints laten zien in app discovery. Insider Risk Management heeft precies hiervoor een beleidsvorm, namelijk gebruikers die beveiligingscontroles omzeilen, en het is een van de weinige Purview-oplossingen die vandaag al op Claude werkt, omdat het opereert op je endpoint-signalen in plaats van op de connector.

Purview Network Data Security werkt via een SASE- of SSE-integratie en is de enige route die Microsoft documenteert als bereikbaar voor AI-interacties over browsers, applicaties, API’s en add-ins heen. Claude wordt daarbij expliciet genoemd.

Lees de toepassingen nauwkeurig. Het browservlak, ofwel device-onboarding plus de Purview-extensie, observeert alleen een browser. De Claude desktop-app is geen browser, en Claude Code ook niet. Juist waar engineers de zwaarste Claude-gebruikers zijn, en dat zijn ze meestal, kijken browsergebaseerde controles naar een lege kamer.

Bestemmingsbeheer werkt overal. Toestaan, blokkeren of coachen op de FQDN. Maak onderscheid tussen je Enterprise-tenant en de consumenten-claude.ai, waarbij de leverancier tenant-restriction-headers ondersteunt. Dit werkt voor de browser, de desktop-app, de CLI en de add-ins tegelijk, omdat het opereert op waar het verkeer naartoe gaat in plaats van wat erin zit. Zet dit neer en je hebt discovery en bestemmingscontrole over elk oppervlak in je omgeving.

Inhoudsinspectie verzwakt sterk. In een browser is dit werkbaar. Op native clients loopt het van best-effort tot onhaalbaar, om drie redenen die elkaar versterken. Prompts worden in stukjes verzonden en gestreamd in plaats van als één inspecteerbaar bericht. De transportlagen zijn server-sent events en websockets, geen nette request-response. En native clients passen steeds vaker certificate pinning toe, wat de TLS-interceptie waarop je SSE leunt, tenietdoet.

Zowel Claude Code als de desktop-app lopen over api.anthropic.com en claude.ai. Valideer het pinning-gedrag in je eigen SSE voordat je iemand inline content-DLP belooft op die oppervlakken. Dat is het verschil tussen een architectuur die haar eerste pilot overleeft en een die stilletjes wordt losgelaten.

Het netwerkvlak geeft je discovery en bestemmingsbeheer voor elk oppervlak, inclusief de CLI. Content-inspectie-DLP is werkbaar in de browser en op zijn best best-effort op native clients.

Er is hier ook een one-click beleid, wat de moeite waard is om te weten, gezien de connector-laag daar voor Claude niets voor heeft. DSPM for AI - Detect sensitive info shared with AI via network voedt netwerk-gedetecteerde bevindingen in dezelfde Activity Explorer-weergave. Het is leveranciersonafhankelijk, dus het bereikt ook Claude.

Het netwerkvlak is ook een van de weinige, zo niet de enige, controles die een add-in opvangt die je niet hebt weten te blokkeren. De voorwaarde: het vereist E5 en pay-as-you-go. De meeste Enterprise-organisaties hebben dit in een of andere vorm al staan, en met goede reden.

Cowork zit niet in de Compliance API. Anthropic stelt dat expliciet, dus de Purview-connector zal het nooit zien, en geen enkele licentie verandert dat. Toch is Cowork niet volledig donker. De monitoringdocumentatie van Anthropic beschrijft een eersteklas OpenTelemetry-export, beschikbaar op Team en Enterprise, centraal te configureren door een beheerder. Een OTLP-endpoint, een protocol, een auth-header. Zodra dat staat, stromen gebeurtenissen direct binnen.

De logging is substantieel: de volledige tekst van elke prompt; elke tool- en MCP-aanroep met servernaam, toolnaam, parameters, succes of falen en uitvoeringstijd; elk bestandspad dat Claude leest, wijzigt of aanraakt, inclusief bestanden die via MCP-servers worden bereikt; welke skills en plugins zijn aangeroepen; of elke tool-actie door de gebruiker is goedgekeurd, afgewezen, of automatisch is uitgevoerd onder bestaande permissies; en per verzoek het model, tokenaantallen, geschatte kosten en duur. Een gedeelde prompt.id koppelt elke gebeurtenis terug aan de prompt die hem veroorzaakte, zodat je kunt reconstrueren wat de agent deed in reactie op één enkele instructie.

Dat is een gedetailleerder forensisch beeld dan de Compliance API biedt voor claude.ai, waar de activity feed geen enkele prompt-inhoud bevat. Het probleem van Cowork is dus niet afwezigheid van data. Het zijn drie andere zaken.

• Het staat uit totdat een beheerder het aanzet. Anthropic is expliciet: er stroomt geen data totdat een OTLP-endpoint is geconfigureerd. Niet minder data, geen data. Een organisatie die dat veld nooit heeft ingesteld, heeft niets en kan dat achteraf niet alsnog verkrijgen.

• Het gaat naar je SIEM, niet naar Purview. Daarmee valt het buiten DSPM, buiten DLP, buiten eDiscovery en buiten elk Purview-retentiebeleid. Je Claude-bewijsmateriaal leeft in twee tools met twee eigenaren.

• Het is operationele telemetrie, geen auditbewijs. Een real-time gebeurtenisstroom is gebouwd voor onderzoek, niet om over twee jaar een manipulatiebestendig record op te leveren. Vandaar het immutable archive in de build-volgorde.

Anthropic beschrijft ook zelf de koppeling die je zou moeten bouwen: elke Cowork OTel-gebeurtenis draagt een “shared user account identifier” die overeenkomt met Compliance API-records. Correleer daarop en je krijgt het control plane en het operationele vlak in één beeld. Dat is de bedoelde architectuur, en die is het bouwen waard.

Dat Cowork’s telemetrie zo rijk is, is precies waarom er eerst een gesprek nodig is voordat er een collector wordt aangesloten. Anthropic vermeldt alle drie de volgende punten onder security considerations op dezelfde pagina, en niemand leest security considerations voordat hij een OTLP-endpoint aansluit.

• Prompt-inhoud wordt standaard meegenomen zodra export aanstaat. Claude Code doet het tegenovergestelde en redigeert prompts tenzij je er expliciet voor kiest, dus het mentale model dat de meeste beheerders hanteren, namelijk dat telemetrie gelijkstaat aan metadata, klopt hier niet.

• Tool-parameters kunnen gevoelige waarden bevatten, inclusief bestandspaden en command-argumenten.

• E-mailadressen van gebruikers staan in de event-attributen.

Een beheerder die het OTLP-endpoint aanzet voor kostendashboards, is daarmee ook begonnen met het streamen van de volledige tekst van alles wat medewerkers in Cowork hebben getypt. Dit heeft een privacydimensie, en verdient een gesprek met je ondernemingsraad en FG voordat je het aanzet.

Alles in laag 2 en laag 5 draait om het configureren van medewerkersapparatuur en het verzamelen van wat mensen typen. In Nederland is dat geen IT-beslissing. Het aanzetten van prompt-logging kan worden gezien als een personeelsvolgsysteem.

Het is belangrijk om het streamen van je Claude Code-prompts en bijbehorende gesprekken duidelijk los te zien van Purview, omdat het de juridische analyse verandert. Purview’s Endpoint DLP restricted app groups zijn een gegevensbeschermingscontrole, geen gedragscontrole. Ze beoordelen de classificatie van een bestand, niet het gedrag van een medewerker, en ze grijpen in op het moment van toegang. Dat is een aanmerkelijk makkelijker gesprek met een ondernemingsraad dan telemetrie, en dat is nog een reden om met laag 2 te beginnen in plaats van met laag 5.

Mijn advies: voer eerst de DPIA uit voordat je gaat bouwen. Leg een concreet voorstel voor aan de ondernemingsraad: wat wordt verzameld, wat wordt geredigeerd, wie mag het bevragen, hoe lang wordt het bewaard, en hoe is de structurele scheiding tussen securitytelemetrie en alles wat HR kan inzien geregeld. Redigeer bij de collector, niet achteraf bij opslag, want een belofte om niet te kijken is geen controle.

Wat mensen uit de aankondiging van mei meenamen, was dat Purview nu Claude ondersteunt. Vervolgens keken ze naar de capability-matrix en zagen een tegenstelling: Purview kan Claude wel zien, maar zou het blijkbaar niet kunnen beheersen.

Die conclusie mist het grotere plaatje.

Purview kan Claude wel degelijk beheersen, alleen niet primair via een dedicated connector. Endpoint DLP en restricted app groups kunnen voorkomen dat de Claude desktop-app bij gelabelde inhoud kan. Het M365 Admin Center bepaalt of Claude-add-ins mogen worden uitgerold. Network Data Security beheerst waar prompts en antwoorden naartoe mogen worden verzonden. Insider Risk kan gebruikers identificeren die proberen deze controles te omzeilen. Geen van deze controles maakt het uit of de applicatie Claude heet, Copilot, ChatGPT, of iets dat nog niet bestaat. Die onverschilligheid is precies het punt. Controles die aan data, identiteit, apparaten en netwerken zijn gekoppeld, overleven veranderingen in AI-tooling.

Het is ook goed om het perspectief van de bredere markt in het oog te houden. De Purview-connector van OpenAI dekt Codex CLI evenmin. Codex werkt via het API-platform in plaats van via de ChatGPT Enterprise-werkruimte, waardoor het buiten het bereik valt waarvoor de connector is ontworpen. Datzelfde patroon zien we breder in de markt ontstaan. De meeste compliance-integraties zijn gebouwd rond enterprise-chatervaringen, terwijl de nieuwste generatie agentische oplossingen steeds vaker buiten die grenzen opereert.

Dit is geen Claude-probleem. Het is geen Microsoft-probleem. Het is een weerspiegeling van waar governance-integraties oorspronkelijk zijn gebouwd, en van waar AI-producten zich naartoe ontwikkelen. Claude maakt het gat alleen zichtbaarder, omdat Anthropic agressief is geweest in het uitbrengen van agent-ervaringen. Naarmate andere leveranciers hun eigen agent-platforms uitbreiden, zullen dezelfde vragen elders opduiken.

De negen kruisjes van de connector beschrijven de beperkingen van één integratie. Ze beschrijven niet de beperkingen van je control-omgeving. Dat is een belangrijk onderscheid, want het vermogen van een organisatie om AI te beheersen hangt veel meer af van data-, identiteits-, apparaat- en netwerkcontroles dan van de vraag of de connector van één specifieke leverancier een groen vinkje heeft in één bepaalde kolom.