Jedna komenda od AI, kilka interpretacji powłoki

plan zajęć.txt jest jedną nazwą pliku. Program uruchomiony przez agenta może jednak dostać dwa argumenty: plan i zajęć.txt. Takie polecenie może być poprawne składniowo, a raport nadal pokazać kod zakończenia zero. Program dostał jednak inne dane, niż uzgodniono.

Powłoka to program interpretujący tekst poleceń, na przykład Bash. Pomiędzy zdaniem użytkownika a uruchomioną czynnością może wykonać dodatkową pracę: rozwinąć zmienną, znaleźć pliki pasujące do wzorca albo obliczyć wyrażenie. Dlatego przy odbiorze pracy agenta trzeba sprawdzić, jakie argumenty rzeczywiście otrzymał program. Sam wygląd komendy w rozmowie nie daje jeszcze tej odpowiedzi.

Do tego tekstu wykonano małą kontrolną próbę w osobnym katalogu ze sztucznymi plikami. Uruchamiany program jedynie wypisywał otrzymane argumenty; nie przenosił ani nie usuwał materiałów i nie korzystał z sieci. Użyto Bash 3.2.57 na macOS oraz Node.js 24.22.1. To dowód dotyczący opisanej próby, a nie ocena wszystkich powłok, narzędzi agentowych czy systemów operacyjnych.

Co rzeczywiście dotarło do programu

W pierwszej parze prób nazwa plan zajęć.txt była wartością zmiennej. Gdy rozwinięcie tej zmiennej nie zostało ujęte w cudzysłów, program dostał dwa argumenty. Przy rozwinięciu w podwójnym cudzysłowie otrzymał jeden, z zachowaną spacją. Zmiana nie dotyczyła treści dokumentu. Dotyczyła granicy danych przekazywanych do programu.

Druga para używała nazwy wersja[1].txt. W katalogu celowo istniał również plik wersja1.txt. Bez odpowiedniego ujęcia rozwiniętej zmiennej program otrzymał tę drugą nazwę. Nawiasy zostały potraktowane jako część wzorca dopasowania nazw. Po ujęciu zmiennej w podwójny cudzysłów otrzymał dosłownie wersja[1].txt.

Wynik mógłby zmylić osobę sprawdzającą tylko liczbę argumentów: w obu tych wariantach był jeden. Różniła się jego wartość. Dlatego odbiór powinien porównywać również dokładne nazwy, a nie tylko stwierdzać, że polecenie „dostało plik”. Przy podobnych dokumentach pomyłka może wyglądać wiarygodniej niż całkowity błąd uruchomienia.

Program kontrolny musi pokazać listę argumentów, które rzeczywiście otrzymał. Wypisanie przez agenta tekstu, który zamierza uruchomić, nie wystarczy: pomija właśnie etap interpretacji. W naszej próbie lista była zapisywana jako dane z oddzielnymi pozycjami. Dzięki temu nie trzeba zgadywać, czy odstęp na ekranie oddziela dwa argumenty, czy należy do jednej nazwy. Podgląd zwykłego sklejonego zdania mógłby wyglądać podobnie w obu przypadkach.

Zestaw plików także jest częścią warunków próby. Dopasowanie nawiasów ujawniło się dlatego, że istniała pasująca nazwa bez nawiasów. W katalogu bez takiego pliku wynik mógłby być inny, zależnie również od ustawień powłoki. Powtórzenie powinno zachować tę kontrolowaną parę, zamiast używać dowolnego folderu z bieżącymi dokumentami.

Podręcznik Bash w części Shell Expansions opisuje kolejność rozwijania zapisu, podziału na słowa i dopasowywania nazw plików. Niektóre z tych etapów mogą zwiększyć liczbę otrzymanych słów. Ostateczna lista argumentów nie musi wyglądać jak początkowy tekst.

W praktyce firmowej nazwy ze spacjami i nawiasami nie są egzotycznym przypadkiem. Mogą pochodzić od klienta, programu eksportującego albo osoby odkładającej kolejną wersję. Żądanie, aby wszyscy na zawsze używali wyłącznie krótkich nazw bez spacji, przenosi odpowiedzialność za sposób uruchamiania na obieg dokumentów. Jeśli proces ma ograniczenia nazw, powinny być jawne; nie mogą zastępować kontroli wykonania.

To samo dotyczy ścieżki katalogu. Nawet poprawnie przygotowana nazwa pliku może zostać źle przekazana, jeśli nazwa nadrzędnego folderu zawiera spację. W materiale kontrolnym warto rozróżnić te poziomy. Agent powinien zachować cały uzgodniony adres dokumentu, nie tylko ostatni jego fragment.

Podwójny cudzysłów nie oznacza „przestań wszystko interpretować”

