AI Blue Teaming förklarat: De tre lager där en kontroll faktiskt kan befinna sig

Fråga ett säkerhetsteam var dess AI-skyddsräcken finns, och svaret brukar vara ett policydokument, en systemprompt eller en leverantörsfunktion. Inget av dem är en kontroll. En kontroll är något som i själva handlingens ögonblick avgör om handlingen sker – och för en AI-agent finns det bara tre platser som kan fatta beslutet: modellen, gatewayen framför den och miljön runt den. Allt ett blått team ärligt kan lova kommer från den andra och den tredje av dessa. Det här är lagerfrågan, och den kommer före varje annat beslut för ett blått team, inklusive vad som ska loggas och vem som ska kontaktas. Det är också därför bevisen från fältet spelar roll: AI-incidentarkivet innehåller 400 agentincidenter från 2024-12 till 2026-10-17, och de flesta av dem är inte berättelser om en modell som beter sig illa. De är berättelser om en driftsättning utan något lager som kunde säga nej.

Blue teaming i AI-bemärkelse är arbetet med att införa dessa lager, finjustera vad de upptäcker och ha ett inövat svar för dagen då ett av dem utlöses. Det är oglamoröst, det ger ingen poäng, och det är den enda halvan av red-team/blue-team-paret som förändrar riskvärdet.

Vad ett blått team ärver, och vad det inte ärver

Traditionellt arbete i blå team vilar på en uppsättning antaganden som AI-utrullningar tyst undergräver. Loggar antogs vara fullständiga, eftersom nätverket såg varje paket. Tillgångar antogs vara uppräkningsbara, eftersom någon måste provisionera dem. Beteende antogs vara deterministiskt, eftersom ett program gör samma sak med samma indata. Ingen av de tre överlever kontakten med en agent.

Vad ett blue team i stället ärver är ett system där de mest konsekvensrika besluten fattas inuti en förfrågan som nätverkslagret behandlar som vanlig HTTPS-trafik till ett värdnamn. Prompten, den hämtade kontexten, verktygsanropen, completionen – allt finns i en förfrågningskropp, och om ingen fångar upp och tolkar den kroppen är driftsättningen funktionellt oövervakad oavsett hur bra perimetern är. Det första blue team-uppdraget är därför inte detektion; det är att etablera en sensor. Utan synlighet på förfrågningsnivå och verktygsnivå finns det inget att detektera, och varje nedströmskontroll är bara dekorativ.

Vem kan faktiskt upprätthålla kontrollen

När det väl finns en sensor blir frågan var varje kontroll tillåts sitta. Det användbara sättet att rita upp detta är utifrån ägarskap snarare än teknik, eftersom ägarskapet är det som avgör om en kontroll överlever nästa release.

Modellagret tillhör den som har tränat det. Du konfigurerar det inte, du kan inte se in i det, och dess beteende förändras när leverantören släpper en ny version – vilket kan vara vilken tisdag som helst. Det du kan göra är att låsa en version och behandla en versionsändring som en ändring av din riskprofil som kräver ett nytt test. Det du inte kan göra är att hävda en kontroll här. "Modellen avvisar skadliga förfrågningar" är en egenskap du förlitar dig på, inte en mekanism du hanterar.

Gateway-lagret är där varje prompt och varje komplettering passerar genom en komponent som du äger. Det är här budget- och hastighetsgränser finns, där tillåtelselistor och verktygsbehörigheter tillämpas, där loggning av förfrågningar och svar är fullständig genom konstruktion, och där en förfrågan kan skrivas om, blockeras eller omdirigeras innan någon token faktureras. Gateway-kontroller är också de enda som förblir kopplade när du byter modeller, vilket betyder mer än det låter: team som lägger sina kontroller i prompter förlorar dem helt och hållet den dag de migrerar.

