Da jeg gikk gjennom Microsoft Defender-portalen, fant jeg noe jeg ikke hadde planlagt for: ansatte brukte allerede lokale KI-kodeagenter, blant annet Claude Code og Codex CLI, på administrerte Windows-enheter.

Verktøyene var synlige. Kontrollen manglet.

Det er viktig fordi en lokal agent ikke oppfører seg som et vanlig chatvindu. Den kjører med brukerens rettigheter og kan lese kodelagre, lokale filer, nettinnhold og verktøysvar. Støttede agenter kan også kalle verktøy og kjøre kommandoer. En skadelig instruksjon skjult i ellers legitimt innhold kan derfor bli til en endepunkthandling, ikke bare et dårlig modelsvar.[1][3]

Jeg brukte funnet til å bygge en liten, evidensbasert kontrollkjede:

  1. Finn aktive lokale KI-agenter med Defender Advanced Hunting.
  2. Finn Windows-enhetene bak agentene.
  3. Legg de validerte enhetene i en tildelt Microsoft Entra-sikkerhetsgruppe.
  4. Tildel Microsoft Defender AI agent runtime protection i Audit-modus.
  5. Bekreft effektiv innstilling og skap en kjent, ufarlig deteksjon før Block vurderes.

Jeg har bevisst fjernet policynavn, enhetsnavn, brukernavn, tenant-identifikatorer og flåtetall fra artikkelen. Diagrammet under er en tenant-nøytral rekonstruksjon av implementeringen, ikke et skjermbilde fra produksjonsportalen.

Arkitektur som viser oppdagelse av lokale KI-agenter, KQL-avgrensing, målretting med Entra-enhetsgruppe, Defender-inspeksjon, Audit- og Block-resultater, valideringskrav og dekningsgrenser.

Hvorfor dette bør behandles som endepunktsikkerhet

Microsoft Defender kan automatisk oppdage støttede lokale KI-agenter og tilknyttede MCP-serverkonfigurasjoner på onboardede enheter. Inventaret kan knytte en agent til enheten og kontoen, mens AgentsInfo gir sikkerhetsteamet en jaktflate for agentmetadata og lokal konfigurasjon.[1][2]

Oppdagelse er ikke beskyttelse. Oppdagelse forteller hvor en agent finnes. Kjøretidsbeskyttelse er den separate kontrollen som inspiserer støttede punkter i agentløkken:

  • brukerprompten;
  • det forespurte verktøykallet før kjøring; og
  • verktøysvaret før det går videre i agentkonteksten.[3]

For agenter som tilbyr leverandørstøttede hendelsesgrensesnitt, bruker Defender agentnative hendelser. Microsoft lister nå Claude Code, Codex CLI, GitHub Copilot CLI og GitHub Copilot-appen for denne stien. Nettverksinspeksjon er en separat beskyttelsesmetode for støttede agenter som ikke tilbyr slike grensesnitt.[3]

Det skillet betyr noe. Endepunktpolicyen jeg opprettet konfigurerer AiAgentProtection, altså agentnative inspeksjon. Den bør ikke beskrives som universell dekning for alle KI-applikasjoner eller alle nettverksstier.

Forutsetningene jeg sjekket først

Microsofts gjeldende konfigurasjonsveiledning oppgir disse hovedkravene for kjøretidsbeskyttelse:[4]

  • Microsoft Defender for Endpoint Plan 2, Microsoft 365 E5, Microsoft Agent 365 eller Microsoft 365 E7;
  • enheter onboardet til Defender for Endpoint;
  • Microsoft Defender Antivirus i aktiv modus med sanntidsbeskyttelse;
  • støttet Windows-versjon og oppdatert Defender-plattform, motor og sikkerhetsintelligens;
  • minst én støttet lokal KI-agent; og
  • nødvendige Intune-, Defender- og varslingsrettigheter.

Jeg holdt også pilotgruppen liten. Dette er fortsatt en forhåndsvisningsfunksjon som ligger direkte i arbeidsflytene til utviklere og administratorer.

Trinn 1: bygg et oppdatert agent- og enhetsinventar

Defenders veiledning for lokale agenter anbefaler å filtrere AgentsInfo på Platform == "LocalAgents", hente den nyeste raden per AgentId og fjerne profiler som er slettet eller avinstallert.[2]

Dette er spørringsmønsteret jeg bruker for å lage en enhetsbasert eksport. column_ifexists() gjør visningsnavnet mer robust mot navneendringer i preview-skjemaet:

let LocalAgentProfiles =
    AgentsInfo
    | where Platform == "LocalAgents"
    | summarize arg_max(Timestamp, *) by AgentId
    | where isempty(LifecycleStatus)
        or LifecycleStatus !in~ ("Deleted", "Uninstalled")
    | extend Local = RawAgentInfo.localAgentMetadata
    | extend Agent = coalesce(
                 tostring(column_ifexists("Name", "")),
                 tostring(column_ifexists("AgentName", ""))),
             Vendor = tostring(Local.vendor),
             DeviceName = tostring(Local.deviceName),
             EntraDeviceId = tostring(Local.aadDeviceId),
             AccountName = tostring(Local.accountName),
             AutoApprove = tostring(Local.autoApprove),
             TrustedProcess = tostring(Local.trustedProcess);
