CLI, API, MCP eller computer use? Sådan vælger du adgang til din AI-agent

Vælg CLI først. Findes der ingen brugbar CLI, så kig efter et API. Derefter kommer MCP. Computer eller browser use er min sidste udvej. Den rækkefølge giver mig den bedste balance mellem hastighed, tokenforbrug, pris, sikkerhed og muligheden for at flytte løsningen mellem forskellige AI-agenter.

Det her er trin 2 i mit framework til at skalere en virksomhed med AI uden at ansætte. I trin 1 kortlagde jeg 86 af mine arbejdsprocesser på 38 minutter. Nu skal hver proces have den adgang, som en AI-agent behøver for at udføre arbejdet.

Mange behandler adgang som en teknisk detalje, der giver sig selv. Så begynder de at bygge, før de har forstået, hvilke data agenten skal bruge, hvilke systemer den skal læse og skrive i, og hvor et menneske skal godkende. Det er her, de fleste taber tråden.

Trin 2: Lav en adgangs-audit, før du bygger

Efter proces mapping står du med en liste over de opgaver, der optager din virksomhed. Listen rummer kampagnemails, CRM-opdateringer, bilag eller research. En opgavetitel fortæller ikke agenten, hvordan den kommer fra start til slut.

Tag én proces ad gangen. Kortlæg de data og systemer, som opgaven rører. Find den adgang, der allerede findes, og skriv de huller ned, som stopper end-to-end drift.

Jeg kalder det en adgangs-audit. "Datapunkter" bliver for snævert, fordi agenten skal bruge mere end data. Den skal kunne åbne et system, læse noget, skrive noget, flytte noget og nogle gange trykke på en knap i en brugerflade.

De otte spørgsmål i din adgangs-audit

Jeg stiller de samme otte spørgsmål til hver arbejdsopgave:

1. Hvilket data eller artefakt starter opgaven med?
2. Hvilke systemer skal læses?
3. Hvilke systemer skal skrives til?
4. Hvilken adgangstype findes?
5. Hvilke credentials kræves?
6. Hvad er risikoniveauet?
7. Hvor skal mennesket godkende?
8. Hvad mangler for end-to-end drift?

Svarene bestemmer, hvordan du skal producere løsningen. En LinkedIn-URL kan være startpunktet. Processen kræver så, at agenten læser opslaget i en browser, henter et billede, skriver et dokument og bygger en kampagne i et e-mailsystem. Du har allerede flere systemer og adgangsformer i én proces.

Min rækkefølge er CLI, API, MCP og computer use

Rækkefølgen er min engineering-tilgang. Jeg vurderer hastighed, tokenomics, pris, sikkerhed og platformsuafhængighed. En anden organisation kan vægte punkterne på en anden måde, men du skal vælge bevidst.

1. CLI giver agenten en kort vej til handlingen

En CLI lever i terminalen. Agenten skriver en kommando, koden udfører den deterministisk, og agenten får et struktureret resultat tilbage. Den skal ikke kigge på en skærm, gætte koordinater eller bruge et nyt screenshot for hvert trin.

CLI'en kan samle flere tekniske handlinger i én kommando. En kommando kan for eksempel hente de relevante data, filtrere dem og gemme resultatet. Agenten behøver så ikke selv at kalde fem forskellige funktioner og læse fire mellemresultater, før den kommer i mål.

Mange CLI'er bruger et API under overfladen. Forskellen ligger i den grænseflade, agenten møder. Udvikleren af CLI'en har allerede samlet endpoints, parametre og fejlbehandling i klare kommandoer. Agenten skal kende kommandoen og de argumenter, som opgaven kræver.

Det betyder færre tool calls, færre mellemresultater i konteksten og et lavere tokenforbrug. CLI'en er også let at flytte mellem horisontale agenter, fordi Claude Code, Codex og andre agent-harnesses kan arbejde i en terminal.

Jeg kigger derfor efter en CLI først. Jeg skal stadig styre credentials og rettigheder, men selve udførelsen bliver kompakt, hurtig og forudsigelig.

2. API giver præcis kontrol over rettigheder

Et API er en valid og stærk adgangsform. Agenten eller den deterministiske kode kalder en bestemt funktion i systemet og sender de parametre, som funktionen kræver.