Miljölagret är det som helt och hållet tillhör dig: autentiseringsuppgifter och deras behörighetsomfång, nätverksutgång, filåtkomst, sandlådebegränsningar för realtid och utgifter. Det är också där en komprometterad körning gör sin skada. En agent som har övertalats att agera illvilligt är farlig i exakt samma proportion till vad miljön tillät den handlingen att nå — och miljön är den enda platsen där "minsta behörighet" är en konfigurationsändring snarare än ett forskningsproblem.

Det praktiska testet för varje föreslagen AI-kontroll är en enda fråga: vilket av dessa tre lager upprätthåller den? Om svaret är modellagret är kontrollen en förhoppning. Om svaret är "systemprompten" är det ett förslag inuti modellagret, vilket är värre än en förhoppning eftersom det kommer med dokumentation som hävdar motsatsen.

Identifiera: vad en agent faktiskt avger

Detektering för agenter bygger på en annan uppsättning signaler än detektering för människor. Det finns ingen inloggningsanomali att korrelera. Det som i stället finns är en förfrågningsström med ovanligt rik struktur, och fyra familjer av signaler som är värda att larma på.

• Volym och form på verktygsanrop. En agent som plötsligt anropar ett filinläsningsverktyg fyrtio gånger i en och samma uppgift, eller vars verktygssekvens ändras från tre steg till trettio, är värd en närmare titt – inte för att den är illasinnad, utan för att fördelningen har förskjutits.

• Innehållets ursprung vid gränsen. Vilken text i prompten som kom från användaren, vilken från hämtning, vilken från ett verktygsresultat och vilken från minnet. Det mesta av upptäckten av promptinjektion reduceras till "instruktionstext förekom i en kanal som bara ska bära data", och du kan inte beräkna det om inte gatewayen märker ursprung vid ingången.

• Utgående trafik och gränser för omfång. Förfrågningar till destinationer utanför tillåtlistan, läsningar av sökvägar utanför omfånget, försök att använda autentiseringsuppgifter utanför deras avsedda tjänst. Detta är signaler med hög precision och de är billiga, eftersom miljön redan vet vad som var tillåtet.

• Kostnader och latens som proxy. En skenande loop och en kompromettering ser båda ut som en kostnadskurva som ändrar lutning. Budgetvarningar är den minst glamorösa upptäcktsmetoden i stacken och bland de som snabbast betalar sig.

Det som medvetet saknas i den listan är en klassificerare som ombeds bedöma huruvida en completion var skadlig. Det är den detektionsidé som team tar till först och den som åldras sämst: den driver med modellen, den har en falskpositivfrekvens som lär dina analytiker att ignorera den, och den ger dig inget att lägga i en runbook.

Begränsa: de tre reglagen som stoppar en dålig körning

Inneslutning för en agent är enklare än det ser ut, eftersom tre rattar täcker nästan allt. Budget begränsar vad en körning kan spendera, vilket begränsar både ekonomisk skada och sprängradien för en loop. Omfattning begränsar vad en körning kan röra vid – verktygen som är aktiverade för uppgiften, sökvägarna, tenantarna. Sandbox begränsar hur länge den kan köra och vad den kan nå medan den kör. Alla tre är gateway- eller miljöinställningar, vilket är ett annat sätt att säga att de är tvingande.

Den designprincip som spelar roll är uppdragsspecifik omfattning snarare än agentspecifik omfattning. En agent med en varaktig behörighetsuppsättning är en agent vars behörigheter kommer att ackumuleras tills någon granskar dem; en agent som får en uppdragsspecifik autentiseringsuppgift under ett uppdrags varaktighet har en gräns som upphör av sig själv. Det andra alternativet är mer arbete att bygga och mycket billigare att försvara.

Det är också där en gateway gör skäl för namnet. Kontroller som ligger framför varje modellanrop – verktygs- och MCP-anrop som utvärderas innan de körs, innehållspolicy och maskering av personuppgifter som tillämpas innan begäran faktureras – är samma kontroller oavsett om modellen bakom dem är den du använde förra kvartalet eller den som lanserades förra veckan. Den kontinuiteten är själva produkten: inte ett bättre filter, utan en plats där filtret kan bo som inte flyttar sig när modellen gör det.

