Prelucrarea imaginilor trebuie inclusă în aprobare

O persoană nu poate aproba în cunoștință de cauză o acțiune bazată pe o imagine dacă vede o reprezentare care ascunde ce primește modelul. Prelucrarea imaginii trebuie inclusă în limitele aprobării. Proiectarea trebuie să restrângă și acțiunile disponibile după interpretare, fiindcă vizualizarea imaginii transformate nu dovedește că orice instrucțiune inclusă în ea va fi recunoscută sau respinsă.

Privind retrospectiv din noiembrie 2026, cercetarea Trail of Bits publicată la 21 august 2025 a scos la iveală o nepotrivire cu efecte serioase: micșorarea putea dezvălui instrucțiuni care nu apăreau la vizualizarea imaginii în rezoluția originală. Cercetătorii au raportat fenomenul în mai multe sisteme numite. Rezultatele arată comportamentul configurațiilor investigate, nu susceptibilitatea universală a tuturor modelelor multimodale sau a implementărilor actuale.

Permisiunile din demonstrație contează

În demonstrația cu Gemini CLI, cercetătorii au folosit o configurație Zapier MCP cu trust=True, care permitea apelarea uneltelor fără confirmarea utilizatorului. Au raportat extragerea neautorizată a datelor din calendar prin acea configurație, fără ca utilizatorul să poată previzualiza imaginea transformată. Condițiile trebuie prezentate alături de rezultat. Exemplul nu dovedește că o fereastră de confirmare explicită a fost învinsă în orice situație sau că toate instalările acordă aceleași permisiuni.

Lecția pentru produs depășește integrarea respectivă. Un flux poate arăta unei persoane originalul încărcat, apoi poate trimite modelului o variantă redimensionată. Dacă decizia persoanei autorizează modelul să folosească unelte, ea privește mai mult decât aspectul obișnuit al originalului. Privește și reprezentarea interpretată de sistem, precum și operațiile pe care acea interpretare le poate declanșa.

Problema aprobării există chiar dacă prelucrarea este obișnuită și are un scop legitim. Generarea miniaturilor, decuparea sau alte transformări pot interveni între încărcare și interpretare. Un ecran de verificare care numește doar fișierul încărcat lasă o etapă importantă neexplicată. Limita relevantă urmărește datele folosite efectiv pentru decizia cu consecințe, nu fișierul care a intrat primul în produs.

Păstrați legătura dintre reprezentări

O interfață defensivă propusă ar trebui să deosebească originalul de varianta trimisă modelului. Explicați transformarea care a produs-o și asociați ambele reprezentări cu același element trimis. Dacă furnizorul face prelucrări suplimentare nedivulgate, precizați că varianta vizibilă acoperă doar etapa controlată de aplicație. A promite identitate exactă fără acces la celelalte etape ar crea o nouă asigurare înșelătoare.

Înregistrarea ar trebui să identifice reprezentarea verificată și reprezentarea trimisă. Dacă prelucrarea se schimbă după aprobare, aplicația ar trebui să stabilească dacă aprobarea rămâne valabilă. Persoana care a inspectat o variantă nu a aprobat neapărat o altă decupare, generată ulterior. Este o cerință de produs propusă, nu afirmația că un sistem numit implementează deja o asemenea legătură.

Afișarea ambelor imagini poate oferi persoanei informații mai bune, dar complică și interfața. O previzualizare mică poate ascunde detalii în oricare dintre versiuni. Persoana are nevoie de o modalitate practică de a inspecta conținutul relevant și de a înțelege de ce există două reprezentări. Încă o miniatură minusculă lângă prima ar îndeplini o specificație superficială fără să rezolve problema deciziei.

Aprobarea ar trebui să numească acțiunea

Luați exemplul ilustrativ al unui asistent care extrage date calendaristice din imaginea unui client. Citirea imaginii și redactarea unei înregistrări de calendar cer alte permisiuni decât trimiterea datelor existente din calendar către altă destinație. Permisiunile utile primei sarcini pot rămâne restrânse. O instrucțiune necunoscută din imagine nu ar trebui să primească drepturi mai largi doar fiindcă fișierul a fost încărcat de un utilizator autorizat.

Aprobarea propusă poate numi operația, destinația și datele implicate. Dacă asistentul vrea să trimită un mesaj, persoana ar trebui să vadă ce va fi trimis și cui. Dacă vrea să modifice o înregistrare, aprobarea ar trebui să privească acea modificare. Verificarea conținutului de intrare și aprobarea efectului concret al unei unelte răspund unor întrebări diferite; niciuna nu ar trebui să o înlocuiască implicit pe cealaltă.

Același raționament se aplică integrărilor care reunesc multe operații într-un singur conector. Un utilizator poate avea nevoie de acces la calendar fără a avea nevoie de toate uneltele legate de calendar la fiecare sarcină. Restrângeți uneltele la activitatea cerută și supuneți efectele importante verificărilor potrivite. Este o propunere de proiectare, nu afirmația că uneltele restrânse elimină toate atacurile prin instrucțiuni sau fac sigură interpretarea oricărei imagini.

O previzualizare identică nu este suficientă

Cea mai puternică obiecție este că și o previzualizare fidelă lasă persoana în fața unui conținut ambiguu sau înșelător. Poate rata o instrucțiune, o poate înțelege greșit sau poate aproba o acțiune dintr-un motiv fără legătură. Prelucrările suplimentare ale furnizorului pot rămâne și ele inaccesibile verificării. Identitatea previzualizării nu poate deveni o garanție completă de securitate.

Obiecția susține împărțirea responsabilităților. Vizibilitatea rezolvă o anumită nepotrivire a informațiilor. Permisiunile restrânse limitează consecințele unei interpretări greșite. Confirmarea unei acțiuni precise permite evaluarea efectului propus efectiv. Fiecare mecanism are alt rol și alte moduri de a eșua. Echipa ar trebui să spună ce mecanism susține fiecare afirmație, în loc să prezinte eticheta generală „aprobat de om” drept dovadă de siguranță.

Pentru planificarea acceptării, folosiți imagini reprezentative inofensive și analizați traseul documentat al prelucrării și efectele propuse. Includeți variante modificate și informații de prelucrare indisponibile. Sunt verificări defensive sugerate; pentru articol nu s-au generat sau executat imagini de atac, instrucțiuni malițioase, exploatări ori teste prin API-uri de modele. Cercetarea istorică furnizează observația, iar cerințele de interfață sunt recomandări deduse din ea.

În dezvoltarea software la comandă, întrebați ce a văzut efectiv persoana înainte de a întreba dacă a existat o aprobare. Păstrați legătura cu datele trimise modelului, apoi limitați acțiunile pe care acele date le pot influența. Rezultatele din august fac din această legătură o responsabilitate explicită a proiectării. Originalul afișat nu poate susține singur promisiunea că persoana a verificat informațiile folosite de sistem.