Fordelen ligger i kontrollen. Du kan give læseadgang uden skriveadgang. Du kan give adgang til at oprette og redigere uden at give lov til at slette. De scopes gør det muligt at begrænse agentens handlerum ud fra opgavens risiko.

Udfordringen kommer, når systemet har mange endpoints. Tænk på hvert klik i Gmail som sin egen funktion. Ét endpoint søger efter en mail. Et andet læser mailen. Et tredje henter hele tråden. Andre endpoints arbejder med kladder, labels eller afsendelse.

Agenten eller din kode skal kende de relevante endpoints, deres parametre, authentication og de fejl, der kan komme tilbage. En proces kan derfor kræve en kæde af API-kald, før agenten har læst og skrevet det, som et menneske klarer gennem få skærmbilleder.

Jeg vælger API efter CLI. API'et giver en stærk sikkerhedsmodel og præcis adgang, men du skal selv samle de nødvendige endpoints til et brugbart workflow.

3. MCP samler værktøjerne, men værktøjerne bruger kontekst

MCP står for Model Context Protocol. I praksis kan du se en MCP-server som et samlet katalog af værktøjer. Mange af værktøjerne kalder API'er under overfladen. Hvert værktøj får et navn, en beskrivelse og et skema for de input, det kræver. MCP-dokumentationen beskriver værktøjer som schema-definerede interfaces, som modellen kan vælge ud fra opgaven.

Beskrivelsen er en kort instruktion til modellen. Den fortæller, hvad værktøjet kan, hvilke parametre det kræver, og hvornår modellen bør bruge det. Det gør MCP nemt at koble på en agent, fordi agenten får funktion og brugsvejledning samlet.

Den bekvemmelighed har en tokenpris. MCP-værktøjernes navne, beskrivelser og inputskemaer ligger ofte i modellens kontekst, før agenten har udført sin første handling. Kobler du flere store MCP-servere på samme session, kan agenten bruge en del af kontekstvinduet på værktøjer, som opgaven aldrig kalder.

Moderne klienter kan udskyde indlæsningen og kun hente de værktøjer, som agenten søger efter. Det kræver støtte i den klient og det harness, du bruger. Anthropics guide til tool context viser forskellen mellem at indlæse hele værktøjskataloget og hente værktøjer efter behov.

MCP er ekstremt alsidigt. Du kan samle mange endpoints og funktioner ét sted, og flere agenter kan bruge den samme server. Jeg placerer det efter API, fordi det ekstra lag kan koste kontekst, tokens og tid. Jeg vil vide, hvor mange tools agenten får, og om klienten loader dem alle ved hver session.

4. Computer og browser use åbner det, der ellers er lukket

Computer og browser use er den gyldne nøgle til de use cases, hvor systemet ikke giver dig en programmerisk adgang. Agenten får et screenshot, ser knapperne på skærmen og vælger en handling med mus eller tastatur.

Modellen ser et billede og vurderer, at en knap ligger oppe i højre side. Den flytter musen til de forventede koordinater og klikker. Rammer den forkert, skal den tage et nyt screenshot, forstå den nye skærm og prøve igen. Agenten kan bruge flere minutter på én knap.

Computer use er hurtigt at sætte op, fordi du ikke skal bygge en integration først. Hvis et menneske kan åbne brugerfladen og løse opgaven med mus og tastatur, kan en agent i princippet gøre det samme. Det åbner gamle systemer, iFrames og programmer uden API.

Kørslen er langsom og dyr. Hvert screenshot skal gennem modellen. Hver handling skaber en ny runde, og modellen skal bruge tokens på at forstå skærmen igen. Derfor kan mit e-mailflow tage agenten en 40-50 minutter at gennemføre, selv om jeg selv kunne udføre det på 20 til 30 minutter.

Sikkerhed og stabilitet trækker også ned. En ekstern hjemmeside kan indeholde prompt injection. Agenten får bred adgang til den brugerflade, som din session kan se. Et API kan begrænses med præcise scopes, mens computer use ofte arbejder med de rettigheder, din indloggede bruger allerede har.

Computer use er heller ikke platform-agnostisk på samme måde som terminalkommandoer eller et API. Agent-harnesses har forskellige computer use-funktioner, og modellerne rammer ikke brugerflader lige godt. Login med MitID, biometri eller personlig 2FA kræver stadig et menneskeligt trin.

