Klokken er tre om natten, og betalingssiden fejler. Et stigende antal virksomheder lader i dag en AI-agent tage den første vagt. Men agenten står med et valg, som dens designere har truffet længe før alarmen gik: skal den handle gennem klassiske API'er eller gennem MCP?
Det spørgsmål behandler The New Stack i en ny artikel om incident-håndtering, og svaret er mere nuanceret end debatten normalt tillader. MCP er ikke en afløser for API'er. De to teknologier har hver deres rolle - og blander man dem sammen, bygger man enten et system der er for langsomt, eller et der er for farligt.
To teknologier, to roller
Et API er en struktureret kontrakt: ét system beder et andet om data eller udløser en bestemt handling. Når overvågningsværktøjet henter metrikker fra databasen, eller CI/CD-pipelinen ruller ny kode ud, er det API'er der arbejder. Forudsigeligt, hurtigt og ens hver gang.
MCP - Model Context Protocol - er noget andet. Det er en protokol designet til at koble AI-agenter til eksterne datakilder og værktøjer gennem én standardiseret grænseflade. Pointen er ikke at erstatte API'erne nedenunder, men at lægge et lag ovenpå, hvor en agent selv kan finde og kombinere kontekst fra mange systemer uden en foruddefineret integration til hvert enkelt.
Forskellen lyder teknisk, men den afgør hvem der bestemmer rækkefølgen. I et API-workflow har et menneske på forhånd kodet hvert skridt. Med MCP vælger agenten selv sine skridt undervejs.
API'et vinder når der skal handles
Under selve afværgelsen af et nedbrud - rollback, failover, genstart - er der ikke plads til fortolkning. Incident-teams har brug for handlinger der er hurtige, ens og fungerer under høj belastning. Her er deterministiske API-workflows det rigtige værktøj, og et AI-lag ovenpå tilfører mest risiko.
API-integrationer har også en compliance-fordel. Eksplicitte autentificeringsflows, detaljerede audit-logs og granulære rettigheder er præcis det, revisorer efterspørger. Det bliver kun vigtigere herhjemme: EU's AI-forordning kræver fra august 2026 automatisk logning, der gør det muligt at rekonstruere AI-assisterede beslutninger i højrisikosystemer.
MCP vinder når der skal forstås
Styrken ved MCP viser sig i minutterne før: triage, diagnose og undersøgelse. Det er her, responders normalt taber tid på at hoppe mellem seks-otte forskellige værktøjer for at samle et billede af situationen.
Med MCP kan en responder spørge i naturligt sprog: "Hvorfor stiger checkout-fejlene i EU?" Agenten henter incident-detaljer fra vagtplatformen, hændelsesdata fra overvågningen, seneste deployments og tråden fra Slack - og præsenterer et samlet bud på sandsynlige årsager og næste skridt. Den slags tværgående kontekstindsamling er netop hvad MCP-baseret observability for AI-agenter handler om.
Det virker også den anden vej. Agenten kan foreslå en statusopdatering til kommunikationskanalen og en note på incidenten, vise et udkast, og først udføre begge dele når et menneske har godkendt. Udforskende, brugerstyret, med godkendelse indbygget.
Rollefordelingen kan koges ned til én sætning: API'er til de repeterbare handlinger, MCP til den udforskende forståelse.
Sikkerheden halter efter
Der er en grund til at være påpasselig med at give agenter frie hænder. MCP-adoptionen er løbet hurtigere end sikkerhedsarbejdet. En analyse fra Trend Micro fandt næsten 500 MCP-servere eksponeret direkte på internettet helt uden autentificering, og OWASP har i år udgivet en dedikeret top 10 over MCP-sårbarheder - fra tool poisoning til utilstrækkelig rettighedsstyring.
Selve MCP-specifikationen anerkender problemet: der bør altid være et menneske i loopet med mulighed for at afvise et værktøjskald. I praksis betyder det OAuth 2.1 med korte tokens frem for statiske nøgler, risikoklassificering af hvert værktøj og obligatorisk godkendelse af alt der er destruktivt eller irreversibelt.
Det er ikke argumenter mod MCP. Det er argumenter for at lade protokollen gøre det, den er god til - læse og forstå - og holde de skarpe knive bag deterministiske API'er med menneskelig godkendelse.
Hvad betyder det for jeres beredskab?
Markedet bevæger sig hurtigt. PagerDuty har lanceret en SRE-agent der kan sættes direkte på vagtplanen, og på tværs af platforme rapporterer teams i gennemsnit knap 18 procent kortere løsningstid med AI-drevet incident-håndtering - de bedste implementeringer langt mere. Som vi tidligere har skrevet, kræver agentbaseret IT-drift forberedelse længe før agenterne får adgang til produktionen.
Der er også en driftsøkonomisk side. Hver MCP-server, agenten kobles til, indlæser sit fulde værktøjskatalog i modellens kontekst ved hver session - og som vi har vist, kan token-forbruget hurtigt løbe løbsk, når overhead som det får lov at vokse ukontrolleret. Giv agenten adgang til de værktøjer, beredskabet faktisk bruger, ikke alt hvad der findes.
En brugbar tommelfingerregel, når I designer jeres setup: Kan opgaven beskrives som et fast workflow, der skal køre ens hver gang? Så er det et API-job. Kræver opgaven at samle og fortolke kontekst på tværs af systemer? Så er det et MCP-job - med et menneske til at trykke på de knapper, der ikke kan fortrydes.
Virksomheder der får den rollefordeling rigtig, får AI-agenter der aflaster deres beredskab. De der ikke gør, får enten en langsom chatbot eller en autonom risiko.
Kilde: The New Stack
