När AI får läsa filer: börja med en kopierad mapp, inte hela projektet

En AI-agent som får arbeta i en mapp får inte bara bättre sammanhang. Den får ett handtag på verksamhetens råmaterial: avtal, kalkylblad, kod, exporter och dokument som någon faktiskt behöver.

Det är användbart. Det är också skälet till att den första piloten bör köras i en kopia, inte i originalmappen.

Grok Build-incidenten visar varför mappgränsen måste testas

Den 13 juli publicerade säkerhetsforskaren Cereblab en reproducerbar rapport om Grok Build. I tester med version 0.2.93 packades ett spårat Git-repository, inklusive historiken, som en Git bundle och skickades via en separat lagringsbegäran. Det skedde även när agenten instruerades att inte öppna några filer. En fil som inte hade lästs av modellen kunde ändå följa med i paketet.

Forskaren såg senare att samma klient fick serverflaggan disable_codebase_upload: true, varefter den rapporterade heluppladdningen upphörde. Det är viktigt att formulera det rätt: beteendet stoppades av en serverstyrd kontroll. Rapporten visar inte att en verifierad klientuppdatering ensam löste frågan, och den säger inget om alla andra filagenter.

Källa: Cereblabs reproducerbara rapport och testmaterial

Källa: The Verge – rapportering och oberoende säkerhetskommentar

SpaceXAI svarade att spår- och koddata inte lagras för team med zero data retention, ZDR, och att API-nyckelanvändning av Grok Build följer ZDR. Företaget hänvisade också till kommandot /privacy för att stänga av lagring när ZDR inte används. Elon Musk skrev därefter att tidigare uppladdad användardata skulle raderas. När researchen avslutades fanns ingen detaljerad offentlig redovisning av vilka konton och versioner som berörts eller någon oberoende bekräftelse på slutförd radering.

Källa: SpaceXAI:s svar om ZDR och datalagring

Källa: Elon Musks besked om radering

Poängen är inte att döma alla filverktyg efter ett fall. Poängen är att filåtkomst, överföring, lagring och modellträning är fyra olika frågor. Ett verktyg kan respektera en spärr mot att läsa en fil i modellens arbetssteg men ändå ha en separat synk- eller lagringsfunktion. En inställning för retention säger inte automatiskt vad som lämnar datorn.

Vad är en filkapabel AI-agent?

En filkapabel AI-agent kan läsa, skapa eller ändra filer som en del av ett flerstegsjobb. Den kan till exempel sammanställa fakturor, kontrollera ett projekt, sortera dokument eller bygga en rapport. Till skillnad från en vanlig filuppladdning kan agenten också använda kommandorad, appar och nätverkstjänster under arbetet.

Manus beskriver exempelvis sin skrivbordsagent som mappavgränsad: användaren väljer en lokal katalog och godkänner kommandon. Det är en användbar kontrollmodell, men leverantörens beskrivning ersätter inte ett eget test av den produkt, version och konfiguration som ska användas.

Källa: Manus Desktop – lokal filåtkomst och godkännanden

Bygg piloten så att ett fel blir billigt

1. Skapa testmappen utanför originalet

Kopiera bara de filer som behövs för uppgiften. Arbetar ni med kod bör ni först fråga om historiken över huvud taget behövs. En ny katalog utan .git minskar risken att gamla hemligheter, borttagna filer eller interna grenar följer med. Om ni behöver versionsjämförelse kan ni skapa en ny lokal historik från den sanerade kopian.

För dokumentarbete gäller samma princip. Exportera ett litet urval i stället för att ansluta en hel SharePoint-yta, kundmapp eller skolserver. Använd påhittade namn och belopp när arbetsflödet fortfarande testas.

2. Inventera det agenten faktiskt kan se

Spara en fillista före start, även dolda filer. Kontrollera metadata, temporära filer, arkiv, genvägar och länkar till andra kataloger. För ett kodprojekt ska granskningen omfatta spårade filer och historik, inte bara vad som syns i den senaste arbetskopian.

Skriv samtidigt vad som uttryckligen är förbjudet: riktiga API-nycklar, elevuppgifter, produktionsdatabaser, kundavtal eller andra dataklasser som piloten inte behöver.

3. Börja med en läsuppgift

Den första körningen ska producera ett förslag, en inventering eller en rapport. Den ska inte flytta original, skriva över kalkylblad, skicka mejl eller publicera något. Läsbehörighet minskar konsekvensen av ett fel och gör det lättare att se vilka källor agenten använder.

