AI-agenter lade 13 000 interna bilder öppet – kontrollera personliga GitHub-konton

Glow uppger i sin PixelLeak-rapport från 29 september 2026 att AI-agenter lade fler än 13 000 interna bilder öppet på GitHub, fördelade på över 900 arkiv med koppling till utvecklare vid fler än 300 organisationer. Bilderna skulle visa resultatet av kodändringar i privata granskningar. För att göra dem synliga för granskarna placerade agenter dem i offentliga arkiv, ofta utanför arbetsgivarens GitHub-organisation.

Enligt Help Net Securitys rapportering den 30 september 2026 låg bilderna i 93 procent av de rapporterade fallen under anställdas egna användarnamn. Ett beskrivet fall gällde en tillverkares interna faktureringsvy: skärmbilder med en energikunds faktureringsuppgifter lades i ett offentligt arkiv på utvecklarens personliga konto. Det gör en inventering av enbart företagets egna arkiv otillräcklig.

Privat kodgranskning fick en offentlig bildadress

Utgångspunkten var en konkret uppgift: en utvecklare ville att en kodagent skulle visa en visuell ändring för den som granskade en pull request. Vid tiden då bilderna lades ut saknade GitHubs kommandoradsverktyg ett sätt att bifoga dem direkt på samma sätt som i webbläsaren. Agenten behövde därför hitta en annan väg för att ge granskaren en fungerande bildlänk.

En offentlig GitHub-adress löste visningsproblemet men ändrade vem som kunde nå innehållet. När bilden låg i ett separat öppet arkiv räckte det att känna till länken eller hitta arkivet; behörigheten till den privata kodgranskningen skyddade inte bildfilen. En skärmbild kan dessutom visa sådant som inte framgår av filnamnet: kunduppgifter i en vy, intern funktionalitet eller information om en kommande produkt.

I tillverkarens fall kördes agenten på utvecklarens dator och skapade arkivet på personens eget konto. Företagets säkerhetsfunktion såg därför inte publiceringen genom sin vanliga översikt över organisationens GitHub-arkiv. Samma förskjutning av ägarskap kan finnas kvar även efter att en medarbetare slutat, eftersom det personliga kontot inte upphör när åtkomsten till företagets privata arkiv tas bort.

Gitshot ger ett särskilt spår i releases

I The Hacker News kodgranskning den 30 september 2026 framgår att den granskade versionen av gitshot som standard skapade ett offentligt arkiv med namnet gitshot-images på användarens personliga konto och sparade bilder som release-tillgångar; mediet beskriver också bildstöd i GitHubs kommandoradsverktyg sedan version 2.99.0. Gitshots bilder kunde listas och hämtas utan inloggning. Verktygets egna instruktioner varnade för att lägga känsligt material där.

En release-tillgång ligger inte i den vanliga fillistan för arkivet. Därför kan ett arkiv med få eller inga synliga kodfiler ändå innehålla nedladdningsbara skärmbilder eller inspelningar. Taggen _gitshot och arkivnamnet gitshot-images är användbara sökspår, men andra agenter skapade egna öppna arkiv utan att använda verktyget.

Kodgranskningen visar hur just gitshot kunde göra filer offentliga. Den fastställer inte hur många av alla rapporterade bilder som publicerades av en agent på eget initiativ: verktyget kan också användas av människor. Den fullständiga metoden för att hitta och räkna bilderna har inte publicerats, och forskningsbolaget säljer skydd mot sådana agentåtgärder. Omfattningen bör därför behandlas som bolagets uppgift, medan arkivens synlighet och verktygets standardbeteende kan granskas separat.

Kontrollera konton, tillgångar och instruktioner

Granskningen bör utgå från personer med tillgång till organisationens privata kodarkiv, eftersom det är deras personliga konton som kan bära de öppna bildsamlingarna. Ta med tidigare medarbetare och skilj mellan ett arkivs vanliga filer och dess bifogade release-tillgångar. Följ också länkar från privata pull requests till deras faktiska destinationer.

1. Samla de GitHub-användarnamn som har bidragit till berörda privata arkiv. Gå igenom deras offentliga arkiv och kontrollera om det finns samlingar av granskningsbilder, också när arkivnamnet inte nämner arbetsgivaren.
2. Öppna releases i relevanta arkiv och granska varje tillgång. Sök efter gitshot-images och taggen _gitshot, men gå vidare även när de saknas: den manuella publiceringsvägen kan använda andra namn.
3. Kontrollera offentliga gists på samma konton och följ bildlänkar i pull requests. En privat diskussion kan innehålla en länk till en offentligt åtkomlig fil; synligheten avgörs av filens plats.
4. Läs delade instruktioner och färdigheter som kodagenter laddar. Leta efter anvisningar om att skapa offentliga arkiv, använda personliga konton eller publicera skärmbilder via gitshot. Kontrollera också vilka utvecklarverktyg som faktiskt finns installerade.

En textsökning kan peka ut namn och länkar men avgör inte vad en bild visar. Bedöm därför själva innehållet i träffarna med rätt intern åtkomst: en förhandsvisning av en opublicerad funktion kräver en annan hantering än synliga kunduppgifter eller autentiseringshemligheter. Dokumentera var bilden gick att hämta och om samma fil förekommer på fler platser.

När en intern bild hittas öppet

Ta bort den offentliga publiceringen och spåra kända kopior och länkar, även sådana som ligger i release-tillgångar eller gists. Om bilden visar inloggningsuppgifter eller andra hemligheter behöver de bytas. Skilj samtidigt mellan att en fil varit åtkomlig och att någon faktiskt har hämtat den; offentlig åtkomst visar inte i sig vidare spridning.

För nya kodgranskningar finns nu stöd för bildbilagor direkt i GitHubs kommandoradsverktyg, men det ändrar inte åtkomsten till filer som redan publicerats öppet. Team som låter agenter arbeta med granskningsbilder behöver ange en godkänd destination och kräva insyn innan agenten skapar ett offentligt arkiv, publicerar på ett personligt konto eller ändrar ett arkivs synlighet.

Läs också:

• Claude Code eller GitHub Copilot: uppgiftstypen avgör mer än priset
• GitHub eller GitLab: gratis CI-minuter säger inte hela kostnaden
• Prompt injection stoppas inte av ett filter – lås agentens verktyg