Jeg bruger computer eller browser use som sidste udvej. Det er den adgang, der kan få næsten enhver Ai løsning, teknisk over målstregen, når de tre andre muligheder ikke rækker, eller nok nærmere, ikke eksister.

Computer use kan bevare den arbejdsgang, I allerede har

Jeg tror, en post-AI-tid kalder på en anden måde at tænke dataadgang. Data skal kunne nås gennem CLI eller som minimum et API. Du skal have kontrol over læse-, skrive-, redigerings- og sletterettigheder. Undgå at låse en vigtig funktion bag en knap, som kun et menneske kan trykke på.

Virksomheder arbejder ikke i en idealarkitektur. De arbejder i systemer, som medarbejderne allerede kender. Hvis jeg tvinger et helt team over i et nyt system for at få en ren integration, falder sandsynligheden for adoption.

Så bruger jeg computer use som bro. Agenten arbejder i den nuværende brugerflade, mens vi bygger en bedre adgang under overfladen. Jeg designer efter den måde, mennesker arbejder på i dag, og flytter arkitekturen i et tempo, organisationen kan følge.

Fra LinkedIn-opslag til færdig e-mailkampagne

Mit eget e-mailflow viser, hvorfor adgangs-auditten ændrer hele løsningen.

Jeg bruger Buildable til e-mailmarketing i AI Growth Minds. Kampagnebyggeren ligger i en iFrame, og jeg havde ingen direkte integration til den del af systemet. En klassisk n8n-automatisering kunne derfor ikke bygge kampagnen for mig.

Før brugte jeg mellem 20 og 30 minutters manuelt arbejde på en hurtig kampagne. Nu bruger jeg cirka 0 sekunder. Agenten kan stadig bruge en halv time på at udføre arbejdet. Min gevinst er, at jeg ikke sidder ved musen imens.

Agenten starter med en LinkedIn-URL

Jeg indsætter URL'en til et opslag, som jeg vil bygge kampagnen på. Jeg kan også give ekstra kontekst, billeder eller video og fortælle, hvornår kampagnen skal sendes.

Jeg havde ikke den LinkedIn API-adgang, som workflowet krævede. En browser use-agent åbner derfor min browser, navigerer til opslaget og henter tekst og billede. Login kommer fra en secret-fil gennem et deterministisk script. Modellen får ikke passwordet skrevet ind i sin prompt.

Agenten skriver derefter e-mailen og samler grafikken lokalt. Før delte jeg materialet i et Google Docs-dokument med en samarbejdspartner, som byggede kampagnen manuelt. Det dokument blev udgangspunktet for den næste del af agentens workflow.

Buildables iFrame stoppede den første løsning

Kampagnebyggeren består af små blokke til billede, overskrift og tekst. Når agenten klikker på én blok, flytter de andre sig på skærmen. Koordinaterne ændrer sig midt i arbejdet. Agenten kunne bruge flere minutter på at ramme én knap og ende på den forkerte.

Screenshotet viser en af de kørsler, hvor Claude sad fast. iFramen mistede authentication, siden frøs, og agenten forsøgte både direkte URL, genindlæsning og ændring af vinduets størrelse.

Jeg testede workflowet fem til ti gange og skrev fejlene tilbage i instruktionerne. Vi fandt også andre indgange end musekoordinater. Agenten kunne bruge JavaScript-injektion i nogle trin og vælge elementer gennem builderens lagoversigt.

Den færdige løsning kombinerer JavaScript, lagoversigten og computer use. Computer use udfører stadig det meste. Mine prompts og instruktioner er blevet bedre for hver kørsel.

Agenten bygger, vælger liste og planlægger

Når teksten og billedet er klar, opretter agenten kampagnen. Den vælger de rigtige blokke, indsætter teksten, placerer grafikken og vælger en navngivet modtagerliste. Den kan ikke se, hvem der ligger på listen. Den kan se listens navn og vælge den, jeg har angivet.

Jeg kan skrive, at kampagnen skal sendes onsdag klokken 16. Agenten planlægger den og beder om godkendelse ved de kontrolpunkter, jeg har bygget ind.

Human-in-the-loop bliver mindre efter hver stabil kørsel

Jeg godkender tre ting i mit nuværende workflow. Jeg godkender indholdet, tidspunktet og selve afsendelsen.

