TL; DR;
Vorige week zette Microsoft een team van securityagents in de Defender-portal. Zes agents: rood brengt de toegangswegen in kaart, blauw onderzoekt, groen bepaalt de volgorde van wat je moet oplossen. Afgerekend in Security Compute Units, elk met een eigen Entra Agent ID.
Vrijwel niets van die capaciteit is volledig nieuw. Security Copilot was al goed in blauw. Rood kon je al voor je zien bovenop Defender EASM en Threat Intelligence. Wat wel nieuw is: de orkestratielaag, de gedeelde securitycontext, en het feit dat Microsoft securitywerk neerzet als gecoördineerde agentic arbeid in plaats van losse assistent-prompts. En we krijgen er het plezier van kleurcodering bij.
Microsoft beschrijft Project Perception als een closed-loop systeem: rood vindt exposure, blauw onderzoekt, groen prioriteert en hardent. Maar vandaag stopt die loop nog precies daar waar de meeste securityprogramma’s al vastlopen: bij de overdracht van security naar engineering. Een finding wordt een rapport. Misschien een ticket. Misschien een backlog-item. Misschien iets waarvan iedereen vindt dat het belangrijk is, totdat de volgende sprint planning het stilletjes begraaft.
Mijn inschatting: Project Perception krijgt uiteindelijk een GitHub- en Azure DevOps-oppervlak. Het zichtbare signaal wordt een playbook dat eindigt in een branch, een pull request of een infrastructure-as-code-wijziging in plaats van een markdown-rapport. Maar het grotere verhaal is niet “securityagents gaan code schrijven”. Het grotere verhaal is dat Microsoft een gegoverneerde actielaag bouwt voor enterprise agents, en dat Project Perception de plek is waar die laag security-kritisch wordt.
De pull request is simpelweg de makkelijkst zichtbare actuator.
In juni gaf ik de openingskeynote op EPN CyberSEC Netherlands in Amsterdam, titled Securing the AI-First Enterprise: why Agentic AI demands Agentic Cybersecurity. Het argument paste op één slide. AI comprimeert de tijdlijn van de aanvaller. Time to breach, time to exploit, time to exfiltrate, allemaal dalend. Jouw responsvenster krimpt met exact hetzelfde bedrag. Om je te verdedigen tegen tegenstanders op machinesnelheid heb je verdedigers op machinesnelheid nodig. Ik verwachtte dat ik dat argument nog een jaar lang aan bestuurskamers zou moeten uitleggen. Zes weken later levert Microsoft Project Perception.
En toen keek ik naar de kleuren...
Hayete Gallot, EVP of Microsoft Security, opende de aankondiging met een zin die het onthouden waard is.
The physics of cybersecurity are changing
Haal de marketingtaal eraf en de claim houdt stand: de kosten van AI-gedreven aanvallen zijn hard gedaald. Verdediging werd niet in hetzelfde tempo goedkoper. Iets moet dat verschil opvangen, en dat ging nooit headcount worden. Zoals we hebben gezien in openbare rapportages en publicaties van OpenAI, Anthropic en Meta, AI is op meerdere manieren bijzonder capabel. Niet al die manieren zijn comfortabel voor mensen in het cybersecurityvak.
Microsofts antwoord is een gecoördineerd team van agents. Zes bij de start. Eén rood, vier blauw, één groen.
De Recon Agent verkent als een aanvaller: aanvalspaden, choke points, waardevolle assets, overmatige permissies. Read-only, en alleen Azure.
De blauwe bank draagt het meeste gewicht. Triage bepaalt of een alert echt is. Threat Intelligence haalt TTP’s en IOC’s uit een artikel. Attack Investigation reconstrueert het verhaal achter een incident. Detection Authoring schrijft de KQL om het gat te dichten dat het vindt.
Groen heeft precies één agent: Posture Prioritization, die findings rangschikt op exploiteerbaarheid, bereikbaarheid vanaf internet en assetkriticaliteit.
Zes playbooks koppelen ze aan elkaar. Degene die het bestuderen waard is, is Protect against a threat: die neemt een threat intelligence-bron, draait Threat Intelligence, dan Recon, dan Posture Prioritization, dan Detection Authoring, en voert de output van elke agent door naar de volgende.
Dát is het interessante deel, niet de individuele agents. Het gaat om de workflow. Microsoft zet niet gewoon Copilot-vormige hulpjes naast analisten. Het verandert securitywerk in een georkestreerde keten waarin de output van de ene agent de input van de volgende wordt. Dat is de productzet. De keten stopt alleen nog steeds vóór het systeem verandert.
Microsofts eigen taal rond Project Perception wijst op een closed-loop systeem. Rode agents leggen risico bloot. Blauwe agents onderzoeken. Groene agents remediëren en hardenen. Findings horen fixes te worden zonder een overdracht bij elke stap.
Dat is de juiste ambitie. Maar een finding wordt pas een fix wanneer er iets verandert.
Een detectieregel verandert. Een Conditional Access-policy verandert. Een Defender-configuratie verandert. Een kwetsbare library wordt gepatcht. Een secret wordt geroteerd. Een infrastructure-as-code-bestand verandert. Er verschijnt een pull request.
Vandaag is de zichtbaarste groene capaciteit posture prioritization. Nuttig, en een echte verbetering ten opzichte van een platte kwetsbaarhedenlijst. Maar prioriteren is geen remediëren. De wachtrij ordenen maakt de wachtrij niet leeg. Uitleggen waarom iets ertoe doet, verandert niet het systeem dat het liet ontstaan.
Dat is waar het echt interessant wordt. Project Perception is niet interessant omdat Microsoft securityagents heeft geleverd; het is interessant dat Microsoft security stilletjes verschuift van problemen vinden naar systemen veranderen.
De kleurcodes zijn het waard om goed te krijgen, want Microsoft koos er drie en die keuze zegt iets.
Rood is niet preventief. Dat is de meest voorkomende misvatting. Rood simuleert een echte tegenstander. Traditionele pentesters zijn er niet om elk gat te vinden, ze zijn er om te bewijzen dat ze binnen kunnen komen en onder de radar kunnen blijven. Meestal weet het SOC niet dat ze eraan komen, en dat is nu juist het punt. Als je de test aankondigt, vertel je iemand dat je dinsdag langskomt om te controleren. Dan zorgen ze dat op maandag alles piekfijn in orde is. Je leert er minder van dan je denkt.
Blauw is detectie, monitoring en response. Het SOC-team. Er komt een alert binnen, iemand kijkt of die echt is, reconstrueert het verhaal en bepaalt de volgende stap. Blauw is reactief van opzet, en dat is geen kritiek, dat is de functieomschrijving.
Geel zijn de bouwers. Developers, architecten, engineers. Zij schrijven de code en bouwen de systemen die rood aanvalt en blauw verdedigt. April C. Wright voegde geel toe aan het wiel op Black Hat in 2017, in een paper genaamd Orange Is the New Purple, omdat rood en blauw tien jaar lang met elkaar hadden staan ruziën terwijl niemand sprak met de mensen die de code schreven. Geel wordt meestal buiten het gesprek gehouden. In de meeste organisaties heet dat gewoon het DevOps-team.
Paars is rood en blauw die samenwerken. Rood voert een aanval uit terwijl blauw kijkt of de detecties die ze hebben gebouwd daadwerkelijk afgaan. Paars draait de varianten net zo lang tot de detectie over de hele linie standhoudt.
Groen zorgt dat het niet opnieuw gebeurt. Niet het incidentrapport, niet het risicomemo en zeker niet de “lessons learned”-slide met vier eigenaren en geen deadline. Het wegnemen van datgene wat het incident veroorzaakte. De software patchen, de pipeline aanpassen. De configuratie herstellen. Foutafhandeling verbeteren. Het identiteitspad verwijderen. De route sluiten die de aanval mogelijk maakte.
Het mengen werkt als verf. Rood en blauw geven paars. Blauw en geel geven groen. Rood en geel geven oranje. Sommige versies voegen wit toe voor toezicht.
Ik ben niet kleurenblind, maar je kunt blind worden van dat wiel. Waar het om gaat is die ene relatie: groen = blauw + geel.
Groen zit op de naad tussen het SOC en de software engineers. Een echte groene workflow leest een detectie-inzicht en gaat terug naar de code, de pipeline, de architectuur. Deze alert is te herleiden tot een kwetsbare library. Deze tot een te ruim ingerichte managed identity. Foutafhandeling die nooit geschreven is, en daarom loopt de buffer over. Een managementinterface die aan het internet hangt en er sowieso niet had moeten zijn. Groen neemt het probleem weg in plaats van het incident te rapporteren.
Dat werkt alleen als het SOC daadwerkelijk samenwerkt met echte software engineers. In de praktijk zijn rood en blauw goed ingericht, gebeurt paars daar waar organisaties volwassen genoeg zijn om het te draaien, bestaat geel maar blijft het buiten het securitygesprek, en lijkt groen zeldzaam.
Paars ontbreekt in de naamgeving maar zit wel in het product. De gedocumenteerde workflow draait blauw, dan rood, dan groen, dan weer blauw, waarbij findings automatisch tussen ze door bewegen. Dat is purple teaming in productvorm. Microsoft bouwde het en gebruikte het woord niet, wat volgens mij bewust is, omdat de term veel geschiedenis met zich meedraagt in enterprise SOC-gesprekken.
Groen zit in de naamgeving maar reikt nog niet ver genoeg.
Posture prioritization rangschikt findings en legt uit wat je eerst moet oplossen en waarom. Dat doet er veel toe, want securityteams verzuipen in technisch valide findings zonder serieus prioriteringsmodel. Een gerangschikte lijst op basis van exploiteerbaarheid, bereikbaarheid en assetkriticaliteit is een beter operationeel model dan “kritieke CVE’s eerst” en “wie deze week het hardst riep”.
Posture prioritization is een echte verbetering ten opzichte van een platte kwetsbaarhedenlijst. Maar het raakt nooit source, pipelines of artifacts, en dat kan ook niet, want er staat geen gele agent aan de andere kant van de naad. Microsoft benoemde de kleur correct en leverde de helft ervan. In een systeem dat gebouwd is om de loop van finding naar fix te sluiten, stopt de loop aan de rand van de codebase.
We hebben de basis van Project Perception behandeld terwijl het in public preview zit. Vooruitkijkend denk ik niet dat we het volledige product al zien. Laten we het een voorspelling van mijn kant noemen, en dan zien we of die standhoudt.
Groen kan niet worden afgemaakt vanuit de Defender-portal. De fix ligt vaak elders: een repository, pipeline, policy, configuratiebestand, enzovoort. Dat betekent dat Perception een code- en configuratieoppervlak nodig heeft:
een connector naar GitHub en Azure DevOps
een agent die een finding leest en een wijziging voorstelt
een playbook dat de hele keten draait, van threat intelligence tot een remediation-artifact of een pull request
een menselijke goedkeuringspoort vóór impact
Ik verwacht dat dat komt, en eerder dan de previewstatus doet vermoeden. Er zijn minstens vier dingen die die kant op wijzen.
De producttaal gaat al uit van actuators. Microsofts eigen Project Perception-materiaal spreekt over actuators: het mechanisme waarmee een agent op zijn omgeving inwerkt en een beslissing omzet in een effect in de echte wereld, niet slechts een aanbeveling. Een actuator is geen dashboard, het is het ding dat iets verandert: detectieregel, Defender-instelling, CA-policy, geroteerde credential, pull request. De architectuur wijst al voorbij pure analyse.
De modellen wijzen die kant op. Perception draait op een multi-model architectuur, en Microsoft zette MAI-Cyber-1-Flash, het eerste doelgebouwde cybermodel, in de stack. Naar mijn weten is dat model een security fine-tune van MAI-Code-1-Flash, dat Microsoft op zijn eigen modelpagina beschrijft als “built into GitHub Copilot and VS Code”. Als het cybermodel en het codeermodel uit dezelfde familie komen, dan convergeren het securitywerk en de development-toolchain al één laag onder het product.
De actuator bestaat al. De integratie tussen Microsoft Defender for Cloud en GitHub Code Security werd generally available op Build 2026. Codekwetsbaarheden worden verrijkt met productiesignalen, en developers remediëren via GitHub Copilot Autofix en de Copilot cloud agent, die de fix genereren, toewijzen en valideren. Microsoft hoeft de handen niet te bouwen. Het moet de handen die het heeft verbinden met de agents die nu het redeneerwerk doen.
En het outputformaat vraagt erom. Een finding die eindigt in een pull request is meer waard dan een finding die eindigt in een markdown-rapport, want de één verandert het systeem en de ander verandert een document. Perceptions hele argument is dat een finding een fix moet worden zonder overdracht bij elke stap. Op dit moment is de laatste overdracht de grootste: van het SOC naar de engineering-backlog, waar securityfindings liggen te verouderen.
Kijk naar de playbooks voor het signaal. Ze zijn Microsoft-managed en read-only, dus je kunt dit niet zelf bouwen en je hoeft ook niet te gissen wanneer het landt. De dag dat er een playbook verschijnt dat een threat intelligence-bron neemt en eindigt in een branch, is groen echt.
Op dat moment heb je geen DevOps-team meer. Dan heb je een DevSecOps-team, en deze keer doet de securityhelft van de naam echt werk in plaats van bij de sprint review aan te schuiven. Dezelfde threat intelligence-input, twee manieren om erop te handelen: Detection Authoring schrijft KQL voor een techniek terwijl een gele agent diezelfde techniek uit de code patcht. Dat is het eerste werkelijk nieuwe operationele model dat ik hiervoor voorgesteld heb zien worden, en het is de reden dat ik Perception lees als onvermijdelijk in plaats van optioneel.
De pull request is waarschijnlijk niet het eindpunt, maar wel het makkelijkst zichtbare. Ik vermoed dat groene agents niet bij code zullen stoppen. Pull requests zijn de developer-variant van een groter patroon: infrastructure-as-remediation, policy-as-remediation, configuration-as-remediation en workflow-as-remediation.
Nu het deel dat het dichtst bij mijn eigen werk ligt, en het deel dat volgens mij het minst af is.
De output van een Recon Agent-sessie is een tenant-specifieke kaart van privilege-paden, choke points en lateral movement-opties. Die komt binnen in het Outputs-paneel als markdown-rapport met een Download-knop ernaast. Dat bestand is niet zomaar een securityartefact, het is een machinaal gegenereerde attack graph van jouw omgeving.
Organisaties classificeren routinematig klantdata, intellectueel eigendom en broncode. Project Perception introduceert nog een ongemakkelijke categorie: machinaal gegenereerde offensieve intelligence. In veel omgevingen is een attack path-rapport gevaarlijker dan de documenten waarnaar het verwijst.
Sessies zijn immutable binnen Defender, wat dekt wat de agent deed, niet wat er daarna met de output gebeurt. Daar is Purview voor nodig: een label op agent-gegenereerde rapporten, DLP op de download, retentie, een Insider Risk-indicator op de analist die in één week elf attack path-maps exporteerde en vervolgens ontslag nam. Naar mijn weten is daar nog niets end-to-end van bedraad, en ik zou graag ongelijk hebben. Security Copilot stroomt al door naar de unified audit log en DSPM for AI, dus het precedent bestaat. Work IQ leunt ook zwaar op permission-aware governance, observability, runtime policy en tenantgrenzen. De richting is duidelijk. Het specifieke Perception-naar-Purview control plane is het deel dat ik in de gaten zou houden.
De interessantere integratie loopt de andere kant op. Posture Prioritization rangschikt op exploiteerbaarheid, bereikbaarheid en assetkriticaliteit, en assetkriticaliteit is een infrastructuurantwoord. Een storage account met geclassificeerde klantgegevens en één met build logs zijn identieke infrastructuur en compleet verschillend risico. Voeg Purview-classificatie toe aan Perceptions contextlaag en groen stopt met rangschikken op blast radius en begint met rangschikken op consequentie.
Microsoft heeft het patroon elders al bewezen. De integratie tussen Defender for Cloud en GitHub Code Security verrijkt codefindings al met datagevoeligheid. Dat signaal bereikt een pull request, maar niet de posture-agent een paar menu-items verderop in dezelfde portal.
Eén observatie die op zichzelf klein is en optelt. De Perception-sessie-ervaring ziet eruit en gedraagt zich als Microsoft 365 Copilot Cowork. Een gespreksfeed met voortgangsupdates. Voltooiingsmarkeringen die Done in 4 min melden. Een agentteller die 4/4 toont. Een Inputs-paneel. Een Outputs-paneel met downloadbare bestanden. Een invoerveld onderaan met het label Ask about this session.
Kijken we hier naar het begin van de "Super App" voor cybersecurity waar Satya Nadella naar verwees tijdens de Q4 FY2026 earnings call? Misschien niet precies, want die was meer of minder gericht op Microsoft 365 Copilot, maar het idee ligt er.
Sommige versies van het wiel dragen een vierde aanduiding. Meng alle kleuren en je krijgt wit: toezicht, governance. De mensen die bepalen hoe goed eruitziet en die de lijn vasthouden wanneer de druk om sneller te gaan zich aandient.
Perceptions hele veiligheidsverhaal rust daarop. High-impact acties pauzeren bij een goedkeuringspoort. Mensen beoordelen, keuren goed, wijzen af of sturen bij. Strategie blijft bij mensen, schaal gaat naar de agents. Ik ben het eens met dat ontwerp. Het ligt dicht bij wat ik in juni op het podium betoogde: AI-led, human-owned.
Maar een goedkeuringspoort is alleen een control zolang iemand daar oordeelsvermogen uitoefent. Zes agents die gecoördineerde playbooks over je estate draaien, produceren goedkeuringsverzoeken sneller dan een mens ze leest, en wie ooit een SOC heeft gerund weet wat er gebeurt met een wachtrij die zijn beoordelaars voorbijloopt. De faalmodus is niet een rogue agent. Het is een vermoeide analist die het veertiende verzoek van de nacht goedkeurt omdat de eerste dertien in orde waren.
We hebben allemaal gelezen dat sommige AI-modellen tijdens cyberevaluaties uit hun sandbox ontsnappen, een zero-day aan internettoegang koppelen, lateraal door clusters bewegen en systemen van derden binnendringen, allemaal om de antwoordsleutel te stelen van de benchmark waarop ze werden beoordeeld. Niemand stuurde dat aan. Die modellen waren ook niet kwaadaardig. Ze kregen een doel en achtervolgden dat voorbij elke grens waarvan iemand had aangenomen dat die standhield.
Jouw goedkeuringspoort is een grens waarvan iemand aanneemt dat die standhoudt.
Microsoft kan rood, blauw, groen en uiteindelijk geel leveren. Wit is de kleur die je zelf bemant, en het is de kleur die bepaalt of dit alles standhoudt.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.