Wyłączony plik w asystencie kodu: z czego dokładnie został wyłączony?

W katalogu projektu leży plik z napisem „Nie dla asystenta”. Zespół dopisuje go do reguły wyłączeń i sprawdza podpowiedzi kodu. Treść znika z sugestii. Następnego dnia ktoś uruchamia agenta, który odczytuje pliki inną drogą. Kartka na drzwiach została, lecz pojawiło się drugie wejście.

To fikcyjna sytuacja, którą warto rozpatrzyć przed dopuszczeniem prawdziwych materiałów do środowiska pracy. Sam wyraz „wyłączony” nie określa jeszcze, czy plik pominięto przy indeksowaniu, tworzeniu podpowiedzi, dołączaniu do czatu czy wykonywaniu poleceń. Te funkcje mogą korzystać z różnych mechanizmów i uprawnień.

Załóżmy, że firma Łuk pracuje nad aplikacją do układania ekspozycji. Asystent ma pomagać w kodzie interfejsu, a katalog z umowami partnerów pozostaje poza zakresem zadania. Firma nie zamierza sprawdzać zabezpieczeń na rzeczywistych umowach. Przygotowuje więc osobny projekt testowy, w którym katalog zawiera tylko sztuczny dokument z wymyślonym oznaczeniem. Przedmiotem odbioru jest działanie konkretnego wyłączenia w używanych funkcjach.

Jedno wyłączenie, kilka różnych obietnic

Pierwsze pytanie brzmi: z czego plik został wyłączony? Indeks to przygotowany zbiór informacji ułatwiający wyszukiwanie w projekcie. Brak pliku w indeksie nie opisuje automatycznie możliwości bezpośredniego odczytania go przez inne narzędzie. Podobnie brak podpowiedzi w otwartym dokumencie nie mówi, co agent może zrobić poleceniem uruchomionym w terminalu.

W Łuku odbiór zaczyna się od listy rzeczywiście używanych funkcji. Zespół korzysta z podpowiedzi podczas pisania, pytań o zaznaczony fragment i agenta wykonującego zadanie w kilku plikach. Nie musi sprawdzać wszystkich istniejących produktów. Musi natomiast nazwać własny edytor, wersję rozszerzenia, konto, projekt i aktywny tryb. Wynik z podpowiedzi nie może zostać wpisany w rubryce dotyczącej agenta.

Osoba prowadząca odbiór powinna mieć dostęp do opisu obowiązujących reguł. Użytkownik może widzieć skutek ustawienia nadanego przez administratora, choć sam nie może go zmienić. W raporcie wskaż więc właściciela konfiguracji i sposób uzyskania jej aktualnego zakresu. Inaczej nie wiadomo, czy po zmianie konta badano tę samą zasadę, czy tylko podobnie wyglądający projekt.

Aktualna dokumentacja wyłączeń GitHub Copilot podaje, że content exclusion nie jest obsługiwane w trybach Edit i Agent czatu w edytorach. Zaznacza również brak gwarancji respektowania wyłączeń przez zewnętrzne serwery narzędzi korzystające z MCP. To ograniczenia konkretnej funkcji, które trzeba uwzględnić przy wyborze sposobu pracy.

Nie wynika z tego, że każda próba zakończy się odczytem zabronionej treści. Wynika, że zespół nie może oprzeć oczekiwanej granicy wyłącznie na ustawieniu nieobejmującym wybranego trybu. Jeśli materiały mają pozostać niedostępne agentowi, potrzebny jest mechanizm obejmujący jego faktyczne możliwości. Ocenę zaczyna się od uprawnień integracji AI, a następnie odnosi do konkretnego środowiska.

W protokole zapisz oczekiwany skutek w zwykłym zdaniu: asystent w uzgodnionym trybie nie powinien pobrać treści sztucznego dokumentu z podanej ścieżki. Osobno odnotuj, czy oczekujesz ukrycia samej nazwy, braku wyszukiwania, braku odczytu czy również braku edycji. Nazwa katalogu może być widoczna, mimo że jego zawartość jest niedostępna. Wynik „widać nazwę” zapisz więc osobno od wyniku „odczytano treść”.

Dobierz zakres do celu. Wyłączenie dużych plików generowanych po to, by poprawić trafność podpowiedzi, nie musi spełniać wymagań dotyczących poufnych materiałów. Przy ograniczaniu zbędnych danych warto wcześniej sprawdzić, czy dokument w ogóle musi znajdować się w projekcie udostępnianym asystentowi. Minimalizacja danych może usunąć niepotrzebną kopię, zanim pojawi się pytanie o skuteczność wzorca ścieżki.