Mine kørsler viser, at indholdet er det eneste sted, hvor jeg ofte retter noget. Kampagnen bygger på et LinkedIn-opslag, jeg allerede har skrevet, så agenten rammer sjældent langt forbi. Mine rettelser handler om formulering, smag og den granulerede forståelse af sprog, som modellen ikke har.

Tidspunkt og afsendelse er mekaniske valg. Jeg beholder godkendelserne, fordi jeg vil have styring over processen. Hvis workflowet rammer rigtigt 10, 30 eller 100 gange, kan jeg fjerne dem.

Antallet af kørsler betyder noget. Tre vellykkede kampagner giver mig mindre bevis end 40 eller 100 kampagner, hvor agenten vælger det rigtige tidspunkt og den rigtige liste hver gang. Jeg fjerner først et kontrolpunkt, når de faktiske kørsler har vist, at det ikke længere beskytter processen.

Hvis workflowet kører flere gange om dagen, bliver godkendelserne selv en arbejdsopgave. Så har jeg flyttet arbejdet fra at bygge kampagnen til at trykke godkend. Det er præcis den flaskehals, jeg vil væk fra.

Der findes også to typer human-in-the-loop. Den første designer jeg selv ud fra smag, risiko og mit behov for kontrol. Den anden bliver tvunget ind af adgangen, når et system kræver MitID, biometri eller personlig 2FA. Stabile kørsler kan fjerne den første type. De kan ikke fjerne et login, der kræver mit ansigt eller fingeraftryk.

Human-in-the-loop er derfor ikke en fast model. Jeg starter med flere kontrolpunkter. Gentagne kørsler viser, hvilke godkendelser der beskytter noget, og hvilke der gør mig til flaskehals.

Credentials må aldrig ligge i prompten

Jeg lægger passwords, API-nøgler og tokens i en .env-fil eller en secret-mappe. Git skal ignorere filen. Skillen kalder et deterministisk script, som henter den rigtige værdi og indsætter den i loginformularen eller API-kaldet.

Ved CLI, API og MCP er mønstret ligetil. Scriptet læser environment-variablen, bruger den til det konkrete kald og returnerer kun resultatet. Det må hverken printe eller sende credentialet tilbage til modellen.

Computer use kræver en anden løsning. Hvis agenten arbejder i din eksisterende browser med gyldige cookies, bruger den den session, du allerede har logget ind i. Rydder du cachen, udløber sessionen, eller kører agenten i en headless browser, skal workflowet kunne logge ind igen.

Her lader jeg et deterministisk script udfylde loginformularen. Modellen finder feltet til e-mail og password, men koden henter værdierne fra .env og indsætter dem. Agenten kan se e-mailadressen på det næste screenshot. Passwordet skal aldrig indgå i prompten, et tool-resultat eller en log.

Login udløber. Nogle systemer kræver ny authentication efter tre måneder. Det gælder også CLI'er og MCP-forbindelser, hvor en gemt token eller session kan udløbe. Den del skal stå i workflowets dokumentation.

Adgangs-auditten skal derfor registrere, hvem der kan logge ind igen, hvad der kræver 2FA, og hvor workflowet sender en besked, når authentication stopper. Agenten kan for eksempel skrive i Slack, så et menneske kan godkende og lade workflowet fortsætte. Uden den mekanisme sidder agenten fast.

Risikoniveauet afhænger af opgaven og jeres risikovillighed

Der findes ikke én risikogrænse, som passer til alle virksomheder. En lille virksomhed, en bank og en offentlig organisation har forskellige krav, modenhed og risikovillighed. I skal selv beslutte, hvor stor en fejlmargin I kan acceptere, og hvilke handlinger agenten må udføre uden godkendelse.

Jeg vurderer især tre ting. Kan agenten møde prompt injection eller anden manipulation? Kan outputtet påvirke andre mennesker? Skal agenten behandle personhenførbare eller følsomme oplysninger?

Computer og browser use skruer op for den første risiko, fordi agenten læser indhold fra skærmen. En hjemmeside, en e-mail eller et dokument kan indeholde instruktioner, som forsøger at manipulere agenten. En agent med skrive- eller sletteadgang får samtidig mulighed for at omsætte manipulationen til en handling.

