KO VSEBINA ZAČNE UKAZOVATI

Aprila 2026 je Googlova varnostna ekipa objavila rezultate pregleda več zaporednih posnetkov javnega spleta v arhivu Common Crawl. Iskala je vzorce, značilne za posredni prompt injection: navodila, vstavljena v vsebino, ki bi jo lahko pozneje obdelal sistem umetne inteligence.

Raziskovalci so našli različne primere. Nekateri so bili eksperimentalni ali razmeroma neškodljivi, drugi so skušali vplivati na povzetke, priporočila in nadaljnje vedenje AI-sistemov. V kategoriji, ki jo je Google označil kot zlonamerno, se je med novembrom 2025 in februarjem 2026 število zaznanih primerov relativno povečalo za 32 odstotkov. Google je ob tem opozoril, da je bila večina opaženih poskusov še razmeroma preprosta in da Common Crawl ne zajema pomembnega dela vsebin za prijavnimi zidovi ter družbenih omrežij.

Rezultat ne dokazuje množičnega uspešnega prevzemanja AI-agentov. Potrjuje pa, da se navodila, namenjena vplivanju na sisteme umetne inteligence, že pojavljajo v dejanski spletni vsebini.

Dokument, elektronsko sporočilo, spletna stran ali rezultat iskanja so za uporabnika predvsem vsebina. Pri AI-agentu lahko ista vsebina postane tudi vhod v proces, ki vpliva na njegovo naslednje dejanje.

Ko podatki in navodila uporabljajo isti kanal

Pri običajni programski opremi poskušamo podatke in izvršilno logiko čim jasneje ločiti. Vrednost v podatkovnem polju naj ostane podatek, programska koda pa določa, kaj se z njim sme zgoditi. Velik del klasične aplikacijske varnosti je nastal prav zato, ker porušena meja med tema vlogama omogoča napade, kot so SQL injection, command injection ali nevarna obdelava poti do datotek.

Veliki jezikovni modeli imajo drugačno izhodišče. Navodilo uporabnika »povzemi ta dokument« je zapisano v naravnem jeziku, v istem jeziku pa je zapisana tudi vsebina dokumenta. Če se v njem pojavi besedilo, ki modelu naroča, naj prezre prvotno nalogo, razkrije podatek ali uporabi določeno orodje, mora sistem razlikovati med vsebino, ki jo obdeluje, in navodilom, ki sme usmerjati njegovo vedenje.

OWASP pri posrednem prompt injectionu posebej opozarja na zunanje vire, kot so dokumenti, spletne strani, elektronska sporočila, rezultati orodij in shranjeni podatki. Njegov standard LLMSVS zahteva tudi, da se shranjeni podatki, podatki zunanjih API-jev in rezultati predhodnih modelskih odgovorov obravnavajo kot nezaupljivi vhodi, preden lahko ponovno vplivajo na model ali naslednji sistem.

Za poskus takšnega napada napadalcu ni treba neposredno komunicirati z agentom. Zlonamerno navodilo lahko vstavi v vir, za katerega pričakuje, da ga bo agent pozneje obdelal. Uspeh s tem še ni zagotovljen. Vsebina mora prestati zaščite sistema, vplivati na vedenje modela in doseči funkcijo, prek katere lahko nastane dejanska posledica.

Legitimna naloga lahko odpre nezaupljiv vhod

Predstavljajmo si zaposlenega, ki agentu naroči, naj pregleda današnjo elektronsko pošto in pripravi seznam sporočil, na katera mora odgovoriti. Naloga je legitimna. Uporabnik ni vnesel nevarnega ukaza, agent pa bere sporočila, ker je to njegova naloga.

Eno izmed njih lahko vsebuje besedilo, namenjeno modelu. Če zaščitne plasti ne preprečijo njegovega vpliva, lahko takšna vsebina spremeni nadaljnjo obdelavo. Pri raziskovalnem agentu je mehanizem podoben. Agent obišče spletno stran zaradi informacij, na strani pa je navodilo, ki skuša vplivati na njegovo oceno izdelka, izbiro nadaljnjih virov ali naslednji korak.

Google je v analizi Common Crawla našel tudi primere vsebin, katerih namen je bil vplivati na prikaz ali priporočanje strani v sistemih umetne inteligence ter na nadaljnje vedenje modela. Iz analize ni mogoče sklepati, da so bili takšni poskusi praviloma uspešni. Kaže pa, da je lahko del napadalne površine tudi vsebina, ki jo agent bere med povsem običajnim opravljanjem naloge.

