Microsoft gjør agentsikkerhet til CI-test

Microsoft flytter agentsikkerhet inn i utviklingsløpet, ikke bare inn i policy-dokumentet.

Selskapet har åpnet kildekoden til to nye verktøy fra Microsoft AI Red Team: RAMPART og Clarity. Poenget er enkelt og ganske praktisk: AI-agenter som leser e-post, henter CRM-data, skriver kode og bruker verktøy på vegne av ansatte, må testes som operativ programvare. Ikke som en chatbot som av og til svarer feil.

Det gjør denne saken viktig for norske CIO-er og CISO-er. Agentprosjekter er på vei fra pilot til drift. Da holder det ikke å spørre om modellen er «trygg». Ledergruppen må vite hvilke systemer agenten får tilgang til, hvilke handlinger den kan utføre, hvordan den feiler, og om samme feil kan komme tilbake etter neste release.

Microsofts svar er å gjøre deler av red-team-arbeidet om til repeterbare tester.

RAMPART gjør røde funn til CI-porter

RAMPART er et åpent test-rammeverk for agentiske AI-systemer. Det bygger på PyRIT, Microsofts rammeverk for automatisert red teaming av generativ AI, men er laget nærmere utviklernes normale arbeidsflyt.

I stedet for at sikkerhetsteamet kjører en vurdering sent i prosjektet, kan utviklere skrive vanlige pytest-tester som beskriver scenarier fra trusselmodellen. Testen kobles til agenten gjennom en adapter, kjører en interaksjon og vurderer observerbare utfall: hvilke verktøy agenten bruker, hvilke sideeffekter som oppstår, og om handlingene holder seg innenfor definerte grenser.

Det er viktig fordi de farligste agentfeilene sjelden ser ut som klassiske modellfeil. En agent kan lese et forgiftet dokument, en e-post, en ticket eller en nettside, og deretter bli manipulert til å gjøre noe den ikke skulle. Microsoft peker spesielt på kryss-prompt-injeksjon som moden dekning i RAMPART. Det er nettopp den typen risiko som kommer når agenter kobles til interne datakilder og verktøy.

RAMPART støtter også statistiske tester. Det betyr at samme scenario kan kjøres flere ganger, med krav som at en handling må være trygg i minst 80 prosent av kjøringene. Det er en mer realistisk måte å teste LLM-baserte systemer på enn én enkel pass/fail-kjøring.

For ledere er styringspoenget tydelig: hvert alvorlige red-team-funn og hver AI-hendelse bør bli en regresjonstest. Hvis en agent forsøker å sende data ut av et system, kjøre en uønsket handling eller følge instruksjoner fra utryggt innhold, skal det ikke bare lukkes i en rapport. Det skal bli en test som kjører hver gang agenten endres.

Clarity angriper feilen før koden skrives

Det andre verktøyet, Clarity, er mindre teknisk på overflaten, men minst like interessant styringsmessig. Microsoft beskriver det som en strukturert sparringspartner for team som skal avklare om de bygger riktig løsning før de begynner å kode.

Clarity kan kjøre som desktop-app, webgrensesnitt eller inne i en kodeagent. Det leder teamet gjennom spørsmål om problemforståelse, løsningsvalg, feilanalyse og beslutninger. Resultatet lagres i en .clarity-protocol/-mappe i repoet som vanlige Markdown-filer. De kan leses, endres, committes og vurderes i pull requests som annen kode.

Det gjør arkitekturvalg og risikovurderinger sporbare. Hvorfor fikk agenten tilgang til dette verktøyet? Hvilke alternativer ble forkastet? Hvilke failure modes ble vurdert? Hvem godkjente antakelsen? Seks måneder senere kan teamet lese beslutningsgrunnlaget, ikke bare gjette seg frem fra Slack-tråder og gamle tickets.

Microsoft skriver også at Clarity bruker flere AI-«thinkers» som vurderer systemet fra ulike vinkler, blant annet sikkerhet, menneskelige faktorer, adversarielle scenarioer og drift. Det er ikke en erstatning for ansvarlige mennesker. Men det kan tvinge frem spørsmål som ofte kommer for sent: hva skjer når to krav kolliderer, når en integrasjon misbrukes, eller når agenten får mer handlingsrom enn produktteamet egentlig mente?

Konsekvensen for norske virksomheter

Dette er ikke bare en Microsoft-nyhet. Det peker på en bredere dreining: agentsikkerhet blir en del av software engineering.

For norske virksomheter som tester AI-agenter i kundeservice, utvikling, økonomi, saksbehandling eller intern drift, bør kravbildet skjerpes nå. Spør leverandører og interne team om fire ting:

• Finnes det repeterbare sikkerhetstester for agentens verktøybruk?
• Blir red-team-funn gjort om til regresjonstester?
• Er agentens designvalg, fullmakter og antakelser dokumentert i repo eller styringssystem?
• Kan en AI-hendelse reproduseres, analyseres og verifiseres etter en fix?

Hvis svaret er nei, er prosjektet fortsatt mer demo enn drift.

RAMPART og Clarity løser ikke agentrisiko alene. De er åpne verktøy, ikke en komplett governance-modell. Men de setter en riktig standard: AI-sikkerhet må leve i samme løp som kode, endringer, tester og incident response.

Det er der kampen kommer til å stå. Ikke i neste PowerPoint om AI-strategi.

Kilder og medier

• Primærkilde: Microsoft Security Blog, «Introducing RAMPART and Clarity: Open source tools to bring safety into Agent development workflow», publisert 20. mai 2026 kl. 15:00 UTC: https://www.microsoft.com/en-us/security/blog/2026/05/20/introducing-rampart-and-clarity-open-source-tools-to-bring-safety-into-agent-development-workflow/
• Microsoft RAMPART på GitHub: https://github.com/microsoft/RAMPART
• Microsoft Clarity på GitHub: https://github.com/microsoft/clarity-agent/
• Microsoft PyRIT på GitHub: https://github.com/microsoft/PyRIT
• Thumbnail: OpenAI Image 2 / hogby.ai.