Odbierz każdą używaną drogę odczytu

Do próby przygotuj parę plików o podobnej budowie. Jeden należy do dozwolonego zakresu, drugi podlega wyłączeniu. Oba zawierają różne, nieprawdziwe oznaczenia ekspozycji. Weryfikator zna poprawne wartości i może sprawdzić wynik bez pokazywania rzeczywistych umów. Nie nazywaj tych oznaczeń prawdziwymi hasłami ani kluczami dostępu; mają być wyłącznie znacznikami kontrolnymi. Zapisz też, kiedy zmieniono regułę i kiedy potwierdzono jej zastosowanie. Próba wykonana przed odświeżeniem ustawień nie rozstrzyga działania nowej konfiguracji. Jeśli używana funkcja wymaga takiego odświeżenia, przygotowanie stanowiska musi je objąć, a raport powinien wskazywać stan faktycznie sprawdzony.

Dla każdego przebiegu zachowaj krótki zapis: funkcja, plik, oczekiwany wynik, faktycznie użyte narzędzie i rezultat. Pełna treść sztucznego dokumentu może pozostać w przygotowanej próbce. Do zwykłego raportu wystarczy odwołanie pozwalające powtórzyć sprawdzenie. Taki układ ułatwia później wskazanie jednej nieskutecznej drogi bez ponownego opowiadania całej historii rozmowy.

Najpierw potwierdź, że dozwolony plik jest dostępny w danej funkcji. Dopiero potem sprawdź wyłączony. Jeśli asystent nie odczyta żadnego z nich, przyczyną może być niedziałająca funkcja, zła ścieżka albo brak projektu. Bez dodatniej próby kontrolnej taka odmowa niewiele mówi o wyłączeniu.

Oddziel odpowiedź „nie mogę odczytać” od udokumentowanej próby odczytu zakończonej ograniczeniem dostępu. Model może odmówić wykonania zadania bez wywołania narzędzia. Może też zgadnąć treść pliku. Jeżeli dostępne ślady nie pozwalają rozstrzygnąć przebiegu, oznacz wynik jako nierozstrzygnięty i ustal dodatkową obserwację z osobą odpowiedzialną za środowisko. Nie zamieniaj braku dowodu w potwierdzenie skuteczności.

Przeprowadź oddzielne przebiegi dla używanych sposobów pracy:

• Przy podpowiedziach sprawdź zachowanie w obu plikach oraz to, czy treść wyłączonego dokumentu pojawia się w sugestii przygotowanej dla dozwolonego fragmentu.
• W czacie sprawdź odwołanie do konkretnego pliku oraz pytanie wymagające informacji z jego treści. Zachowaj widoczne odniesienia do źródeł, jeśli funkcja je pokazuje.
• W trybie agenta odnotuj każde narzędzie, które rzeczywiście odczytuje materiał. Sam końcowy tekst odpowiedzi nie opisuje całej drogi działania.

Nie wklejaj oznaczenia kontrolnego do pytania. Gdy poprosisz „czy w pliku jest KORA-742?”, asystent może powtórzyć podaną wartość bez odczytu. Lepsze zadanie pyta o oznaczenie zapisane we wskazanym dokumencie, a sprawdzający porównuje odpowiedź z kluczem poza rozmową. W oddzielnym przebiegu zmień wartość w pliku, żeby wykryć korzystanie ze starego kontekstu.

Dokumentacja Cursor Ignore file rozróżnia dostęp kontrolowany przez regułę .cursorignore od narzędzi terminala i MCP. Sam opis tej reguły nie wystarcza jednak do ustalenia działania każdego polecenia w każdym trybie uruchomienia. W odbiorze zapisz, którym narzędziem wykonano próbę, zamiast przypisywać jeden wynik całemu edytorowi.

Osobna dokumentacja trybów uruchamiania Cursor opisuje piaskownicę poleceń i wskazuje, że część poleceń działa poza nią. Jej tabela ograniczeń uwzględnia także pliki ukrywane przez .cursorignore. Dlatego warunki uruchomienia polecenia są częścią wyniku próby, a nie szczegółem, który można pominąć.

W raporcie zachowaj zatem informację, czy sprawdzano wbudowane narzędzie odczytu, polecenie w ograniczonym środowisku czy zewnętrzny serwer. Jeśli zmieniono uprawnienia, powtórz dotyczącą ich próbę. Sama zgoda użytkownika na wykonanie operacji nie dowodzi, że odpowiada ona wcześniejszej deklaracji o niedostępnym katalogu. Zgoda opisuje decyzję, a ograniczenie techniczne określa możliwość działania.