Posledico določajo orodja in dovoljenja

Za varnostni problem, ki ga obravnavamo tukaj, je ključna možnost agenta, da uporablja orodja in druge sisteme. Poleg ustvarjanja besedila lahko išče po podatkovnih zbirkah, bere datoteke, kliče API-je, spreminja zapise, pošilja sporočila ali uporablja funkcije, ki delujejo zunaj samega modela.

Zato enaka napačna interpretacija nima vedno enake posledice. Pri sistemu brez izvršilnih možnosti se lahko konča z napačnim povzetkom. Pri agentu z dostopom do poslovnih funkcij lahko vpliva na klic orodja in parametre, ki jih bo sistem uporabil.

NIST je marca 2026 objavil rezultate velikega javnega red-team tekmovanja, osredotočenega na takšne scenarije. Več kot 400 sodelujočih je izvedlo več kot 250.000 poskusov proti 13 naprednim modelom v nalogah, ki so vključevale uporabo orodij, programiranje in upravljanje računalnika. Pri vseh testiranih ciljnih modelih je bil najden najmanj en uspešen napad.

Izvirna raziskava navaja 464 udeležencev, približno 272.000 napadalnih poskusov, 8.648 uspešnih napadov in 41 scenarijev. Stopnje uspešnosti so se med modeli močno razlikovale, zato rezultatov ni mogoče prenesti na vsak agent ali vsako okolje. Raziskava kljub temu potrjuje, da posredni prompt injection ostaja praktičen varnostni problem tudi pri sodobnih modelih in različnih vrstah agentnih nalog.

Od vsebine do dejanja mora obstajati tehnična pot

Prompt injection sam po sebi še ni oddaljeno izvajanje kode. Za resno posledico mora obstajati povezava med vplivom na model in funkcijo, ki lahko nekaj dejansko izvede.

Microsoft je maja 2026 objavil analizo dveh odpravljenih ranljivosti v odprtokodnem ogrodju Semantic Kernel. Pri CVE-2026-26030 je bilo izkoriščanje mogoče le ob določenih pogojih. Napadalec je potreboval možnost prompt injectiona, agent pa je moral uporabljati Search Plugin z In-Memory Vector Store v prizadeti konfiguraciji. Parameter, na katerega je lahko vplival model, se je nato nevarno vključil v Pythonov izraz in omogočil izvajanje kode. Ranljivost je bila odpravljena v različici Semantic Kernel 1.39.4.

Tehnična pot je bila:

zunanja vsebina → model → izbira orodja → parameter → programska funkcija → dejanje

Model pri tem ni ustvaril izvršilne funkcije. Nezaupljiv vhod je prek modela dosegel komponento, ki jo je že imela in je parameter obdelala na nevaren način.

Za varnostno analizo je zato pomembna celotna pot od vhodne vsebine do funkcije, ki jo sistem izvede. Prav na njej lahko arhitektura prepreči, da bi nezaupljiv podatek pridobil več vpliva, kot ga za svojo osnovno nalogo potrebuje.

Zaupanje mora slediti vsebini, ne samo sistemu

Organizacije pogosto pripisujejo zaupanje sistemu, iz katerega podatek prihaja. Notranji SharePoint, službeni poštni predal, CRM ali sistem za prijavo napak imajo praviloma drugačen status kot naključna spletna stran.

Pri agentih takšna razvrstitev ni dovolj. V zanesljivem sistemu se lahko pojavi vsebina, na katero je vplivala zunanja oseba. V službeni poštni predal pride sporočilo stranke. V sistem za podporo besedilo vnese uporabnik. V repozitorij pride zunanji pull request. Spletna stran organizacije lahko prikazuje komentarje obiskovalcev. Pri presoji zaupanja zato ni pomemben samo sistem, iz katerega je vsebina prišla. Pomembno je tudi, kdo je lahko vplival na posamezen del vsebine in kakšno vlogo sme ta imeti pri nadaljnjem izvajanju.

Microsoftova aktualna priporočila gredo v isto smer. Pozive, dokumente, pridobljene odlomke, rezultate orodij in pomnilniške zapise je treba obravnavati kot potencialno nezaupljive vhode. Njihova priporočila vključujejo ločevanje navodil od podatkov, validacijo strukturiranih polj, preverjanje vira in omejevanje vpliva zunanje vsebine na nadaljnje delovanje sistema.

Bralna pot ni izvršilna pot

Agent lahko iz računa izlušči dobavitelja, datum, znesek in številko bančnega računa. To je naloga pridobivanja podatkov. Drugo vprašanje je, ali lahko na podlagi tega rezultata spremeni podatke dobavitelja ali sproži plačilo.