En bra första instruktion är konkret: ”Läs dessa 20 sanerade fakturor, skapa en CSV i utmappen och markera osäkra värden. Ändra inga källfiler.”

4. Lägg in en falsk kanariefil

Skapa en unik, ofarlig markör i testmappen, till exempel PILOT-CANARY-2026-07-A7. Placera den i en fil som uppgiften inte behöver. Kontrollera sedan om markören syns i agentens svar, loggar, exporter eller observerad nätverkstrafik.

Kanarien bevisar inte att allt är säkert. Den kan däremot avslöja att det deklarerade arbetsområdet och det verkliga beteendet skiljer sig.

5. Skriv ned den förväntade datavägen

Dokumentera vilka domäner, appar och lagringsplatser som ska användas innan körningen. Jämför sedan med tillgängliga loggar, proxydata eller leverantörens administrationsvy. Om verktyget inte ger tillräcklig insyn är det ett resultat i sig: då ska piloten inte flyttas till känsligare material.

xAI:s företagsdokumentation skiljer mellan lokala verktygssteg, transport till inferenstjänsten, serverbehandling, retention och lokal sessionshistorik i ~/.grok/. Den uppdelningen är ett bra frågebatteri även för andra leverantörer.

Källa: xAI Grok Build – företagskontroller och datalivscykel

6. Granska diffen, inte bara slutfilen

Jämför testmappen mot den orörda kopian. Granska skapade, ändrade och borttagna filer samt eventuella kommandon och externa anrop. Ett snyggt slutdokument kan dölja att agenten läste för mycket, skrev på fel plats eller lämnade temporära kopior.

Först när en människa har godkänt diffen får samma typ av åtgärd övervägas i nästa pilotsteg. Behåll skicka, radera, publicera och ändra behörigheter bakom ett separat godkännande.

7. Kräv bevis för städning och återställning

Avsluta inte med ”det såg bra ut”. Radera testkopian enligt den plan ni bestämt, kontrollera lokal sessionshistorik och dokumentera hur leverantörens retention eller radering fungerar. Rotera omedelbart en hemlighet om ni upptäcker att den funnits i testmaterialet eller i versionshistoriken.

Spara också en återställningspunkt. För dokument kan det vara den orörda exporten. För kod kan det vara en separat kopia och en godkänd diff. Rollback är inte samma sak som radering hos leverantören; båda behöver egna kontroller.

Fyll i den här mapp-pilotkartan

Kopiera punkterna till ett arbetsdokument och fyll i dem före första körningen:

• Uppgift: Vad ska agenten leverera, i vilket format och till vilken mapp?
• Ägare: Vem får starta, pausa och stoppa piloten?
• Källa: Vilka original kopierades och när?
• Tillåtet innehåll: Vilka filer och dataklasser får användas?
• Förbjudet innehåll: Vad får aldrig finnas i testmappen?
• Tillåtna åtgärder: Läsa, skapa utkast, skriva i utmapp eller något annat?
• Förväntade destinationer: Vilka domäner och lagringsplatser ska förekomma?
• Kanariefil: Vilken falsk markör används och var kontrolleras den?
• Godkänt resultat: Vilka krav måste uppfyllas innan en människa accepterar körningen?
• Stoppregel: Vilket fynd pausar piloten direkt?
• Städbevis: Hur verifieras lokal rensning, retention och eventuell radering?
• Beslutsdatum: När väljer ni att stoppa, justera eller gå vidare?

Tre rimliga första tester

Kodprojekt: Kopiera en enda modul till en ny katalog utan Git-historik. Ersätt konfiguration med falska värden. Be agenten föreslå en ändring, men inte skriva den. Kontrollera sedan lästa filer, nätverksdestinationer och diff.

Ekonomiadministration: Lägg 20 sanerade PDF-fakturor i en testmapp. Låt agenten skapa en CSV med fasta kolumner och markera osäkerheter. Jämför mot en manuellt kontrollerad facitfil innan ni provar riktiga dokument.

Skola eller kontor: Använd publika styrdokument och påhittade mötesanteckningar. Be om en sammanställning med källhänvisningar. Elevdata, personalärenden och autentiserade molnmappar hålls utanför tills dataflöde, loggar och godkännanden är verifierade.

Det här är ett typiskt Verktygssmide-problem: inte ”vilken agent är bäst?”, utan ”vilken mapp, data och åtgärd får agenten använda, och vilket bevis krävs innan vi litar på resultatet?”. Om er pilot inte kan svara på de frågorna är den inte redo för originalfilerna.