Postman installerte AI-tillegg uten tydelig samtykke

Hvis du har åpnet Postman Desktop på en Mac i det siste, kan programmet ha installert Postman CLI og tillegg i Codex og Claude Code uten at du tok et tydelig valg om hver integrasjon.

Dette er ikke en teoretisk bekymring. Logger fra to Mac-er viser automatiske installasjoner på tvers av flere Postman-versjoner. Tillegget la inn en oppstartsinstruks som forsøkte å gjøre Postman til standard inngang for en lang rekke API-oppgaver, og installasjonskoden forsøkte å godkjenne sin egen Codex-hook.

Det er et grovt overtramp mot en helt grunnleggende grense: Et API-verktøy skal ikke endre andre utviklerverktøy og påvirke AI-agentene dine uten et klart ja. Samtidig må jeg være presis. Den åpne dokumentasjonen viser ikke at Postman lastet opp eller stjal alle API-data. Den viser uønsket installasjon, bred instruksjonsstyring og et forsøk på å etablere tillit til egen hook. Det er ille nok.

Hva installerte Postman automatisk?

Den opprinnelige rapporten gjelder Postman Desktop 12.33.4 på macOS. Ifølge den detaljerte GitHub-saken registrerte Postmans egen logg at både Claude Code- og Codex-tillegg ble installert automatisk 24. oktober 2026. Samme installasjonsvindu omfattet også en separat Postman CLI.

I Codex ble Postmans markedsplass og plugin aktivert i brukerens globale ~/.codex/config.toml. Tillegget pekte dessuten på Postmans eksterne MCP-server. I Claude Code ble Postman-pluginen aktivert på brukernivå, mens en Postman-kjørbar fil dukket opp i ~/.local/bin. Dette var altså ikke bare en ny funksjon inne i Postman-vinduet.

Rapporten ble først gjort fra én Mac og var ikke en ren reproduksjon på en ny maskin. Det er en viktig begrensning. Men 3. november la en annen bruker fram logger fra Postman 12.35.1 som viste samme auto-existing-upgrade-løp: CLI, Claude Code-plugin og Codex-plugin ble installert da en eksisterende Postman-installasjon ble oppdatert. Det gjør saken langt vanskeligere å avfeie som et lokalt uhell.

Hooken forsøkte å gjøre Postman til standard

Postman-tillegget registrerte en SessionStart-hook som kunne kjøres ved oppstart, tømming og komprimering av en Codex-sesjon. Instruksen ba agenten laste ferdigheten postman:api-engineer før den svarte på nesten enhver ikke-triviell API-oppgave.

Ordlyden i den låste kildefilen fra den installerte revisjonen omfatter design, implementasjon, mocking, testing, overvåking, dokumentasjon og deploy av API-er. Med andre ord: Du trengte ikke å be om Postman. Instruksen forsøkte å plassere Postman midt i arbeidsflyten fordi oppgaven handlet om API-er.

Dette er ikke en uskyldig snarvei. Oppstartsinstrukser former hvilke verktøy en agent velger, hvilken kontekst som lastes og hvilke eksterne tjenester som trekkes inn. Når et produkt installerer en så bred instruks globalt, flytter det på brukerens beslutningsmyndighet. Et tillegg skal være et verktøy du velger. Det skal ikke snike seg inn som arbeidsleder.

Rekkevidden er også viktig. En integrasjon du aktivt velger, kan du ta stilling til før den får påvirke arbeidsflyten. En godkjent oppstartshook kan derimot påvirke agenten før den første arbeidsoppgaven blir behandlet. Når instruksen i tillegg gjelder generelt API-arbeid, kan den få betydning i prosjekter som aldri har hatt noe med Postman å gjøre.

Postmans instruks sa riktignok at direkte brukerbeskjeder og prosjektfiler som AGENTS.md skulle ha høyere prioritet. Det er bedre enn å forsøke å overstyre brukeren fullstendig, men det gjør ikke den globale installasjonen grei. Brukeren skal ikke måtte skrive en motordre i hvert prosjekt for å slippe en integrasjon vedkommende aldri ba om.

Forsøkte installasjonen å godkjenne seg selv?

Ja. Den publiserte installasjonskoden inneholdt en funksjon som hentet den aktuelle hookens hash fra Codex og skrev den inn som godkjent i brukeroppsettet. Postmans egen kildekode beskrev funksjonen som godkjenning av Postmans gjeldende hook etter installasjon.

Den første rapporten fant to tillitshasher i Codex-konfigurasjonen. Rapportøren var samtidig nøye med å si at selve oppføringen ikke alene beviser hvilken brukerhandling eller prosess som skrev akkurat disse verdiene. Koden beviser derimot at installasjonsprogrammet forsøkte å utføre godkjenningen. Det skillet skal vi holde fast ved.

På den andre Mac-en med Postman 12.35.1 ble tillegget fortsatt installert, men det fantes ingen hooks.state-oppføring eller trusted_hash etterpå. Der ser det dermed ut til at hooken ikke fikk Codex-tillit. Det kan tyde på at godkjenningsdelen endret seg mellom versjonene, men den automatiske installasjonen var fortsatt aktiv.

Ble alle API-data sendt til Postman?

Det finnes ikke dokumentasjon på at Postman lastet opp alle API-data. Den opprinnelige rapportøren skrev uttrykkelig at funnene dokumenterte uønskede integrasjoner og instruksjonsendringer, ikke datauthenting. Den andre rapporten sa også at det ikke fantes bevis for opplasting av data.