Varnejša zasnova te korake loči. Model lahko pripravi strukturiran predlog, druga komponenta pa preveri njegovo shemo, dovoljene vrednosti, identiteto cilja in poslovna pravila. Šele po teh kontrolah je mogoče ugotavljati, ali je določeno dejanje dovoljeno.

Takšna arhitektura zmanjšuje odvisnost od predpostavke, da bo model vedno pravilno prepoznal zlonamerno navodilo. Microsoft pri obrambi pred posrednim prompt injectionom zato priporoča večplastni pristop, ki vključuje obravnavo nezaupljive vsebine, nadzor uporabe orodij, najmanjše privilegije in potrjevanje tveganih operacij.

Jezikovni model lahko pripravi predlog dejanja. Pri pomembnih operacijah je varneje, da avtorizacijo določajo pravila in preverljivi parametri zunaj modela.

Dovoljenja omejujejo posledice

Načelo najmanjših privilegijev pri agentih dobi zelo konkreten pomen. Agent, ki povzema elektronsko pošto, praviloma ne potrebuje pravice do pošiljanja sporočil. Sistem, ki analizira dokumente, ne potrebuje samodejne možnosti njihovega brisanja. Agent za poizvedovanje po poslovnih podatkih ne potrebuje splošne pravice do njihovega spreminjanja.

Kadar je privilegirana operacija potrebna, je mogoče dovoljenje omejiti na konkretno dejanje, cilj in čas. S tem se zmanjša obseg posledic tudi v primeru, ko zaščita pred zlonamernim vhodom ne deluje tako, kot smo pričakovali.

Pomemben je tudi način potrjevanja. Če agent uporabniku samo pove, da priporoča spremembo bančnega računa dobavitelja, uporabnik preverja predvsem njegovo razlago. Kontrolna plast je močnejša, kadar iz dejanskih parametrov operacije jasno pokaže, kateri objekt bo spremenjen, katera vrednost se zamenjuje in s čim.

Pri visoko tveganih dejanjih naj potrditev zato temelji na dejanskih parametrih operacije, ne samo na prostem besedilu, ki ga je ustvaril agent.

Nadzor se ne konča pri modelu

Septembra 2026 je OWASP objavil Agent Control Standard. Ta agentno varnost obravnava širše od zaščite posameznega poziva in poudarja preglednost agentov, sledljivost njihovih dejanj ter možnost izvajanja varnostnih politik med samim delovanjem.

To je pomembno, ker zaščita pred prompt injectionom ni samo vprašanje filtriranja besedila pred vstopom v model. Pri agentu je treba nadzorovati tudi prehod od modelskega rezultata do orodja, dovoljenja posamezne operacije in kontekst, v katerem se dejanje izvaja. OWASP je avgusta 2026 objavil tudi posodobljeni LLM Top 10 za leto 2026. Dokument skupaj z Agent Control Standardom odraža širši premik varnostne prakse: od zaščite posameznega modela proti nadzoru sistema, v katerem model uporablja zunanje podatke, orodja in dovoljenja.

Pred uvedbo je treba poznati doseg agenta

Ocena tveganja ne more temeljiti samo na imenu ali zmogljivosti uporabljenega modela. Dva sistema z istim modelom imata lahko povsem različna varnostna profila.

Pred produkcijsko uporabo je smiselno določiti:

katere zunanje vire agent bere, kdo lahko vpliva na njihovo vsebino, katera orodja lahko kliče, katere parametre pri teh klicih lahko določa model, katera dovoljenja ima posamezno orodje, katera dejanja se izvedejo samodejno, katera zahtevajo dodatno avtorizacijo, kako dolgo veljajo privilegiji, kateri parametri se preverjajo zunaj modela, kako se prepreči izvedba visoko tveganega dejanja ob zaznanem odstopanju.

Za pomembne operacije je koristno ohraniti tudi podatke, potrebne za rekonstrukcijo poti od nezaupljive vsebine do izvršilne funkcije. Sem sodijo izvor relevantnega vhoda, uporabljeno orodje, dejanski parametri klica in morebitna odobritev. Namen take evidence v tem članku ni splošna analiza dnevnikov, temveč preverjanje konkretne izvršilne poti agenta. Agent, ki bere javno dokumentacijo in pripravlja osnutke, ima drugačen profil tveganja od agenta, ki iz iste vsebine neposredno dostopa do pošte, poslovnih podatkov, datotek ali sistemskih funkcij. Tudi pri istem modelu posledico napake v veliki meri določajo orodja in dovoljenja, ki so mu na voljo.

