Ja, det är säkert att köra AI-genererad PowerShell i produktion, men bara med en godkännandegrind framför. Ett skript som en assistent skrev är inte farligare än ett som en ingenjör skrev klockan fyra en fredag. Det som gör det riskabelt är att de flesta organisationer saknar en regel som täcker det. Det finns en ändringsprocess för en brandväggsregel och en releaseprocess för en applikation, och sedan finns det ett skript som dök upp i ett chattfönster och kördes med en token för Global Administrator. Den kontroll som saknas är ingen modellinställning. Det är en namngiven godkännare, en fastställd lista över vad den personen kontrollerar, och en anteckning om vad som kördes och varför.

Vi har ISO 27001, ISO 9001, ISO/IEC 42001 och Cyber Essentials, så detta kommer från att ha fått dessa frågor i bedömningar.

Felet är den saknade grinden, inte modellen

Det mesta av diskussionen om AI i driften handlar egentligen om modellkvalitet, vilket är fel diskussion. Samma organisation kör redan skript från konsulter, från forum, och från personal som slutade 2019. Ursprung var aldrig kontrollen. Granskning var det.

Det som verkligen förändras är genomströmningen. En ingenjör kan nu producera tjugo rimliga åtgärdsplaner på en eftermiddag, så begränsningen flyttar från att skapa till att granska, och granskning är den del ingen bemannade. En plan som läser självsäkert och citerar rätt cmdletar glider förbi en trött granskare, eftersom inget i den är uppenbart fel. Det som saknas är en avgränsad omfattning, och frånvaro är svårare att upptäcka än fel.

Den första frågan är alltså inte "kan vi lita på AI:n" utan "vad kontrollerar egentligen den som klickar godkänn".

Flödesschema över en godkännandegrind för en AI-genererad driftändring. En begäran kommer från en ingenjör eller ett ärende i supportfunktionen. AI-assistenten tar fram en plan och ett skript och registrerar begäran och verktygets version. Utkastet går vidare till en granskningsgrind där en namngiven granskare kontrollerar sju saker: omfattning och filter, destruktiva operationer, stöd för testkörning, idempotens, skadeomfång, den identitet arbetet körs under, och återställningsvägen. Tre utfall lämnar grinden: godkänt och utfört, återsänt för ändring, eller avslaget. Godkänt arbete körs under en namngiven tjänsteidentitet och skriver en utförandeanteckning med vem som godkände, vad som kördes, vad som ändrades och resultatet. En pil går tillbaka från anteckningen till grinden, märkt befordringsgranskning, eftersom ett arbetsflöde som upprepat klarar sig är det som förtjänar en bredare autonomifil.

Grinden är produkten: allt före den är ett utkast, och allt efter den är bevis.

Tre filer av autonomi

Om AI "får agera" är fel fråga, eftersom svaret skiljer sig per uppgift. Sortera arbetet i tre filer, och ge filen till arbetsflödet snarare än till verktyget.

Endast läsning. Logganalys, att ta fram dokumentation, att förklara vad en policy gör. Inget ändrar tillstånd, så felläget är ett felaktigt svar snarare än en felaktig åtgärd. Allt börjar här.

Föreslå och godkänn. Assistenten tar fram planen och skriptet; en människa läser det och kör det. Det mesta nyttiga driftarbetet hör hemma här, och det är här grinden sitter. Godkännande måste vara en handling med en anteckning. Om processen är "ingenjören tittar på det och kör det" är det den tredje filen med extra steg.

Utför inom policy. Assistenten genomför ändringen inom en på förhand godkänd gräns: en fastställd uppsättning operationer, en fastställd målomfattning, ett tak för skadeomfånget och automatiska stoppvillkor. Bra kandidater är smala, repetitiva, återställningsbara och övervakade, som att tillämpa en dokumenterad licensåtervinning på konton som redan bekräftats som avslutade.