Den anden risiko handler om, hvem outputtet rammer. En intern kladde kan læses og rettes af én medarbejder. En e-mailkampagne kan ramme 20.000 mennesker. Jo større konsekvensen af en forkert handling er, desto mere kontrol og test skal processen have.

Den tredje risiko handler om data. Navn, e-mail og andre personhenførbare oplysninger kræver en anden behandling end en offentlig produkttekst. Helbredsoplysninger, religion og seksuel orientering hører til de følsomme kategorier, som kræver et ekstra sikkerhedslag.

Tag en proces, hvor en agent skal læse CV'er. CV'erne kan indeholde navn, kontaktoplysninger, tidligere arbejdspladser og fri tekst om kandidaten. De kan også indeholde følsomme oplysninger om helbred, religion eller seksuel orientering. Agenten skal derfor ikke have filerne sendt direkte til en ekstern LLM uden et ekstra datalag og en konkret vurdering af formålet.

Risikoen stiger igen, hvis AI-systemet skal screene, rangere eller udvælge kandidater. Den brug kan falde ind under AI-forordningens regler for højrisikosystemer. AI-forordningens bilag III nævner systemer til rekruttering og udvælgelse, så den konkrete løsning kræver en juridisk vurdering.

Du kan bygge et lokalt datalag før den eksterne LLM. Et deterministisk anonymiseringsscript kan fjerne klare identifikatorer. En lokal NLP-model eller en lille lokal sprogmodel kan hjælpe med at finde følsomme oplysninger i fri tekst, før resten af materialet sendes videre.

EU-Kommissionen understreger, at pseudonymiserede data stadig er persondata, hvis en person kan identificeres igen. GDPR-ansvaret består, selv om du har fjernet navn og e-mail.

Compliance er et stort emne, og det fortjener sit eget indlæg. Pointen i adgangs-auditten er, at du opdager kravet, før du har bygget agenten og givet den adgang.

Teknisk muligt betyder ikke, at det kan betale sig

Næsten alle digitale opgaver kan få en adgangsvej. Automatiseringsbeslutningen kræver en vurdering af pris, risiko og stabilitet.

Der findes heller ikke én ROI-grænse, som passer til alle. Sammenlign prisen med de mandetimer, processen koster i dag. Hvis en løsning sparer 100 millioner kroner og koster 90 millioner, skal du vurdere, om afkastet er stort nok. Hvis den koster én million og sparer 99 millioner, ser regnestykket anderledes ud.

Regnestykket skal have både udvikling og drift med. En computer use-løsning kan være hurtig at sætte op og dyr at køre, fordi hvert screenshot og hvert agent-loop bruger tokens. En CLI-løsning kan kræve mere arbejde i starten og koste mindre pr. kørsel. Antallet af gentagelser afgør, hvilken forskel det gør.

Mit e-mailflow viser den forskel. Agenten kan bruge op mod en time på en opgave, jeg selv klarer på 20 til 30 minutter. Løsningen giver stadig mening for mig, fordi mit manuelle arbejde er faldet til cirka 90 sekunder. Jeg køber min egen tid tilbage, selv om maskinen arbejder langsommere.

Risiko kan også stoppe en teknisk mulig løsning. Prompt injection, GDPR eller konsekvensen af en forkert handling kan gøre processen uegnet til første runde.

En LLM er ikke deterministisk. Du får ikke præcis samme output hver gang, og du skal acceptere en fejlmargin. Vurder både sandsynligheden for en fejl og konsekvensen, hvis den sker.

Sammenlign derefter fejlmarginen med den nuværende proces. Mennesker laver også fejl. Et testet workflow med stærke instruktioner og guardrails kan i mange processer lave færre fejl end et menneske. Beslutningen handler om den konkrete opgave, jeres nuværende fejl og den risiko, I vil acceptere.

Edge cases bygger den robuste løsning

Adgangs-auditten giver dig designet på papiret. Testperioden viser, hvordan systemerne opfører sig i virkeligheden. Du finder ikke alle edge cases ved skrivebordet. Du finder dem, når agenten møder en flyttet knap, en udløbet session, en tom side eller et felt med en ny valgmulighed.

Du retter fejlen og skriver løsningen ind i skillen, så snart den opstår. Kør processen igen. Mit e-mailworkflow blev brugbart, fordi jeg gennemgik virkelige kørsler og forbedrede instruktionerne.