Återställ: spela upp igen, patcha, testa igen

Återställning efter AI-incidenter har en fördel jämfört med återställning efter nätverksincidenter: hela körningen spelas vanligtvis in. Prompt, kontext, verktygsanrop, modellsvar, tidsangivelser – om gatewayen loggade dem kan incidenten spelas upp, vilket är en starkare utgångspunkt än vad de flesta forensiska utredningar får.

Replay fyller tre syften i följd. Det fastställer vad som faktiskt hände, i stället för vad transkriptet antyder hände efter att flera personer har sammanfattat det. Det identifierar den kontroll som borde ha utlösts, vilket är skillnaden mellan att åtgärda ett symtom och att åtgärda en gräns. Och det tar fram regressionsfallet: en inspelad indata som nu måste blockeras, körd mot den nya konfigurationen för att bevisa att den blockeras.

Patch-steget är där blå team oftast siktar fel. Om fyndet gällde ett modellbeteende ligger alla tillgängliga motåtgärder utanför modellen – en minskning av omfattningen, ett filter i gatewayen, en behörighet som tagits bort från miljön. Om fyndet gällde ett systembeteende ligger åtgärden i konfigurationen och regressionstestet är billigt. Oavsett vilket är återtest inte valfritt, eftersom både åtgärden och modellversionen förändras, och en kontroll som verifierades mot förra månadens build är ett påstående om förra månaden.

Repeterar dagen då det inträffar

Ett runbook-dokument som aldrig har lästs under press är ett dokument, inte en förmåga. Den övning som lönar sig är snäv och specifik: ta en trolig agentincident, gå igenom den från början till slut och mät tiden för varje steg. Vem upptäcker den? Hur lång tid tar det innan en människa tittar på rätt loggrada? Vem kan stoppa körningen — en namngiven person eller en kommitté? Vem kan återkalla autentiseringsuppgiften, och hur lång tid tar det innan återkallandet har slagit igenom? Vem beslutar om någon utanför företaget ska meddelas?

Två av de frågorna får team att gå bet på ett förutsägbart sätt. "Vem kan stoppa körningen" fallerar när stoppandet kräver någon som sover, så svaret måste vara en mekanism snarare än en person – ett budgettak eller en nödstopp som en jouringenjör kan aktivera på egen hand. "Hur lång tid tar återkallandet" fallerar eftersom autentiseringsuppgifter ofta cachas i komponenter som inte fanns i diagrammet.

Att läsa arkivet är den billigaste formen av repetition som finns, eftersom det låter dig ärva andra människors incidentstruktur i stället för att uppfinna din egen. Ta en handfull poster som liknar din driftsättning och ställ de tre frågorna ovan för var och en. De poster där du inte kan svara på dem är luckorna i din runbook, och du hittade dem före incidenten i stället för efter.

Asymmetrin som är värd att säga rakt ut

Red teaming och blue teaming är inte symmetriska aktiviteter och bör inte budgeteras som om de vore det. En red team-körning är tidsbegränsad av ett schema och producerar en uppsättning fynd som förlorar i värde i takt med att målet förändras. Ett blue teams kontroller består, förstärks och är det enda som faktiskt står mellan en dålig indata och ett dåligt utfall. Ett uppdrag kan hitta en gräns; bara det andra kan hålla den.

Vilket gör den ärliga standarden för ett blått team oglamorös och kontrollerbar. För varje kontroll du hävdar bör du kunna namnge lagret som upprätthåller den, loggraden som bevisar att den utlöstes, larmet som talar om för dig när den inte gjorde det, och personen som kan stänga av körningen. Fyra meningar. Om en av dem saknas är kontrollen ett policydokument, och policydokument läser inte förfrågningskroppar.