Forvirringen er forståelig. Codex-pluginen konfigurerte en ekstern MCP-forbindelse til Postman, og oppstartsinstruksen ville rute bredt API-arbeid gjennom Postman-ferdigheter. På den første Mac-en feilet MCP-oppstarten med krav om autentisering. Men en konfigurert forbindelse og en bred instruks er ikke det samme som bevis på at alle forespørsler, nøkler eller API-spesifikasjoner ble sendt ut.

Det betyr heller ikke at risikoen er uinteressant. Et MCP-oppsett kan gi en agent nye handlinger og en ny ekstern grenseflate etter autentisering. Nettopp derfor skal oppkoblingen være synlig, avgrenset og frivillig. Men en risikovurdering må beskrive hva forbindelsen kan åpne for, ikke late som det allerede finnes logger som viser en fullstendig dataoverføring.

Her er det fristende å skru dramatikken til elleve, men da blir saken svakere. Den dokumenterte hendelsen er alvorlig fordi et program tok seg til rette på tvers av verktøy- og tillitsgrenser. Jeg trenger ikke legge udokumentert datatyveri oppå den.

Postman bekrefter at komponentene ble pakket sammen

Postman svarte i GitHub-tråden 3. november. Selskapet forklarte at CLI-en og agenttilleggene ble pakket sammen med desktop-appen fordi mange brukere hadde problemer med å installere og koble dem opp hver for seg. Postman viste til informasjon på nedlastingssiden og i oppdateringsflyten, og skrev at komponentene kan avinstalleres fra appen.

Selskapet lovet å gjøre samtykket tydeligere, særlig for eksisterende brukere, og sa at det gjennomgår godkjenningen av hooks og oppførselen ved sesjonsstart. Det er i praksis en bekreftelse på at komponentene bevisst ble installert samlet, ikke et utslag av en tilfeldig tredjepartsfeil.

En ny rapport 4. november viser også hvorfor oppryddingen må kontrolleres. En bruker fant Postman-pluginen aktivert i GitHub Copilot og skrev at Postmans egen avinstallasjon ikke fjernet Copilot-oppføringene. Det er én brukerrapport, ikke en full test av alle verktøy, men den er god nok grunn til å kontrollere resultatet i stedet for å stole blindt på avinstallasjonsknappen.

Forklaringen løser likevel ikke hovedproblemet. At en integrasjon er vanskelig å sette opp, gir ikke leverandøren rett til å installere den i andre programmer og gjøre den til standard uten et tydelig opt-in. En avkrysningsboks hadde ikke vært noen teknologisk revolusjon. Den hadde bare vært vanlig folkeskikk.

Hva bør du kontrollere nå?

Har du brukt Postman Desktop på macOS, bør du kontrollere om appen har lagt igjen komponenter utenfor selve Postman-installasjonen. Se etter Postman-oppføringer i ~/.codex/config.toml, ~/.claude/settings.json, ~/.claude/plugins og eventuelt ~/.copilot/settings.json, pluss en Postman CLI i ~/.local/bin. Sjekk også Postmans egne logger for autoInstall og auto-existing-upgrade.

Ikke slett blindt hvis dette er en jobbmaskin eller et delt utviklingsmiljø. Dokumenter først hva som er installert, når filene ble endret og hvilke verktøy som berøres. Deretter kan du bruke avinstallasjonen i Postman og kontrollere at globale konfigurasjoner, plugins, hooks, MCP-oppsett og CLI faktisk er borte. Rapportøren ba om en fullstendig oppryddingsprosedyre nettopp fordi én knapp ikke nødvendigvis dekker alle disse flatene.

Se også etter forskjellen mellom installert, aktivert og godkjent. På den andre Mac-en var Codex-pluginen installert og aktivert, men hooken manglet tillitsoppføringen som skulle til for å kjøre i den testede Codex-versjonen. Det er nyttig ved opprydding og hendelsesanalyse: En fil på disken beviser ikke at all funksjonalitet kjørte, men den beviser at installasjonen endret miljøet.

For bedrifter bør dette også behandles som en endring i utviklermiljøet, ikke bare som en appoppdatering. En agent-hook kan påvirke oppgaver på tvers av kodebaser og arbeidsområder. Det er samme grunn til at sikkerheten rundt AI-agenter og API-nøkler må vurderes som en hel kjede, ikke som en håndfull isolerte plugins.

Tilliten er selve produktet

Postman arbeider med API-er, autentisering, miljøvariabler og dokumentasjon som kan være blant de mest følsomme delene av et system. Da holder det ikke at en automatisk integrasjon var ment som en hjelp. Leverandøren må forstå at samtykke ikke er en liten detalj i brukeropplevelsen. Det er selve sikkerhetsgrensen.

Min vurdering er enkel: Dette skulle aldri vært standard oppførsel. Postman må stanse automatisk installasjon i eksisterende verktøy, kreve et tydelig ja for hver integrasjon og publisere en komplett oppryddingsbeskrivelse. Hook-tillit skal avgjøres av brukeren i verktøyet som skal kjøre hooken – ikke av programmet som ønsker tilgang.

Og hvis du finner disse komponentene på maskinen din uten å ha bedt om dem, bør du ikke bare trykke «OK» og gå videre. Dokumenter, fjern det du ikke vil ha, og krev et ordentlig svar fra Postman. Bekvemmelighet er fint. Å ta seg til rette er noe helt annet.

Ofte stilte spørsmål