AWS har udgivet første del af en teknisk guide til Bedrock AgentCore Observability, et sæt værktøjer til at forstå hvad AI‑agenter gør i drift, ikke bare om de svarer. Timingen er slående. Samtidig viser Tenet Security, opsummeret af VentureBeat, at agenter kan kapres gennem tilsyneladende harmløse fejlstrømme uden at en eneste alarm lyser. Det efterlader et meget lavpraktisk spørgsmål til teams med agenter i produktion: Hvad kigger man på, når ingenting fejler højt, men noget alligevel går helt galt?
Lad os være ærlige. De fleste opdager agentfejl, når en bruger klager, eller når en downstream‑proces begynder at opføre sig mærkeligt. Det er for sent. AWS’ nye materiale og de aktuelle sikkerhedsfund peger samme vej. Observability for agenter er ikke pynt. Det er drift og sikkerhedskritisk.
Problemet i produktion i dag
AWS beskriver tre gennemgående fejlmønstre i produktion: kvalitet, pålidelighed og effektivitet. Kvalitetsfejl er de drilske. Agenten afleverer et svar, det ser plausibelt ud, men er forkert. Ingen exceptions, ingen rødt dashboard. Bare forkert. Reliability‑fejl spænder fra mistede credentials til brudt kontekst, hvor en samtale starter forfra midt i et langt forløb. Effektivitetsfejl er stille budgetdræbere, for høj latenstid eller unødvendig tokenbrug, som sniger sig ind over uger.
Hvorfor standard logs ikke rækker
Traditionelle applikationslogs og CPU‑grafer viser symptomerne. Ikke beslutningerne. Man ser latenstid, antal kald, måske nogle HTTP‑koder. Men ikke hvorfor agenten valgte et bestemt tool, hvilken mellemkonklusion den kom til, eller hvornår den gik i ring. AWS peger direkte på hullet her. Standardlogning fanger sjældent rækkefølgen af reasoning‑skridt, så man ender med at gætte.
Når fejlen ikke udløser en exception, men en stille divergens, bliver gætværk dyrt. Tænk på en agent, der henter hele dokumenter i stedet for udvalgte afsnit. Metrics viser måske stigende tokenforbrug. Men uden trace af de mellemregninger der førte til valget, forbliver årsagen uklar. Diagnosen bliver for bred, løsningen for dyr.
Hvad Bedrock Agent
Core Observability faktisk leverer
AWS beskriver tre lag af indblik: metrics, traces og strukturerede logs. I CloudWatch får man kuraterede visninger for AgentCore, som samler agentens helbred, og prompt tracing, der folder reasoning‑forløb ud i navigerbare spor. Metrics giver overblik. Traces viser den konkrete udførelsessti, herunder hvilke tools der blev kaldt med hvilke inputs og i hvilken rækkefølge. Strukturerede logs binder det hele sammen, så man kan søge på tværs af samtaler og transaktioner.
Pointen er, at sporene går ned i beslutningernes anatomi. Man kan se overgangen fra plan til handling, og hvor udfaldet af et værktøjskald påvirkede næste skridt. Det er forskellen mellem at vide at noget gik galt og at se hvor det gik galt, selv når ingen fejl blev rejst.
Walkthrough‑krav og implikationer for drift
Guiden har nogle klare forudsætninger: En konto med Bedrock AgentCore aktiveret, CloudWatch‑dashboards og basal logforespørgsel på rygraden, forståelse for IAM‑roller og politikker, samt CloudWatch Transaction Search slået til. Plus adgang til at deploye en agent. Det lyder administrativt, det er det også, men det har praktiske følger for adgangsstyring og onboarding.
I praksis betyder det, at teams skal have styr på hvem der må se reasoning‑spor, ikke kun rå logs. Compliance vil spørge til retention og sletning. Onboarding af nye udviklere kræver mere end en API‑nøgle. De skal kunne læse traces og forstå hvornår en afvigelse er kritisk. Små ting, men de ændrer arbejdsformen.
Sådan finder man de lydløse fejl
Den operationelle disciplin er forholdsvis klar, og den kan læres. Start i trace‑oversigten for den mislykkede eller bare mistænkelige transaktion. Find skiftet fra plan til første tool. Tjek inputfeltet: er der for mange eller for få parametre? Se efter gentagne plan‑justeringer uden fremdrift. Det er tegn på loop.
Når svaret er plausibelt men forkert, er opskriften at sammenholde reasoning‑trin med ground truth, måske blot et par referencefelter. Man finder ofte et enkelt trins fejlagtige antagelse, ikke et generelt modelproblem. Ved forkerte værktøjsvalg giver strukturerede logs et billede af tilgængelige værktøjer og det valgte. Retningen er tydelig: stop loopet, juster tool‑valg‑logikken, eller indfør en simpel watchdog der afbryder efter N gentagelser, selv om det føles groft.
Sikkerhed og agentjacking
Tenet Securitys agentjacking‑demonstration er værd at dvæle ved. Et fabriceret Sentry‑error‑event kunne i kontrollerede tests få en agent til at køre angriberens kode med udviklerrettigheder. Ingen alarmer. EDR, WAF, firewall og selv IAM‑reglerne fangede det ikke, for hele kæden var autoriseret. Det er præcis den kategori af stille fejl, hvor observability kan gøre forskellen mellem at famle og at forstå.
Men observability alene blokerer ikke angrebet. Det hjælper med efterforskning, med at se indsprøjtningen i trace og pege på indgangen. Det afdækker også blinde vinkler i betingelser og prompts. Alligevel mangler der en runtime‑sikring, der frakobler farlige handlinger fra eksponerede kanaler. Man må holde begge tanker i hovedet: sporbarhed for analyse, sandboxing og input‑hygiejne for forebyggelse.
Tradeoffs og begrænsninger
Mere tracing koster. Både i kroner i CloudWatch og i latenstid, når detaljeret logning og sampling skrues op. Der er også privatlivs‑hensyn. Token‑nære logs kan uforvarende opsamle følsomme oplysninger, hvis man ikke maskerer rigtigt. Det er ikke løst med et flueben. Vælg retention med omtanke.
En anden faldgrube er informationsstøj. Når dashboards bugner af events, drukner signalet. Den klassiske fejl er at samle alt og håbe at man finder mønstre senere. Bedre at vælge få, stærke indikatorer og lade resten være søgbart on‑demand. Ja, det kan føles som at skære i noget værdifuldt. Men det er drift.
Anbefalinger til implementering
Start med at aktivere Observability i et afgrænset miljø. Brug canary‑udrulning på en procentdel af trafikken, og mål både latency og CloudWatch‑omkostninger. Sæt en samplingstrategi tidligt, fx 100 procent for fejl og low‑confidence svar, 5–10 procent for alt andet. Notér hurtigt hvor støjen opstår, og skru ned igen.
På sikkerhedssiden giver det mening at knytte traces til simple detektorer for farlige mønstre: gentagne shell‑kommandoer, tool‑kald til følsomme endepunkter efter eksterne fejlindgange, eller pludselig kontekstskifte efter et Sentry‑event. IAM‑principper bør strammes omkring værktøjer. Minimer privilegier per tool, ikke per agent.
Hvornår observability ikke rækker
Nogle fejl er arkitekturfejl. Dårlige prompts, svage værktøjsgrænseflader, eller datakilder uden tydelige kontrakter. Her hjælper flere logs kun marginalt. Guardrails, human‑in‑the‑loop på de dyre beslutninger, og sandboxing af farlige handlinger er nødvendig. Observability viser hvor smertepunkterne er, men fjerner dem ikke.
Der er også domæner hvor datakvalitet styrer alt. Hvis input er støj, bliver reasoning det også. Traces kan dokumentere problemet, men løsningen ligger i bedre datarør og validering, ikke i flere metrics. Det er måske lidt kedeligt at indrømme. Men sandt.
Hvad del to bør handle om
AWS lover at næste del dækker performanceoptimering og memory management. Det er klogt. For i praksis kolliderer detaljeret observability med latency og pris. Der mangler stadig en klar drejebog for sampling ved meget høje gennemløb og for omkostningsstyring uden at miste de vigtige spor. Her er en forventning, ikke et krav, at AWS folder skaleringsmønstre og governance ud.
Et særskilt ønske er mere eksplicit håndtering af PII i prompt tracing: masking, redaction og værktøjer der gør det svært at dumpe følsomt indhold i logs ved et uheld. Den slags små værktøjsgreb, som man først opdager man mangler, når man sidder med en revisionsanmodning en tirsdag kl. 16.
Konsekvenser for governance og incident response
Observability ændrer hændelseshåndtering. Playbooks bør udvides med trace‑baseret triage. Nye SLA‑triggere som stille fejl og uventet tool‑valg bør få egne alarmer. Roller skal defineres: hvem læser traces i en krise, hvem beslutter rollback, hvem taler med compliance. Små beslutninger der forkorter minutter til indsigt.
På governance‑siden er dokumentation en gevinst. Traces gør det muligt at redegøre for hvorfor en agent handlede som den gjorde. Det hjælper internt, og det hjælper overfor tilsyn. Men det forpligter også. Hvis man kan se afvigelsen og ikke reagerer, bliver det svært at forklare bagefter.
Kilder og kildekritik
AWS’ egen blog er førstehåndsbeskrivelsen af funktionalitet og fejlmodi. Den er stærk på teknik og procedurer, men er naturligt farvet af producentens vinkel. CloudWatch‑dokumentationen er reference for kuraterede visninger og prompt tracing, og bekræfter kravet om at aktivere Observability i AgentCore for at se noget som helst. VentureBeat sammenfatter Tenet Securitys agentjacking‑fund, som er kontrollerede tests, ikke masseudnyttelse i det fri. Det er vigtigt at skelne. Truslen er reel, men data er PoC, ikke incidensstatistik.
Der er ingen åbenlys modsigelse mellem kilderne. De belyser hver sin del. Et hul, der står tilbage, er fraværet af uafhængige feltcases der viser Bedrock AgentCore Observability i stor skala. Også omkostningsestimater for fuld tracing i kæmpe drift mangler. Indtil de findes, bør teams måle selv i pilotprojekter.
Tjekliste til samme dag
- Slå Observability til i AgentCore for et testmiljø, og verificér at CloudWatch Transaction Search virker.
- Opsæt kuraterede CloudWatch‑views, og gem to søgninger: uventet tool‑valg og gentagne plan‑trin uden fremdrift.
- Etabler sampling: 100 procent for lave‑tillidssvar og fejl, lav procent for resten.
- Definér retention og redaction for logs, især hvis der kan optræde PII.
- Indfør canary‑udrulning med måling af latenstid og CloudWatch‑omkostninger uge for uge.
- Stram IAM på værktøjer, ikke kun på agenten. Mindste privilegie pr. tool.
- Automatisér regressionstests for agentbeslutninger, inklusiv simple adversariale cases fra eksterne fejlindgange.
- Opdatér incident playbooks med trace‑triage og ansvarspunkter.
Perspektiv
AI‑agenter fejler på en ny måde. Stille. Bedrock AgentCore Observability adresserer netop det ved at vise hvordan beslutninger bliver til, ikke kun hvad der kom ud. Det gør en forskel i drift og i sikkerhed, især når angreb kan ride med på godkendte fejlrør. Men det er kun begyndelsen. Uden god arkitektur, stramme rettigheder og lidt sund skepsis overfor alle smarte integrationer, ender man alligevel i mørket. Man opdager først forskellen, når man sidder med sporene i hænderne.
