Jeg erstattet en prosess, ikke en person

Jeg automatiserte ikke en sikkerhetsanalytiker bort fra jobben. Jeg automatiserte de 15 timene i uka de taper på sårbarhetstriagering. Slik er agenten bygget — og de fire stedene den prøver å gjøre noe dumt.

Overskriften har rammen bakvendt

«KI tar jobben din» er feil måleenhet. Jobber er ikke monolitter en agent sluker hele. Jobber er knipper av prosesser, og de fleste av de prosessene er rutineslit.

I konsulentarbeidet mitt har jeg sett sikkerhetsteam bruke 15+ timer i uka på sårbarhetstriagering — lese skanneroutput, grave i CVE-detaljer, avgjøre hva som faktisk betyr noe — før en eneste fiks er skrevet. Ingen tok den jobben fordi de elsker triagering. De tok den for de vanskelige delene: dømmekraft, arkitektur, den rare hendelsen klokka to om natta.

Så jeg bygde ikke en agent for å være sikkerhetsingeniør. Jeg bygde en som spiser triageringen. Den kjører på et skjema mot min egen infrastruktur: den skanner, rangerer, foreslår fikser, bruker de trygge og overlater resten til meg. Under er anatomien — og, mer nyttig, de fire stedene den prøver å gjøre noe dumt, og hvordan jeg stopper den.

Velg en prosess, ikke en jobb

Den egentlige ferdigheten i å bruke agenter er ikke prompting. Det er avgrensning — å skjære en velformet prosess ut av en uklar jobb. Bommer du på dette, redder ingen modell deg.

En prosess er et godt mål for en agent når den ser slik ut:

Sårbarhetstriagering scorer godt på hver rad. «Vær sikkerhetsarkitekten vår» scorer dårlig på alle. Pek en agent mot det andre, og du får et selvsikkert, plausibelt, uansvarlig rot. Pek den mot det første, og du får uka di tilbake.

Formen på en agent som gjør ekte arbeid

Feilen er én gigantisk prompt som «håndterer sikkerhet». Ekte arbeid trenger en liten pipeline av smale roller, der hver gjør én oppgave og sender strukturert output videre — akkurat den triage → research → utbedring-delingen jeg har skrevet om før.

I praksis: en skanner (Trivy, Grype) produserer funn; en lokal modell (Devstral via LM Studio) rangerer dem og luker ut støyen; Claude CLI skriver selve fiksen; en planlegger (systemd) kjører løkka; og hvert steg skriver til en logg du kan lese senere. Billig resonnering blir lokalt, dyr resonnering går til en frontier-modell, og ingenting er en svart boks.

Men arkitekturen er ikke poenget. Kontrollflyten er:

# The shape that matters: propose -> gate -> act. Never act -> explain.
findings = scan()                       # what's vulnerable
plan     = triage(findings)             # rank, drop false positives

for fix in plan.high_confidence:        # the boring 80%
    if low_risk(fix) and tests_pass(sandbox(fix)):
        apply(fix); log(fix)            # automatic, fully audited
    else:
        queue_for_human(fix)            # the risky 20%

notify(summary)                         # what I did, what I left for you

En agent som handler og deretter forklarer er en risiko. En agent som foreslår, blir sjekket gjennom en sperre, og så handler er en kollega. Hele designet ligger i den rekkefølgen.

De fire stedene den prøver å gjøre noe dumt

Det er her ingeniørarbeidet faktisk ligger. Hver av disse er en ekte feilmodus, ikke noe hypotetisk.

1. Den hallusinerer en fiks — eller returnerer søppel. Spesielt lokale modeller gir deg selvsikker, feilformatert output. Derfor er modelloutput upålitelig input. Agenten min parser modellens JSON defensivt og forkaster alt som ikke validerer, i stedet for å handle på en halvferdig plan. Er strukturen feil, skjer ikke fiksen.

2. Den vil handle på en falsk positiv. Skannere overrapporterer. En ivrig agent «fikser» gjerne ting som aldri var ødelagt, og maler systemene dine i tomgang. Sperren er alvorlighetsgrad pluss verifisering: bekreft at sårbarheten er ekte og nåbar før noe røres.

3. En «fiks» ødelegger tre andre ting. «Bare oppdater biblioteket» høres enkelt ut helt til vedlikeholderen endret API-et og to tjenester faller. Ingenting tas i bruk automatisk uten å bestå tester i en sandkasse først, og hver endring har en rollback. Lavrisikofikser går automatisk; alt med skadevidde venter på et menneske.

4. Den har mer tilgang enn den trenger. En autonom agent med vide rettigheter er det farligste i stacken din — den kjører med dine rettigheter, og én dårlig instruksjon (eller en prompt-injeksjon i noe den leser) blir en ekte handling. Minste privilegium, isolasjon og en logg over hver kommando er ikke valgfritt. Dataplassering og lokale modeller redder deg ikke her; tilgangskontroll gjør det.

Mønsteret under alle fire: agenten foreslår, en sperre avgjør, og et menneske eier alt som er risikabelt. Automatiser de kjedelige 80 %. Hold øye med de 20 %.

Hva som forblir menneskelig

Augmentering er ikke et mykere ord for erstatning. Det er en arbeidsdeling.

Agenten eier slitet: lesingen, rangeringen, standardfiksen, papirarbeidet. Mennesket eier det agenten ikke kan stoles på med — dømmekraft i grensetilfeller, godkjenningene med stor skadevidde, systemdesignet, og ansvaret når noe går galt. Noen er fortsatt ansvarlig. Det flyttes ikke til modellen.

Analytikeren hvis triagering jeg automatiserte, mistet ikke jobben. De mistet den delen av jobben som fikk dem til å ville slutte. Samme person, som gjennomgår i stedet for å slite.

Hva dette generaliserer til

Sårbarhetshåndtering er bare det reneste eksemplet — stort volum, målbart, mulig å sperre. Samme oppskrift overføres til enhver prosess formet som den:

• triagering av hendelsesrespons
• førstegangs kodegjennomgang
• provisjonering av infrastruktur
• pass på datapipelines
• eskalering av supporthenvendelser

Finn en prosess som koster noen 15 timer i uka. Gi den foreslå-sperre-handle-behandlingen. Hold mennesket på de risikable 20 %. Gjenta.

Konklusjonen

Spørsmålet var aldri «vil en agent erstatte deg». Det er «hvilke av ukene dine slutter du å kaste bort» — og «er du den som designer agenten, eller den det designes rundt».

En agent erstattet ikke analytikeren. Den ga dem torsdagen tilbake.

Viktigste punkter

• Agenter erstatter ikke jobber; de erstatter prosesser. Ferdigheten er å avgrense den rette.
• Gode mål er repetitive, verifiserbare, målbare og mulige å sperre. Dårlige mål er smaksbaserte og irreversible.
• Bygg en pipeline av smale roller, ikke én megaprompt. Billig resonnering lokalt, dyr resonnering på frontier.
• Sikkerheten ligger i rekkefølgen: foreslå → sperre → handle, aldri handle → forklare.
• Behandle modelloutput som upålitelig, test før du tar i bruk, behold rollbacks, og håndhev minste privilegium.
• Automatiser de kjedelige 80 %; behold et menneske — og ansvaret — på de 20 %.

---

Jeg er en løsningsarkitekt spesialisert på KI/ML, sikker infrastruktur og agentautomatisering. Gjennom AI-Flow hjelper jeg organisasjoner med å sette KI-agenter i arbeid på ekte prosesser — uten å gi fra seg nøklene.

#KIagenter #Automatisering #DevSecOps #KI #HumanInTheLoop #AgentEngineering