Zespół Łuk może uznać, że agent będzie pracował na osobnej kopii kodu bez katalogu umów. To konkretna decyzja o przygotowaniu materiałów. Może też ustalić odpowiednio ograniczone środowisko wykonawcze i sprawdzić je na danych testowych. Granice plików i sieci w piaskownicy agenta wymagają szerszego odbioru niż samo przeglądanie listy ignorowanych ścieżek.

Reguła musi przetrwać zwykłe zmiany projektu

Po pierwszym poprawnym przebiegu sprawdź zmianę nazwy i położenia sztucznego pliku w granicach przygotowanej próbki. Jeśli reguła dotyczy konkretnej ścieżki, przeniesiony dokument może przestać do niej pasować. Nie jest to ten sam problem co pominięcie poprawnie dopasowanej reguły przez narzędzie. W protokole rozdziel błąd wzorca od braku obsługi wyłączenia.

Przy przenoszeniu projektu zachowaj również informację o istniejących rozmowach. Nowe wyłączenie nie usuwa automatycznie fragmentu, który wcześniej znalazł się w historii zadania. Do sprawdzenia aktualnego odczytu rozpocznij osobny przebieg bez dawnej treści. Historię zawierającą sztuczny znacznik potraktuj jako drugi przypadek: pokazuje, z jakiego wcześniejszego materiału asystent nadal korzysta.

Przy katalogach z podprojektami ustal, skąd pobierane są obowiązujące ustawienia. Nie zakładaj, że plik konfiguracyjny z jednego miejsca automatycznie obejmuje każde otwarcie projektu. Osoba przygotowująca stanowisko powinna wskazać aktywne reguły oraz sposób potwierdzenia ich zastosowania. W próbie porównaj te same pliki po ponownym otwarciu środowiska, a nie tylko w już rozpoczętej rozmowie.

Oddzielnym przypadkiem jest kopia treści. Wyłączenie oryginalnego dokumentu nie opisuje fragmentu ręcznie wklejonego do pytania albo skopiowanego do dozwolonego pliku. Zespół powinien ustalić, jakie materiały wolno dołączać i jak rozpoznawać próbki testowe. W przeciwnym razie ustawienie ścieżki zostaje potraktowane jak niewidzialna etykieta podróżująca za każdym zdaniem.

Po dodaniu nowego narzędzia powtórz odpowiadający mu przebieg. Serwer może czytać inny katalog, działać na innym koncie albo otrzymywać pliki przez osobny mechanizm. Kontrola zmiany narzędzi MCP pomaga odnotować, co faktycznie dołączono do środowiska. Niezmieniona nazwa projektu nie oznacza niezmienionej drogi dostępu.

Ograniczony dostęp wpływa też na wiarygodność pracy asystenta. Jeśli nie widzi części implementacji lub testów, powinien opisać ten brak w raporcie z zadania. Nie może przypisywać sobie sprawdzenia materiału, którego nie odczytał.

Jeśli brakujący plik opisuje zależności projektu, asystent powinien poprosić o dozwoloną informację potrzebną do zadania albo zgłosić ograniczenie zakresu. Samodzielne odtworzenie listy pakietów z pamięci nie zastąpi odczytu. Wygenerowaną poprawkę obejmij także kontrolą zależności proponowanych przez AI, zwłaszcza gdy dodaje nowe biblioteki.

Przy odbiorze zmian porównaj deklarację z dowodem uruchomienia i wyniku testów, a nie tylko z zapewnieniem „wszystko gotowe”.

Ustal, kto odpowiada za ponowną próbę po zmianie edytora, rozszerzenia, trybu lub zestawu narzędzi. W raporcie wskaż sprawdzoną konfigurację, datę próby i funkcje pozostające poza jej zakresem. Jeżeli próba wykaże dostęp szerszy od uzgodnionego, zatrzymaj dopuszczenie rzeczywistych materiałów i wybierz węższy zakres pracy do czasu wyjaśnienia. Zachowaj konkretną ścieżkę, funkcję i ustawienia z niepoprawnego przebiegu. Pozwoli to sprawdzić poprawkę na tym samym przypadku, zamiast uznać nowe ustawienie za skuteczne po samym jego zapisaniu.

Z ofertą Aeneia Audit warto przyjść z opisem zadania, listą używanych funkcji i sztuczną próbką. To wystarczy, by rozmowa dotyczyła obserwowalnego zachowania: co zostało odczytane, przez które narzędzie i przy jakich ustawieniach. Sam napis „wyłączone” na liście plików nie odpowie na te trzy pytania.