Det er midt om natten. En observability-agent ser en anomalyscore på 0,87. Tærsklen er 0,75. Den gør, hvad den har lov til: ruller en service tilbage. Klokken er 03:12. Tre minutter senere begynder supportkanalerne at lugte af kold kaffe og panik. Fire timer efter er driften oppe igen, men den reelle årsag viser sig at være et planlagt batch-job, som agenten aldrig havde set før. Modellen gjorde som trænet. Systemet svigtede. Kilde: VentureBeat. Og casen er desværre ikke unik.
Vi har selv siddet i et kontor på Havnegade en tirsdag morgen og kigget på grafer, der lignede et seismogram. Den slags pulsstigning sætter sig. For os blev det en lærestreg: Observability er nødvendigt, ja. Men ikke nok, når autonome agenter handler hurtigt og selvsikkert – og forkert.
Hvad der faktisk skete
VentureBeat beskriver forløbet nøgternt: En produktionsagent, hvis job er at opdage infrastrukturafvigelser og reagere passende, registrerer en score på 0,87 – over en defineret 0,75-tærskel. Agenten har adgang til rollback-servicen inden for sine rettigheder og bruger den. Resultat: fire timers nedetid. Den udløsende faktor var et skemalagt batch-job, der ikke var i agentens verdensbillede. Ingen ondsindet påvirkning. Ingen modelbug. Bare et system, der ikke var testet for ukendte forhold (VentureBeat).
Kernen er, at modellen opførte sig inden for sine regler. Fejlen lå i teststrategien og i manglen på driftsscenarier uden for normalbilledet. Ingen eskalering. Ingen “spørg først”. Kun automatisk handling – selvsikkert og forkert. Hårdt at læse. Bedre at lære af.
Hvor testen slog fejl
Ingen havde sovet i timen. Ifølge samme kilde havde teamet valideret happy-path adfærd, kørt belastningstests og gennemgået sikkerheden. Det, der manglede, var spørgsmålet vi alt for sjældent stiller i 2026: Hvad gør agenten, når verden viser den noget, den aldrig har set før (VentureBeat)?
Der blev ikke testet for ukendte mønstre, overlappende jobs eller – og det ser vi oftere nu – samspil mellem flere agenter, hvor den enes “fornuftige” beslutning bliver den andens giftige input. Ingen ond vilje. Bare fravær af tests, der måler afvigelse fra hensigt, ikke kun fra succes.
Konteksten i 2026
Adoptionen løber. Kontrollen halter. Gravitees State of AI Agent Security 2026 rapporterer, at 80,9 procent af tekniske teams er videre end plan og over i aktiv test eller produktion, mens kun 14,4 procent går live med fuld sikkerheds- og IT-godkendelse. Rapporten bygger på 900+ respondenter, hvilket gør tallene brede – men ikke universelle (Gravitee).
Mange samtaler i bestyrelseslokaler kredser om identitet og observability. Begge vigtige. Men spørgsmålet om, hvorvidt agenten følger hensigten, når produktionen ikke spiller efter bogen, får for lidt plads. VentureBeat peger præcis på det hul. Det gør vi også.
Systemniveau-problemet
Man kan have en fint tunet model og stadig få et systemnedbrud. Det er ikke et paradoks. Tre antagelser går igen og går galt: vi forventer determinisme, isolerede fejl og entydige “done”-signaler. Agenter er probabilistiske, fejl forplanter sig på tværs af kæder, og “task completed” kan betyde “jeg gjorde noget, det virkede rigtigt”.
VentureBeat refererer til et paper fra februar 2026, hvor forskere fra Harvard, MIT, Stanford og CMU dokumenterer, at velafstemte agenter i multi-agent miljøer kan drive mod manipulation eller falsk opgaveløsning alene pga. incitamentstrukturer – uden fjendtlige prompts. Vi refererer her via VentureBeat og anbefaler at konsultere originalen ved implementering. Pointen står: systemdesign og testmodenhed afgør sikkerheden, ikke kun modelalignment.
Intent-baseret chaos testing
Kaostest er ikke nyt. Netflix’ Chaos Monkey er gammel vin i ny flaske. For agenter skal vi måle afvigelse fra hensigt, ikke bare fra succes. Intent-baseret chaos testing betyder, at man injicerer “ukendte” produktionstilstande og tjekker, om agenten stadig følger formålet: alarmerer korrekt, eskalerer ved tvivl og holder igen ved høj påvirkning.
Praktisk ser vi fem ting virke: canaries med lille blast radius; shadow mode, hvor agenten kun foreslår handling; simulated unknowns, hvor batch-jobs, timeouts og halve svar fra upstream systemer skrues op med vilje; intent fuzzing, hvor mål og constraints varieres for at se, hvor politikker knækker; og menneske-i-løkken ved høj konsekvens. Det sidste koster lidt latency. Det køber nattesøvn.
Spec-driven development i praksis
En anden vinkel handler om koden, der orkestrerer agenter og guardrails. MarkTechPost beskriver spec-driven development i 2026 som at vende processen om: strukturér krav og design som sandhedskilden, og lad koden blive genereret ud fra den. Artefakter som requirements.md, design.md og tasks.md – ofte i EARS-notation til entydige acceptance criteria – tvinger teamet til at tænke kanter før første commit (MarkTechPost).
Vi har oplevet, at SDD dæmper “hurtigt, men forkert” kode, især når AI-assisterede IDE’er er blevet gode til at spytte noget ud, der virker – lige indtil det rammer resten af systemet. SDD gør antagelser synlige, forhandler roller på forhånd og skaber kroge til test, observability og politikker.
Hvorfor det betyder noget i driften
Natten er farlig. Ikke fordi mennesker sover, men fordi systemer kører batch, backup, reindeksering og små ritualer, der ligner fejl set fra det forkerte hjørne. En agent uden kontekst eller launch windows kan let ramme bremsen på det værst tænkelige tidspunkt. Canary og shadow-deployments gør skaden lokal. Launch windows og change freezes efter midnat gør den sjældnere.
I CI/CD bør rollback ikke være et frit skud om natten. Indfør et “safe rollback guard”-mønster: 1) begrænsede rettigheder efter kl. 22, 2) krav om menneskelig godkendelse over en defineret blast radius, 3) staging-simuleringer af rollback i kendte batch-vinduer, 4) rate limits for automatiske rollback, 5) audit-krav før eksekvering.
Observability der hjælper mennesker
Signal-fusion betyder noget: metrics, logs og traces i samme billede. Men koblingen til årsag er afgørende. Vi anbefaler causal tracing i audit-logger – ikke kun events. Giv beslutninger et trace-id på tværs af agentpipelines. Knyt forklaringen til handlingen. Når du senere spørger “hvorfor rullede du tilbage?”, skal der være et svar, ikke bare en score.
Thresholds bør være adaptive og kontekstbevidste. Batchvinduer, kendte datastorme og planlagte driftsopgaver skal vægte. Alarm-korrelation skal dæmpe støj, ikke skjule ild. Vi snublede selv første gang, da et kundesystem foldede et BI-job ud kl. 02:05, og vores testagent råbte “ild” i biografen. Shadow mode og en catch-and-hold-eskalering skar senere de automatiske oprydninger ned markant – væsentligt, som i at folk sov igen.
Konkrete tiltag 30, 90, 180 dage
Vi holder det jordnært. 30 dage: Minimer permissions for agenter med tids- og kontekstgrænser. Indfør shadow mode for alle højpåvirkningshandlinger uden for kontortid. Læg audit-logs med causal traces på plads først – selv hvis UI’et må vente en sprint. Mål: andel handlinger uden trace-id = 0; % højpåvirkningshandlinger i shadow = 100.
90 dage: Byg canary- og rollback-guardrails i CI/CD. Tilføj adaptive thresholds med kendte batchkalendere. Implementer alarm-korrelation, der binder metrics til beslutningstræer. Start en lille intent-fuzzing-suite i staging og mål, hvor ofte agenter eskalerer frem for at handle. Mål: rollback false-positive-rate nedadgående; % automatiske rollbacks uden human-in-loop under defineret tærskel; MTTD for reelle afvigelser stabil eller bedre.
180 dage og governance
180 dage: Rul en intent-baseret chaos-plan ud i produktion, begynd med lavrisiko-tjenester. Indfør SDD-light: krav- og designartefakter før nye agent-roller eller større ændringer. Formalisér menneske-i-løkken-policy med klare konsekvenstærskler og on-call-ansvar. Dokumentér politikversioner i auditloggen.
På governance-siden må rollerne skæres klarere. CTO og CISO ejer politikkerne og undtagelserne. SRE ejer runtime guardrails og incident-runbooks. Legal/compliance ejer auditerbarhed og retention. Brug Gravitee-tallene som spejl: Når kun 14,4 procent går live med fuld godkendelse, er det ikke et enkeltteam-problem – men en procesopgave.
Tradeoffs og begrænsninger
Der er omkostninger. Kaostest tager tid og miljøer. Shadow mode og menneske-i-løkken koster latency, og nogle flows vil føles tungere. Der er også en risiko for overvågningsblindhed: For mange grafer. For mange alarmer. Sæt få, klare SLO’er for agentadfærd: andel eskalering ved usikkerhed, MTTD for driftsafvigelser, andel falske positive handlinger og “blast radius per hændelse”.
Og nej, intent-baseret chaos og SDD ændrer ikke organisatoriske incitamenter af sig selv. Hvis forretningen presser på for at automatisere alt uden kontrolpunkter, vinder tempoet. Indtil det taber en nat.
Sikkerhed, compliance og regulering
Automatiske rettelser uden sporbar forklaring kan blive et compliance-mareridt. Kræv immutable audit-logs, hvor beslutning, input og politikversion logges sammen. Kræv explainability hooks – selv en kort beslutningsnøgle: “score 0,87 > 0,75, politik p-rollback-01, ingen batchkontekst fundet”. Det redder ikke alt. Men det gør revision mulig.
Regulatoriske rammer og interne godkendelsesprocesser kan i praksis begrænse graden af fuld autonomi i visse domæner. Det er sundt. Indret governance derefter: højpåvirkningshandlinger kræver menneskelig godkendelse, tydelig opgaveadskillelse og dokumenterede runbooks. Og ja, rate limits. Et lavpraktisk loft over antal automatiske rollback per time.
Et kort ord om Snillds leverancer
Vi kommer ikke med en tryllestav. Vi møder jer i drift. Typisk leverer vi tre ting: en observability-audit med fokus på causal traces og alarm-korrelation, en CI/CD-hardening med canary, shadow og safe rollback guards og en SDD-onboarding, hvor krav og acceptance-criteria gøres operationelle. Rådgivning, ikke reklame.
I en anonym kundecase indførte vi shadow mode for højpåvirkningshandlinger og catch-and-hold med eskalering. Det fjernede en betydelig mængde automatiske oprydninger om natten og skabte ro i vagtlaget. Vi kunne lugte forskellen – færre kolde pizzabakker på skrivebordet om morgenen.
Hvad forskningen siger
Det nævnte februar 2026-paper peger på incitamenter som årsag til agent-drift i multi-agent miljøer – også uden fjendtlig påvirkning. Her refererer vi via VentureBeat og anbefaler, at teams læser paperet direkte, før de designer belønningsstrukturer eller samarbejdsmønstre mellem agenter. Systemfejl kan opstå, selv når hver agent “gør det rigtige”.
For os betyder det, at test ikke kun er input-output. Det er også tests af incitamenter og målkonflikter. Giv to agenter delvist modstridende mål i staging og se, hvor de bryder. Hellere der end i produktion.
Hvad vi ikke ved endnu
De tekniske rollback-detaljer i den beskrevne hændelse er ikke offentligt dokumenteret i kilden: API-design, permission-scope, rate limits og hvem der må initiere hvad. Her ville følgende artefakter styrke analysen: API- og change-logs, en permission-matrix for agenten, rate-limit-konfiguration, eskaleringsregler og en præcis incident-tidslinje med korrelerede alarmer.
Vi mangler også en offentlig benchmark for effekten af intent-baseret chaos testing og SDD på hændelsesrater. Gravitee-tallene siger noget om kløften mellem adoption og kontrol, men ikke hvorfor 85,6 procent går live uden fuld godkendelse. Tidspres? Ressourceknaphed? Kultur? Her mangler data – og interviews.
Konklusion uden pynt
Lad os være ærlige. Observability alene redder jer ikke fra en selvsikker agent med forkerte antagelser kl. 03:12. Intent-baseret chaos testing og SDD er ikke smukke overskrifter, men de virker, fordi de tvinger spørgsmålene frem, før brugerne gør det. Start småt. Gør det i shadow. Læg sporbarhed ind, før I åbner for handlinger.
Man opdager forskellen, når man sidder med det i hænderne. Og når natten er stille.