W kolejnej próbie użyto sztucznej nazwy pomiar-$((2+3)).txt. Zapis zawiera jedynie nieszkodliwe dodawanie dwóch liczb. Kiedy nazwę wklejono bezpośrednio w tekst polecenia wewnątrz podwójnego cudzysłowu, Bash wykonał to obliczenie. Program otrzymał pomiar-5.txt. Cudzysłów zachował jeden argument, ale nie jego zamierzoną dosłowną treść.

Gdy dokładnie tę samą nazwę przekazano jako wartość zmiennej i dopiero jej rozwinięcie ujęto w podwójny cudzysłów, program otrzymał dosłowny zapis z dodawaniem w nazwie. To istotne rozróżnienie. Powłoka nie traktuje każdej wartości zmiennej automatycznie jak nowego tekstu polecenia do ponownej interpretacji. Inny skutek powstał przy wcześniejszym sklejeniu całej komendy.

Opis podwójnego cudzysłowu w podręczniku Bash wskazuje znaki zachowujące specjalne znaczenie, między innymi dolar i znacznik podstawiania polecenia. Samo otoczenie dowolnie sklejonego tekstu podwójnym cudzysłowem nie zamienia go w dosłowną daną.

W trakcie przeglądu tekstu dodano jeszcze jeden kontrolny wariant. Nazwę z dodawaniem zapisano funkcją JSON.stringify, a powstały tekst dołączono do komendy. Wynik znowu brzmiał pomiar-5.txt. Zapis JSON otrzymał więc poprawne cudzysłowy dla swojego formatu, ale nie zachował nazwy jako dosłownej danej po interpretacji przez Bash. To nie jest uniwersalna funkcja przygotowania argumentów powłoki. Formatowanie danych i przygotowanie tekstu wykonywalnego rozwiązują różne problemy.

Nie wynika z tego prosta recepta „zamień wszędzie podwójny na pojedynczy”. Dane mogą same zawierać apostrof, a polecenie może przechodzić przez kilka warstw programu. Potrzebne jest rozwiązanie właściwe dla konkretnego miejsca interpretacji. Osoba odbierająca proces powinna umieć wskazać, gdzie kończy się tekst budowanej komendy, a zaczyna osobny argument.

Sprawdź także, czy prezentacja w interfejsie odpowiada rzeczywistemu wywołaniu. Narzędzie może wyświetlać wygodny, skrócony zapis, a wykonywać program z listą argumentów. Może też pokazywać pozornie uporządkowaną listę, którą później skleja z powrotem i przekazuje powłoce. Wniosek musi dotyczyć drogi wykonania, nie tylko obrazka z terminalem.

W operacyjnym przeglądzie Aeneia Audit można rozdzielić zamiar agenta, dane przekazane narzędziu i potwierdzony skutek. Przy poleceniach ten podział pozwala ustalić, czy błąd powstał w doborze czynności, przygotowaniu argumentów czy późniejszej interpretacji. Specjalistyczna ocena bezpieczeństwa implementacji wymaga odrębnego zakresu i właściwych kompetencji.

Osobna lista argumentów usuwa jedną warstwę, nie wszystkie pytania

W wariancie bezpośrednim program uruchomiono z osobną listą argumentów, bez powłoki pośredniej. Nazwa pomiar-$((2+3)).txt dotarła bez zmiany. To pokazuje różnicę w tej konkretnej drodze. Nie oznacza, że dowolny program uruchomiony w ten sposób bezpiecznie przyjmie każdą wartość.

Dokumentacja Node.js rozdziela exec i execFile: pierwsza funkcja uruchamia polecenie w powłoce, druga domyślnie uruchamia program bez jej wcześniejszego tworzenia. Opis zastrzega różnice platform, w tym obsługę plików bat i cmd na Windows.

Program docelowy może nadal interpretować otrzymaną nazwę jako opcję. Plik zaczynający się myślnikiem wymaga więc osobnego rozpoznania zachowania narzędzia. Ujęcie go w cudzysłów może zachować jeden argument, a mimo to nie nadać mu roli zwykłej ścieżki. W naszej próbie przygotowano taką nazwę jako materiał kontrolny, lecz nie wykonywano na niej operacji narzędziem kopiującym czy usuwającym.

OWASP zaleca oddzielanie danych od komendy oraz walidację argumentów. Wskazuje też ryzyko zmiany argumentów: zablokowanie dodatkowego polecenia nie oznacza jeszcze, że wartość zostanie zinterpretowana zgodnie z zamiarem. Znaczenie nadaje również program docelowy.