Mit e-mailworkflow krævede fem til ti kørsler, før instruktionerne dækkede de problemer, jeg havde fundet. Andre processer kan kræve flere. Pointen er, at du planlægger en periode, hvor workflowet kører med flere godkendelser, mens du finder fejlene.

Hver ny edge case opdaterer også det ottende spørgsmål i adgangs-auditten. Du bliver klogere på, hvad der mangler for end-to-end drift. Det kan være en stabil login-session, en anden vej gennem en iFrame eller en besked til et menneske ved 2FA.

Den testtid skal ind i planen fra starten. En agent-skill er ikke færdig, fordi den lykkes én gang. Du fjerner først godkendelser og giver mere autonomi, når gentagne kørsler har vist, at løsningen holder.

Det skal du stå med efter din adgangs-audit

Du skal have én række pr. arbejdsopgave og ét svar på hvert af de otte spørgsmål. Det kan ligge i et Excel-ark. Du kan også chatte med en AI og få den til at vibe code et lille HTML-værktøj i Lovable eller et andet værktøj.

For mit e-mailflow kunne rækken se sådan ud:

Felt	Svar
Startartefakt	LinkedIn-URL, ekstra kontekst og eventuelle billeder
Systemer der læses	LinkedIn, lokale filer og kampagnemateriale
Systemer der skrives til	Google Docs og Buildables kampagnebygger
Adgangstype	Browser use, computer use, JavaScript og lagoversigt
Credentials	Secret-fil, eksisterende browsersession og deterministisk login-script
Risiko	Ekstern webside, prompt injection og afsendelse til en modtagerliste
Menneskelig godkendelse	Indhold, tidspunkt og afsendelse
Mangler for end-to-end drift	Stabil authentication og nok test til at fjerne unødige godkendelser

Hvis I er et team, kan I fordele processerne og tage en række hver. Marker de opgaver, hvor compliance, risiko eller manglende adgang gør løsningen for tung. Lad dem ligge i den røde zone.

Start med quick wins. Vælg opgaver, hvor adgangen findes, gevinsten er tydelig, og en fejl ikke kan vælte forretningen. Den første succes giver teamet lyst og mod til at bygge den næste.

Der ligger en klar ideologi og en klar engineering-forståelse i dataadgang. Adgangen afgør, hvad agenten kan gøre, hvad det koster, og hvor meget kontrol du beholder.

Vil du have mig ud og bygge løsningerne sammen med jer?

Adgangs-auditten er trin 2 i mit seks-trins framework. De næste trin handler om at bygge AI-løsningerne end-to-end, samle dem i workflows og lægge et kommandolag ovenpå.

Hvis du vil have hjælp til hele rejsen, kommer jeg ud i jeres virksomhed og bygger løsningerne sammen med jer i de systemer, I allerede bruger. Se Skalér din forretning med AI og tag kontakt, så taler vi om, hvad der kan lade sig gøre i din virksomhed.

Ofte stillede spørgsmål

Hvad er en adgangs-audit for AI-agenter?

En adgangs-audit gennemgår den data, de systemer, de credentials, den risiko og de godkendelser, som en AI-agent kræver for at løse én arbejdsopgave end-to-end.

Skal jeg vælge CLI, API, MCP eller computer use?

Min rækkefølge er CLI først, derefter API, MCP og til sidst computer eller browser use. Du skal stadig vurdere den konkrete opgave ud fra pris, hastighed, sikkerhed og platform.

Kan en AI-agent bruge et system uden API?

Ja. En agent med computer eller browser use kan arbejde gennem brugerfladen med screenshots, mus og tastatur. Jeg bruger det som sidste udvej, fordi det tager længere tid, bruger flere tokens og giver større risiko.

Hvordan beskytter jeg passwords og API-nøgler mod AI-modellen?

Gem credentials i en .env-fil eller en secret-mappe, som Git ikke sporer. Lad et deterministisk script hente og indsætte værdierne. Skriv aldrig passwords, tokens eller API-nøgler i prompten.

Kan en AI-agent køre helt autonomt med 2FA?

Planlæg et menneskeligt godkendelsespunkt, når login kræver MitID, biometri eller en anden personlig 2FA. Workflowet skal opdage blokeringen og give dig besked i stedet for at sidde fast.