Varnostna meja je med vsebino in pooblastilom

Razvoj modelov bo zmanjšal del tveganja. Boljše zaznavanje prompt injectiona, označevanje nezaupljive vsebine, specializirani klasifikatorji in druge zaščite že danes prestrežejo del napadov.

Aktualna priporočila NIST-a, Microsofta in OWASP-a pa imajo skupno izhodišče: zaščita znotraj modela ni edina varnostna meja. Arhitektura mora predvideti možnost napačne interpretacije in omejiti njen doseg v naslednjih plasteh.

Pri uvedbi agenta zato ni dovolj preveriti, ali model pravilno opravlja nalogo. Pomembno je tudi, kaj lahko doseže vsebina, ki jo model pomotoma obravnava kot navodilo.

Dokument, sporočilo ali spletna stran lahko vplivajo na model zato, ker jih mora agent pri svojem delu prebrati. Iz tega ne sledi, da jim pripada tudi pravica usmerjati privilegirana dejanja sistema.

Vsebina lahko govori agentu. To ji še ne daje pooblastila.

EVIDENCE PROFILE

Dokazni profil članka

Profil pokaže vrsto dokazne podlage in omejitve osrednjega argumenta.

OSREDNJI DOKAZPosredni prompt injection postane resna varnostna težava, ko nezaupljiva vsebina lahko vpliva na model in obstaja tehnična pot od tega vpliva do orodja z dejanskimi pooblastili.

RAZISKAVE0

DOKUMENTACIJA9

PREDOBJAVE0

UREDNIŠKI PREIZKUSNE

PREVERJENO2026-09-09

Viri

1. 01ADVISORYGoogle
   Google Security Blog, »AI threats in the wild: The current state of prompt injections on the web«, 23. april 2026 Analiza poskusov posrednega prompt injectiona v javnih spletnih vsebinah. Vir je pomemben predvsem kot dokaz, da se takšna navodila pojavljajo zunaj laboratorijskih testov.
2. 02PRIMARY DOCUMENTATIONDziemian et al., »How Vulnerable Are AI Agents to Indirect Prompt Injections? Insights from a Large-Scale Public Competition«, 16.
   Dziemian et al., »How Vulnerable Are AI Agents to Indirect Prompt Injections? Insights from a Large-Scale Public Competition«, 16. marec 2026 Primarni raziskovalni članek o približno 272.000 napadalnih poskusih proti 13 modelom v 41 agentnih scenarijih.
3. 03PRIMARY DOCUMENTATIONNational Institute of Standards and Technology (NIST)
   NIST CAISI, »Insights into AI Agent Security from a Large-Scale Red-Teaming Competition«, 23. marec 2026 Uradni NIST-ov povzetek in interpretacija rezultatov javnega red- team testiranja agentov.
4. 04ADVISORYMicrosoft
   Microsoft Security Blog, »When prompts become shells: RCE vulnerabilities in AI agent frameworks«, 7. maj 2026 Tehnična analiza ranljivosti v Semantic Kernelu in konkretne poti od modelskega vhoda do programske funkcije.
5. 05PRIMARY DOCUMENTATIONMicrosoft
   Microsoft Learn, »Defend against indirect prompt injection attacks«, posodobljeno 23. marca 2026 Priporočila za večplastno zaščito pred posrednim prompt injectionom.
6. 06PRIMARY DOCUMENTATIONMicrosoft
   Microsoft Learn, »Input, Context, and Retrieval Hygiene«, posodobljeno 1. avgusta 2026 Aktualna priporočila za obravnavo dokumentov, pozivov, rezultatov orodij, pomnilnika in drugih vsebin, ki jih model bere, kot potencialno nezaupljivih vhodov.
7. 07STANDARDOWASP
   OWASP LLM Verification Standard 2.0 Standard za preverjanje varnosti sistemov z velikimi jezikovnimi modeli, vključno z neposrednim in posrednim prompt injectionom ter varno uporabo modelskih izhodov v naslednjih sistemih.
8. 08PRIMARY DOCUMENTATIONOWASP
   OWASP GenAI LLM Top 10 2026, 3. avgust 2026 Aktualna izdaja pregleda ključnih varnostnih tveganj aplikacij, ki uporabljajo velike jezikovne modele.
9. 09STANDARDOWASP
   OWASP Agent Control Standard, 1. september 2026 Okvir za preglednost agentov, sledljivost njihovih dejanj in izvajanje varnostnih politik med delovanjem.