Jeżeli narzędzie obsługuje znacznik końca opcji, może on być częścią poprawnego wywołania. Trzeba potwierdzić to w dokumentacji danego programu. Nie traktuj dwóch myślników jako uniwersalnego zabezpieczenia każdej operacji. Podobnie osobna lista argumentów nie rozstrzyga, czy wskazano właściwy plik, właściwy katalog docelowy i dopuszczoną czynność.

Przy odbiorze archiwum ZIP dochodzi jeszcze zawartość kontenera i interpretacja zapisanych w nim ścieżek. Poprawne przekazanie nazwy archiwum do programu nie dowodzi, że rozpakowanie zachowa uzgodnione granice. Warto utrzymać te dwa pytania jako osobne próby, zamiast obiecać wszystko jednym „prawidłowo zacytowano ścieżkę”.

Zgoda dotyczy czynności, która naprawdę się wykona

Przycisk zatwierdzania może pokazywać „przygotuj kopię tego dokumentu”. Jeśli późniejszy etap zmienia jeden adres na dwa albo dopasowuje inny plik, wykonanie wychodzi poza treść tej decyzji. Zatwierdzanie działań AI musi zachować związek z konkretną operacją. Tutaj sprawdzamy, czy ten związek przetrwał interpretację polecenia.

Nie wymagaj od każdej osoby decydującej ręcznej analizy całej składni powłoki. W dobrze zaprojektowanym procesie może zobaczyć rozpoznawalny dokument, czynność i miejsce docelowe, a mechanizm wykonania zachowa je jako dane. Gdy narzędzie dopuszcza dowolny tekst komendy, zakres decyzji i potrzebne kompetencje są inne niż przy zamkniętej funkcji „skopiuj wskazany plik”.

Piaskownica agenta ogranicza, gdzie wolno działać. Nie poprawia automatycznie interpretacji. Niewłaściwy plik może zostać wybrany również wewnątrz dozwolonego katalogu. Z kolei prawidłowe argumenty nie dowodzą, że samo środowisko ma odpowiednio wąski dostęp. Odbiór powinien utrzymać obie te granice.

Oprócz nazwy komendy zapisz, który program został rzeczywiście uruchomiony. W kontrolnym zestawie wskazano konkretny program wypisujący argumenty, a nie przypadkowe narzędzie znalezione pod podobną nazwą. Jeżeli wykonawca zmieni później program docelowy lub uruchomi inną wersję, dawny wynik nie powinien samodzielnie potwierdzać nowej drogi. Kontrola argumentów ma dotyczyć tego wywołania, z którego rzeczywiście skorzysta agent.

Zachowaj warunki próby: system, powłokę, wersję narzędzia, katalog i kontrolne nazwy. Zapisz otrzymaną listę argumentów oraz wynik operacji tam, gdzie ją rzeczywiście wykonano. W opisanej próbie wszystkie uruchomienia zakończyły się kodem zero, chociaż część zmieniła granice lub treść argumentu. Kod zakończenia potwierdza działanie programu według jego reguł, nie zgodność całej czynności z poleceniem użytkownika.

Jeżeli po poprawce sposobu uruchamiania powstaje nowa wersja skryptu, powiąż przegląd z aktualną deltą. Powtórz te przypadki, których dotyczy zmiana. Sukces dla krótkiej nazwy bez spacji nie domyka problemu, który ujawniła nazwa z nawiasami. Z kolei sam zapis lepszej komendy nie jest wynikiem jej sprawdzenia.

Raport testu przygotowanego przez AI powinien również zachować to, czego próba nie dowodzi. Program wypisujący argumenty potwierdza ich granice i wartości. Nie potwierdza utworzenia kopii ani przyjęcia pliku przez inny system. Jeśli odbiór obejmuje również tę czynność, wykonawca powinien osobno sprawdzić wynik na przeznaczonych do tego materiałach i porównać zawartość.

Przed taką operacją ustal również zachowanie przy istniejącym celu. Nawet prawidłowa ścieżka nie rozstrzyga, czy plik ma zostać zastąpiony, pominięty czy zapisany pod inną nazwą. Prośba „przygotuj kopię” potrzebuje tej decyzji niezależnie od cudzysłowów. W dowodzie powinien być widoczny faktyczny plik wynikowy oraz skutek dla wcześniejszej pozycji, jeśli taka istniała. To dodatkowy zakres, którego kontrolny wydruk argumentów nie objął.

Na końcu raport ma pozwolić wybrać dalszą drogę: dopuścić określone wywołanie, ograniczyć je do znanych danych albo skierować mechanizm do poprawy. Przy naszej próbce granica jest widoczna od razu. plan zajęć.txt ma trafić jako jedna dokładna nazwa. Jeśli po drodze znika spacja, to nie dokument wymaga lekcji schludnego nazewnictwa.