LocalAgentProfiles
| where Agent has_any ("Claude", "Codex")
| summarize
    Agents = make_set(Agent, 20),
    Vendors = make_set(Vendor, 20),
    Accounts = make_set_if(AccountName, isnotempty(AccountName), 20),
    AutoApproveValues = make_set(AutoApprove, 5),
    TrustedProcessValues = make_set(TrustedProcess, 5),
    LastSeen = max(Timestamp)
    by DeviceName, EntraDeviceId
| project DeviceName, EntraDeviceId, Agents, Vendors,
          Accounts, AutoApproveValues, TrustedProcessValues, LastSeen
| order by LastSeen desc

Jeg gikk gjennom hele inventaret over lokale agenter før jeg brukte Claude/Codex-filteret. Filteret er et avgrensingsvalg, ikke en påstand om at andre agenter er trygge.

I arbeidsfilen for gruppemedlemskap beholdt jeg bare det nødvendige: enhetsnavn, Entra-enhets-ID, observerte agenter og sist sett-tidspunkt. Kontoopplysninger er nyttige i risikovurderingen, men trengs ikke for å legge et enhetsobjekt i en distribusjonsgruppe.

Trinn 2: gjør jaktfunnene om til en kontrollert distribusjonsring

Jeg opprettet en Microsoft Entra-gruppe med:

  • Gruppetype: Security
  • Medlemskapstype: Assigned
  • Medlemmer: bare enhetsobjekter
  • Formål: begrenset pilot for kjøretidsbeskyttelse av KI-agenter
  • Eier: navngitt operativ eier
  • Gjennomgang: dokumentert dato for oppdatering av medlemskapet

Intune støtter Entra-sikkerhetsgrupper med tildelt eller dynamisk medlemskap. Microsoft fraråder også å blande brukere og enheter i samme gruppe fordi det kan gi uoversiktlig policyatferd.[7]

Jeg valgte en tildelt gruppe fordi Defenders observerte tilstand for lokale agenter ikke er en innebygd dynamisk Entra-enhetsegenskap. Ulempen er viktig: gruppen er et øyeblikksbilde. Den blir utdatert hvis jakten ikke kjøres på nytt og medlemskapet ikke gjennomgås.

En sterkere driftsmodell er:

Planlagt jakt -> gjennomgått enhetsendring -> endret gruppemedlemskap
-> policystatus -> effektiv innstilling -> deteksjonstest

Ikke automatiser hele kjeden uten menneskelig kontroll på første dag. Et feiltreff i oppdagelsen skal ikke bli til en ubehandlet håndhevingsendring i produksjon.

Trinn 3: opprett kjøretidspolicyen

Jeg brukte policyoversikten i Microsoft Defender-portalen:

https://security.microsoft.com/policy-inventory?osPlatform=Windows

Policystien er:

  1. Velg Create new policy.
  2. Velg Windows.
  3. Velg Microsoft Defender AI agent runtime protection.
  4. Sett Ai Agent Protection til Audit.
  5. Tildel Entra-sikkerhetsgruppen med enheter.
  6. Kontroller og lagre.

Den samme agentnative innstillingen kan distribueres fra Intune med en Endpoint security > Antivirus-policy. Policyer opprettet i Defender-portalen kan målrettes mot Intune-registrerte enheter og enheter administrert med Defender for Endpoint security settings management. For sistnevnte krever Microsoft målretting mot enhetsobjekter; brukermålretting støttes ikke.[4][6]

Defender-portalens veiviser har to praktiske begrensninger: den støtter ikke Intune scope tags eller assignment filters. Opprett eller rediger policyen i Intune dersom dette er nødvendig.[6]

Hvorfor jeg startet med Audit

I Audit tillater Defender den støttede handlingen, men registrerer deteksjonen og oppretter et informasjonsvarsel. I Block kan Defender stoppe en støttet handling før den kjøres og opprette et varsel basert på vurdert risiko.[3][4]

Microsoft anbefaler denne utrullingen:

  1. test Audit på et lite antall enheter;
  2. gjennomgå varsler i én til to uker;
  3. utvid Audit til flere enhetsgrupper; og
  4. flytt utvalgte grupper til Block først når deteksjonene er presise og håndterbare.[4]

Policysiden i piloten min viste vellykket behandling av innstillingen og vellykket innsjekk fra pilotenhetene. Det bekreftet distribusjonsfremdrift. Det beviste ikke i seg selv at prompt injection ville bli oppdaget.

Trinn 4: bekreft kontrollen på fire nivåer

En policy er ikke ferdig når portalen viser grønt. Jeg brukte fire beviskrav.

1. Tildeling og innsjekk

Kontroller policyens tildelte grupper, status for policyinnstillingen og status for anvendte enheter. Dette avdekker målrettings-, konflikt- og distribusjonsproblemer, men er fortsatt bevis fra administrasjonsplanet.

2. Effektiv innstilling på enheten

Åpne enheten i Microsoft Defender-portalen og gå til:

Configuration management > Effective settings > Ai Agent Protection