Ett arbetsflöde förtjänar den tredje filen när det har körts i den andra tillräckligt många gånger för att bli tråkigt: godkänt upprepade gånger utan ändring, deterministiskt, avgränsat strukturellt snarare än av ett inskrivet filter, och testat baklänges. Degradera vid varje överraskning, och för aldrig över en fil till en uppgift som bara ser likadan ut.

Vad en granskare faktiskt kontrollerar

Detta är listan som saknas i de flesta policyer. Sätt den bredvid godkännandeknappen och låt granskaren registrera vilka kontroller som gjordes.

Omfattning och filter. Vad berör detta, och vad definierar den mängden? Ett inskrivet filter är ett löfte; ett granskat gruppmedlemskap är en gräns. Den klassiska incidenten är ett filter som tyst matchar allt eftersom en egenskap var tom på fler objekt än väntat.

Destruktiva operationer. Leta efter remove, delete, disable, reset, och varje skrivning till en produktionskonfiguration. Läsningar är billiga att ha fel om; skrivningar är det inte.

Stöd för testkörning. Stöder det en förhandsgranskning, och har den förhandsgranskningen körts och lästs? I PowerShell betyder det verklig hantering av ShouldProcess så att -WhatIf fungerar, inte en kommentar som påstår att skriptet är säkert.

# Unbounded: matches every disabled account in the tenant, no preview, no confirmation
Get-MgUser -Filter 'accountEnabled eq false' -All | Remove-MgUser
# Bounded: a reviewed membership defines the scope, and the preview runs first
$leavers = Get-MgGroupMember -GroupId $ConfirmedLeaversGroupId -All
$leavers | ForEach-Object { Remove-MgUser -UserId $_.Id -WhatIf }

Idempotens. Om detta körs två gånger, gör den andra körningen ingenting eller gör den skada? Fråga vad ett nytt försök efter ett delvis misslyckande gör, eftersom det är det vanliga fallet.

Skadeomfång. Inte "är detta rätt" utan "om det är fel, hur många märker det och hur snabbt". En licenstilldelning och en policy för villkorsstyrd åtkomst ger mycket olika svar.

Vilken identitet det körs under. Kontrollen folk hoppar över. Om arbetet utförs inne i en ingenjörs privilegierade session säger varje loggpost att en människa gjorde det. Obevakat arbete hör till en arbetsbelastningsidentitet som bara har de behörigheter uppgiften behöver, samma disciplin som den nuvarande frågeuppsättningen driver på tjänstekonton i vår checklista för direkt underkännande i Microsoft 365.

Återställningsväg. Vad gör detta ogjort, och har någon testat det? Att återställa från säkerhetskopia är ingen återställningsväg för ett katalogobjekt, och det som inte kan göras ogjort behöver ett högre godkännande, inte ett snabbare.

Vad standarderna säger, och vad de lämnar till dig

Varken ISO 27001 eller Cyber Essentials innehåller en kontroll som lyder "du får inte köra AI-genererade skript". Att vänta på en sådan är ett misstag, eftersom skyldigheterna redan gäller och bara inte använder ordet.

ISO 27001:2022 kräver kontrollerad ändring, loggning som låter dig rekonstruera händelser, åtskillnad av privilegierad åtkomst, och fastställd konfigurationshantering. En åtgärd som börjar hos en assistent är en ändring och behöver samma auktorisation och anteckning som varje annan. ISO/IEC 42001 går längre och kräver ett ledningssystem kring AI-användning: fastställt syfte, fastställda roller, riskbedömning och övervakning av beteendet i praktiken.

Cyber Essentials bryr sig i huvudsak inte om hur ett skript skrevs. Det bryr sig om att administrativ åtkomst är åtskild och att de konton som kan göra ändringen är kontrollerade. Kopplingen är indirekt men verklig: i samma stund som en assistent behöver stående privilegier för att vara användbar har du skapat precis den permanent förhöjda identitet som systemet är missnöjt med.

