Säkerhetsproblemet med AI-genererade arbetsflöden är inte att de misslyckas. Det är att de fungerar, utan att någon kan förklara hur.
”Våra medarbetare hanterar ett verkligt farligt problem: automatisering som fungerar, men som ingen förstår”, säger Yelena Mujibur Sheikh, cybersäkerhetsingenjör på BNSF Railway, i en artikel för Dark Reading. Observationen är ärligare än vad de flesta leverantörsrapporter tillåter sig att vara, och just därför är den mer användbar.
Scenariot som Sheikh beskriver är förekommande i organisationer som snabbt har börjat använda AI-verktyg. En utvecklare eller analytiker använder en AI-assistent för att skapa ett arbetsflöde; arbetsflödet löser ett omedelbart problem; det tas i drift, och börjar sedan i tysthet samla på sig åtkomsträttigheter som det aldrig medvetet tilldelades. Ingen granskar den underliggande logiken. Ingen kartlägger vilka data det rör vid. Det bara körs.
Behörighetsproblemet är strukturellt, inte oavsiktligt
AI-genererad kod tenderar att begära breda behörigheter eftersom det är den enklaste vägen till ett fungerande resultat. Modellen optimerar för kod som körs, inte för kod med minsta möjliga behörighet. Resultatet blir automatisering som ofta har mer åtkomst än någon mänsklig granskare medvetet skulle godkänna.
Veracodes forskning om säkerhet i AI-genererad kod visar att osäkra mönster och sårbara beroenden regelbundet förekommer i kod som produceras av stora språkmodeller, inte för att modellerna är skadliga, utan för att de tränas på kodbaser som innehöll just de mönstren. Resultatet speglar underlaget. Om träningsdata innehöll dåligt avgränsade tjänstekonton och hårdkodade inloggningsuppgifter kommer den genererade koden att återskapa dem.
Den andra strukturella frågan är det som Sheikh och andra kallar skuggautomatisering: AI-genererade arbetsflöden som tas i drift utanför formell IT-styrning, ofta av verksamhetsteam som har direkt tillgång till lågkods- eller no-code-plattformar. Dessa arbetsflöden syns inte i tillgångsinventeringar. De omfattas inte av åtkomstgranskningar. Säkerhetsteam kan inte övervaka det de inte kan se.
Förgiftade modeller och kedjeeffekter i resultaten
Den allvarligare risken finns längre upp i kedjan. När en AI-modell som används i ett automatiserat beslutsflöde komprometteras eller manipuleras stannar konsekvenserna inte lokalt. En förgiftad modell kan i det tysta godkänna bedrägliga transaktioner, generera felaktiga affärsinsikter eller styra data fel på sätt som ser ut som normal drift tills skadan redan är skedd.
Dark Reading rapporterade om en relaterad angreppsklass i maj 2025: falska felrapporter som skickas till AI-kodningsagenter och får agenten att införa skadlig kod i ett kodarkiv i stor skala. Agenten vet inte att felrapporten är fabricerad. Den bearbetar indata, genererar en åtgärd och committar den. I många CI/CD-pipelines som är konfigurerade att lita på agentens output granskar ingen människa ändringen innan den når produktion.
Det är kaskadproblemet i konkret form. En manipulerad input, behandlad av ett betrott automatiserat system, sprids vidare genom varje beroende nedströms. Den hastighet som gör AI-stödd utveckling attraktiv är samma egenskap som gör den farlig när indata inte kan litas på.
Jag är skeptisk till leverantörsrapporter som kopplar exakta ekonomiska förlustsiffror till den här riskkategorin utan att tydligt redovisa metodiken bakom siffran. Det strukturella problem som Sheikh beskriver är verkligt och väl belagt. Det är när den risken blåses upp till rubrikvänlig statistik som kommersiella intressen tenderar att förvränga bilden.
Tre kontroller som är värda att införa före nästa driftsättning
Ingen av åtgärderna här är ny. Det är samma kontroller som gäller för alla automatiserade system, men tillämpade konsekvent på en kategori av automatisering som organisationer ofta har behandlat som undantagen.
Granska AI-genererad kod före driftsättning, inte efteråt. Det innebär att AI-assisterad output ska behandlas på samma sätt som vilket externt beroende som helst: statisk analys, beroendeskanning och en mänsklig granskare som förstår vad koden gör och vad den kan komma åt. Att acceptera agentoutput direkt in i produktionspipelines utan detta steg är inte en hastighetsoptimering. Det är en ogranskad ändringshantering.
Avgränsa behörigheter redan vid skapandet, inte i efterhand. AI-genererade arbetsflöden som begär bred åtkomst bör ifrågasättas vid granskning, inte trimmas ned först när en säkerhetsgranskning upptäcker exponeringen. Principen om minsta möjliga behörighet behöver verkställas på plattformsnivå, inte lämnas åt utvecklaren att tillämpa manuellt.
Kartlägg er skuggautomatisering nu. Alla team som använder no-code- eller low-code-AI-plattformar för att bygga arbetsflöden som ansluter till produktionsdata eller produktionssystem bör vara skyldiga att registrera dessa arbetsflöden hos IT. Inventeringen behöver inte vara komplex, men den måste dock genomföras och registret skapas. Det är inte möjligt att övervaka förändringar i arbetsflöden som du inte är medvetna om.
Referenser
- AI-Generated Workflows Are a Silent Security Disaster
- Fake Bug Report Hijacks AI Coding Agents at Scale
- AI-Generated Code Security Risks
This post is also available in:
English