Bekreft både effektiv verdi og konfigurasjonskilde. Microsoft dokumenterer dette som verifikasjonsstien på enhetsnivå.[4]

For lokal kontroll på en autorisert testenhet:

Get-MpPreference |
    Select-Object AiAgentProtection, AiAgentNetworkInspection

Lukk eksisterende agent- og terminalsesjoner etter at kontrollen er aktivert. Start deretter en ny terminal før testen. Microsoft fremhever dette omstartstrinnet i dokumentasjonen.[4][5]

3. Ufarlig prompt-injection-demo

Microsoft publiserer en ufarlig testprompt spesielt for å validere funksjonen. Kjør den bare på en autorisert testenhet og tenant. At agenten selv avviser prompten er ikke tilstrekkelig bevis. Deteksjonen må vises i Defender eller Windows Protection history.[5]

4. Varselbevis i Defender

Microsofts demo bruker denne spørringen for å finne deteksjonen:[5]

AlertInfo
| where Timestamp > ago(24h)
| where Title has "AI prompt injection"
      or Title has "Suspicious AI prompt injection"
| project Timestamp, AlertId, Title, Severity, Category, ServiceSource
| order by Timestamp desc

I Audit er det forventede Defender-varselet informativt. I Block bestemmes alvorlighetsgraden av vurdert risiko. Relaterte varsler kan korreleres til hendelser for vanlig SOC-undersøkelse.[4]

En dokumentasjonskonflikt du bør kjenne til

Microsofts versjonsnotat fra juli 2026 sier at agentnative hendelsesgrensesnitt fungerer med standard oppdateringskanaler for plattform og motor, og at Beta-kanalen ikke lenger er påkrevd.[8]

De gjeldende konfigurasjons- og demosidene instruerer likevel administratorer om å sette testmaskiner for public preview på Beta-kanalen for plattform og motor.[4][5]

Jeg ville ikke løst motsetningen ved å flytte en stor produksjonsring til Beta. Bruk en begrenset testgruppe, les gjeldende dokumentasjon når du implementerer, bekreft installerte Defender-versjoner, og la den ufarlige demoen sammen med Defender-varselet være det avgjørende beviset. Preview-krav kan endres raskere enn normale driftsstandarder.

Dette løser ikke policyen

Kontrollen er nyttig, men grensene er smale:

  • den dekker støttede agenter og støttede inspeksjonsstier;
  • policyprofilen konfigurerer agentnative hendelser, ikke alle scenarioer for nettverksinspeksjon;
  • vellykket inventar eller policystatus beviser ikke at deteksjonsstien virker;
  • den avgjør ikke om selve programvaren er godkjent;
  • den erstatter ikke applikasjonskontroll, minste privilegium, datatapskontroller, kodelagertilgang eller MCP-styring; og
  • en statisk enhetsgruppe krever vedlikehold av medlemskapet.

Hvis et agentprogram ikke skal kunne kjøre i det hele tatt, er det en beslutning om applikasjonskontroll. Kjøretidsbeskyttelse og tillatelse eller blokkering av selve programvaren er ulike kontroller.

Driftsstandarden jeg ville beholdt

Min endelige rekkefølge er:

Oppdag -> klassifiser -> avgrens -> Audit -> bevis -> gjennomgå -> Block selektivt

Det seniorfaglige er ikke å opprette policyen. Det er å bevare evidenskjeden:

  • hvorfor hver enhet er omfattet;
  • hvem som eier distribusjonsringen;
  • hvilken modus som er aktiv;
  • hva den effektive enhetsinnstillingen er;
  • om en kjent, ufarlig test skapte Defender-evidens;
  • hvordan feiltreff og unntak håndteres; og
  • når statisk medlemskap oppdateres.

Da blir en preview-bryter til en kontrollert endepunktsikkerhetsfunksjon.

Sources

[1] https://learn.microsoft.com/en-us/defender-endpoint/local-agent-discovery-overview — Local AI agent discovery with Microsoft Defender for Endpoint [2] https://learn.microsoft.com/en-us/defender-endpoint/discover-local-ai-agents — Discover local AI agents with Microsoft Defender for Endpoint [3] https://learn.microsoft.com/en-us/defender-endpoint/ai-agent-runtime-protection-overview — AI agent runtime protection with Microsoft Defender for Endpoint [4] https://learn.microsoft.com/en-us/defender-endpoint/configure-ai-agent-runtime-protection — Set up AI agent runtime protection with Microsoft Defender for Endpoint [5] https://learn.microsoft.com/en-us/defender-endpoint/defender-endpoint-demonstration-ai-agent-runtime-protection — AI agent runtime protection demonstration [6] https://learn.microsoft.com/en-us/defender-endpoint/endpoint-security-policies-configure — Manage endpoint security policies in Microsoft Defender for Endpoint [7] https://learn.microsoft.com/en-us/intune/fundamentals/tenant-administration/add-groups — Use groups to organize users and devices for Microsoft Intune [8] https://learn.microsoft.com/en-us/defender-endpoint/whats-new-in-microsoft-defender-endpoint — New features in Microsoft Defender for Endpoint