Det de lämnar till dig är bedömningen: ingen av dem talar om vilka operationer som hör hemma i den tredje filen, och det en revisor efterfrågar är resonemanget och anteckningen bakom det beslutet. Vår koppling av Microsoft 365-inställningar till Cyber Essentials och ISO 27001 täcker kontrollbilden under.

Bevisanteckningen som en revisor accepterar

Ett godkännande som inte lämnar spår har inte skett. En användbar anteckning per utförd åtgärd innehåller utlösaren, beställarens avsikt med egna ord, hela det godkända underlaget snarare än en sammanfattning, verktyget och versionen som tog fram det, den namngivna granskaren och vilka kontroller som registrerades, beslutet och tidsstämpeln, den utförande identiteten, målomfattningen som den bestämdes vid körning, resultatet inklusive delvisa misslyckanden, och varje genomförd återställning.

Två egenskaper betyder mer än fullständighet. Den måste gå att söka i, eftersom en revisor frågar om ett datumintervall snarare än om en mapp. Och den måste överleva plattformens egna loggar, som upphör tidigare än de flesta antar.

Var det går sönder

Delade administrativa konton. Godkännandeanteckningen namnger en person, utförandeanteckningen namnger ett konto, och inget kopplar ihop dem. Åtgärda kontona först.

Assistenten som agerar med en människas inloggningsuppgifter. Bekvämt, och det förstör spårbarheten. Varje efterföljande logg visar då en person som utför åtgärder hon kanske inte läst noggrant.

Loggarnas bevarandetid. Din godkännandeanteckning kan leva i åratal medan plattformens uppgift om vad som ändrades upphör inom veckor. Du bevisar att någon godkände något och kan inte bevisa vad det gjorde.

Delegerad åtkomst hos leverantörer av hanterade tjänster. När arbete landar i en kundtenant genom delegerad åtkomst, avgör vilken sida som håller godkännandeanteckningen och hur kunden får den, jämte vad som bör rapporteras varje månad.

Godkännandeteater. Om granskaren godkänner allt på några sekunder är grinden dekorativ. Mät andelen ändringar, inte andelen godkännanden.

En införandeordning med stoppvillkor

  1. Inventera vad som redan sker. AI-genererade skript körs redan. Du behöver den ärliga utgångspunkten.
  2. Skriv granskarens checklista. De sju kontrollerna ovan. Stanna om du inte kan namnge vem som granskar.
  3. Kör allt i filen föreslå och godkänn i ett kvartal. Stanna om andelen ändringar är nära noll, för då läser ingen.
  4. Ge obevakat arbete en egen identitet. Ingen stående Global Administrator, inga delade konton, avgränsade behörigheter per arbetsflöde. Inget efter detta fungerar utan det.
  5. Befordra två eller tre arbetsflöden, med stoppvillkor satta i förväg: ett tak för antalet objekt, en feltröskel, en spärr utanför kontorstid.
  6. Se över kvartalsvis och degradera utan tvekan.

Räkna med två kvartal. Den långsamma delen är aldrig tekniken; det är att enas om vem som äger beslutet.

Var EtherAssist passar in

Den grinden är vad EtherAssist är byggt kring. Det tar fram planen och skriptet med den operativa kontexten från en Microsoft-miljö bakom sig, håller arbetet vid ett mänskligt godkännandesteg, och skriver utförandeanteckningen på andra sidan, så att godkännande och bevis är ett underlag i stället för två system att stämma av senare.

Det är vad vår rutt agentic operations täcker: avgränsad körning med mänskligt godkännande och ett spårbart underlag, skilt från det bredare arbetet med IT-drift och efterlevnad. Om drivkraften är en kommande bedömning passar ISO-efterlevnad och revisionsberedskap bättre, och vad agentisk AI betyder för IT-team sätter vokabulären. EtherAssist kostar GBP 16.00 per användare och månad med 14 dagars provperiod, så ett riktigt arbetsflöde kan gå genom grinden först.

Utforska agentic operations för att se hur avgränsad körning, mänskligt godkännande och bevisanteckningen hänger ihop i ett arbetsflöde.