# Przełamanie śmiertelnej trójki: jak Asana myśli o bezpieczeństwie agentycznej sztucznej inteligencji > Dowiedz się, w jaki sposób Asana odpowiedzialnie buduje sztuczną inteligencję będącą agentem, podczas gdy branża nie ma jeszcze jasności co do podstawowych zasad. Source: https://asana.com/inside-asana/how-asana-thinks-about-agentic-ai-security ## Przełamanie śmiertelnej trójki: jak Asana myśli o bezpieczeństwie agentycznej sztucznej inteligencji _Agentic AI wprowadza klasę zagrożeń bezpieczeństwa, których branża nie rozwiązała. Oto jak postrzegamy to w Asanie i jakie niezmienne zasady bezpieczeństwa stosujemy w odniesieniu do wszystkich naszych funkcji AI._ ### **Problem** Systemy agentic AI nie tylko odpowiadają na pytania. Czytają dokumenty, wykonują działania i koordynują różne narzędzia. Im więcej mogą zrobić, tym większa jest ich powierzchnia ataku. W przeciwieństwie do konwencjonalnego kodu, LLM mają właściwość, która **zasadniczo utrudnia to zadanie: nie potrafią w sposób niezawodny odróżnić instrukcji od danych.** Wszystko, co jest przekazywane do LLM, trafia do tego samego strumienia, więc starannie opracowany fragment danych może przejąć model w ten sam sposób, co prawidłowa instrukcja. To jest podstawa ataku typu prompt injection, który Simon Willison[nazywa](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/) „grzechem pierworodnym” aplikacji opartych na LLM. To nie jest teoria. Badacze zademonstrowali tę klasę ataku przeciwko[Microsoft 365 Copilot](https://simonwillison.net/2025/Jun/11/echoleak/),[serwerowi MCP GitHub](https://simonwillison.net/2025/May/26/github-mcp-exploited/),[Slack AI](https://simonwillison.net/2024/Aug/20/data-exfiltration-from-slack-ai/) i wielu innym. Bruce Schneier[ujął to wprost](https://www.schneier.com/blog/archives/2025/08/we-are-still-unable-to-secure-llms-from-malicious-inputs.html): branża nie ma jeszcze solidnych mechanizmów obronnych przed tą klasą ataków. Jak więc odpowiedzialnie budować agentową sztuczną inteligencję, skoro branża nie rozwiązała podstawowych kwestii? ### **Śmiertelna trójka** Willison rozkłada podstawowe ryzyko na trzy możliwości, które w połączeniu tworzą warunki do wyrządzenia szkody: - **Dostęp do danych wrażliwych.** Agent może odczytać informacje poufne lub prywatne. - **Ekspozycja na niezaufaną treść.** Agent przetwarza dane wejściowe, które mogą zawierać ukryte instrukcje od przeciwnika. - **Możliwość komunikacji zewnętrznej.** Agent może wysyłać informacje poza system. Przydatne doprecyzowanie trzeciego elementu: tak naprawdę chodzi o możliwość **wywoływania skutków ubocznych**, a nie tylko o komunikację wychodzącą. Eksfiltracja danych na serwer atakującego jest klasycznym przykładem, ale złośliwa instrukcja, która po cichu zmienia nazwę każdego projektu w obszarze roboczym lub wysyła wrażliwą treść do niewłaściwego kanału wewnętrznego, to ten sam rodzaj problemu. Używamy terminu „komunikacja zewnętrzna” jako skrótu, ale w rzeczywistości chronimy się przed szerszym zakresem zagrożeń. Każdym z trzech elementów można zarządzać. Nawet dwoma jednocześnie zwykle też. Ale kiedy wszystkie trzy się zbiegną, masz realną ścieżkę ataku. Ważna informacja: **przerwanie dowolnego etapu znacznie zmniejsza ogólne ryzyko.** Nie musimy doskonale rozwiązać problemu wstrzykiwania poleceń. Nikomu się to nie udało. Musimy upewnić się, że wszystkie trzy warunki nie mogą łatwo współistnieć. [Korny Sietsma opiera się na tym](https://martinfowler.com/articles/agentic-ai-security.html), mapując tę trójkę do środków ograniczających ryzyko, takich jak sandboxing, dekompozycja zadań, zasada niezbędnych minimalnych uprawnień i human-in-the-loop. Są to podstawowe elementy składowe. Pytanie brzmi: jak je zoperacjonalizować. ### **Kontekst, punkty kontrolne i kontrola** Organizujemy nasze myślenie wokół trzech filarów, które bezpośrednio odnoszą się do śmiertelnej trójki. Każdy z nich ogranicza jedną z nóg. Asana ma kilka obszarów AI. AI Teammates to agenci uczestniczący z własnym członkostwem i uprawnieniami w obszarze roboczym. Inne funkcje AI działają jako użytkownik, a ograniczeniem jest to, do czego ten użytkownik ma już dostęp. Poniższe niezmienne koncentrują się na przypadku agentycznym, w którym powierzchnia jest największa, i wskażemy, gdzie implementacja różni się w zależności od powierzchni. #### **Kontekst: Zarządzaj tym, co widzi AI** _Trifecta leg: dostęp do wrażliwych danych_ Aby agent AI był przydatny, potrzebuje kontekstu. Wyzwanie polega na tym, aby dać jej wystarczająco dużo, aby była pomocna, ale bez wręczania jej klucza uniwersalnego. Naszą podstawową niezmienną jest zasada najmniejszego uprzywilejowania, której dokładne wyrażenie zależy od powierzchni. W przypadku AI Teammates, którzy mają własne członkostwo oddzielne od każdego indywidualnego użytkownika, granicą jest przecięcie uprawnień członka zespołu i użytkownika. W przypadku funkcji AI, które działają jako użytkownik, granicą jest po prostu dostęp tego użytkownika. W każdym przypadku dostęp sztucznej inteligencji jest regulowany przez tę samą warstwę autoryzacji po stronie serwera, która reguluje każdą inną interakcję w Asanie. Funkcje AI nie otrzymują rozszerzonych uprawnień. Działają one w ramach systemu kontroli dostępu Asany, a nie poza nim. Definiowanie kontekstu to coś więcej niż regulowanie wewnętrznego dostępu do danych w Asanie; obejmuje to również zewnętrzne integracje, z którymi agent może wchodzić w interakcje. Chociaż integracje wymagają obecnie wyraźnej autoryzacji użytkownika, opracowujemy szczegółowe ścieżki kontroli specyficzne dla agenta. Dzięki temu organizacje mogą ograniczyć uprawnienia integracji dla AI Teammates obsługujących dane wejściowe wysokiego ryzyka. Nasza podstawowa niezmienna architektoniczna jest jasna: granica tego, co może _zobaczyć_ AI, musi być dynamiczna i określana przez właścicieli danych, a nie być domyślnym ustawieniem produktu zaprogramowanym na stałe. Nawet jeśli atakujący przemyci złośliwe instrukcje do kontekstu AI, to, co AI faktycznie może _zobaczyć_, jest ograniczone tym samym modelem uprawnień, co wszystko inne. #### **Punkty kontrolne: filtruj to, czego słucha AI** _Etap Trifecta: ekspozycja na niezaufaną treść_ To jest najtrudniejszy etap. Na platformie do zarządzania pracą większość tego, co odczytuje sztuczna inteligencja, to treści generowane przez użytkowników: zadania, komentarze, załączone dokumenty. Część z nich pochodzi spoza organizacji. Nie możesz odmówić ich odczytania. Zamiast tego ustanawiamy **punkty kontrolne**: miejsca, w których odróżniamy zaufaną intencję od arbitralnej treści i w których ludzie mogą interweniować, jeśli coś wygląda podejrzanie. - **Obsługa instrukcji z uwzględnieniem źródła.** Funkcje AI oznaczają treść według zaufania do autora i źródła, dzięki czemu model może nadać większą wagę instrukcjom od autoryzowanych użytkowników niż instrukcjom napotkanym w treści arbitralnej. To ogranicza powierzchnię ataku w przypadku wstrzyknięcia polecenia, ale jej nie zamyka; model nadal odczytuje wszystko w kontekście, a gwarancja bezpieczeństwa jest częściowa, a nie absolutna. Ograniczenia tego podejścia omówimy poniżej. - **Zapisywanie danych w dziennikach i analiza kryminalistyczna.** Każde wywołanie modelu jest rejestrowane wraz z jego danymi wejściowymi, wynikami, podmiotem, kontekstem funkcji i zdarzeniami w dalszej części procesu, w tym z informacją, których obiektów wykresu roboczego dotknęła automatyzacja i które adresy URL pojawiły się w wyniku. Automatycznie ostrzegamy o sygnałach operacyjnych, takich jak wskaźniki błędów i skoki kosztów. W przypadku anomalii istotnych dla bezpieczeństwa te same dzienniki wspierają analizę post-hoc przeprowadzaną przez ludzi. Jak zauważa Willison, nawet wykrywanie oparte na wzorcach, które przechwytuje większość ataków, samodzielnie nie wystarczyłoby; widoczność i możliwość przeprowadzania analiz to trwały fundament, na którym budujemy, a nie mur. - **Projektowanie z udziałem człowieka.** Funkcje AI przedstawiają swoją pracę do przeglądu przez człowieka, zamiast w cichym trybie podejmować nieodwracalne działania. - **Rozkład zadań i akcje z określonym zakresem.** Złożone przepływy pracy są podzielone na mniejsze etapy, a działania dostępne dla funkcji AI są celowo ograniczone, a nie otwarte. Żadne z powyższych rozwiązań nie jest odporne na ataki, jeśli jest stosowane samodzielnie. Razem tworzą one wielopoziomową ochronę. #### **Kontrola: ograniczaj zakres działań AI** _Trzeci etap: możliwość wywoływania skutków ubocznych_ Trzecia noga to miejsce, w którym dochodzi do większości rzeczywistych ataków. Jeśli atakujący przekona sztuczną inteligencję do osadzenia poufnych danych w adresie URL, wysłania ich za pośrednictwem integracji lub zmiany rekordu, na którym polegają inne osoby, atak się powiedzie. W tym przypadku inwestujemy w kilka kategorii kontroli: - **Traktuj wynik LLM jako niezaufany.** Wygenerowana treść nie otrzymuje dodatkowego poziomu zaufania, ponieważ pochodzi z Asana AI. Przechodzi przez te same ścieżki walidacji i renderowania, co każda inna treść generowana przez użytkowników. - **Obowiązkowe zatwierdzenie przez człowieka w przypadku akcji o dużym znaczeniu.** Niektóre kategorie działań zawsze wymagają wyraźnego zatwierdzenia przez człowieka, niezależnie od tego, jak pewna jest AI lub jak rutynowe wydaje się żądanie. W przypadku AI Teammates obejmuje to działania, które zwiększają dostęp (zmiana uprawnień, dodawanie członków) oraz działania, które niszczą dane (usuwanie). Sztuczna inteligencja może je zaproponować, ale nie może ich samodzielnie wykonać. - **Ochrona obsługi linków.** Zewnętrzne adresy URL w treści generowanej przez sztuczną inteligencję są przetwarzane, zanim dotrą do użytkownika. Nowe adresy URL, które nie pojawiły się w danych wejściowych, są poddawane dodatkowej kontroli i wyświetlane w pełnej, niezakrytej formie, a nie jako tekst linku z nową etykietą, więc sztucznej inteligencji nie można użyć jako narzędzia do zamaskowania punktu końcowego eksfiltracji jako przyjaznego komunikatu „kliknij tutaj, aby zobaczyć podsumowanie”. - **Brak ogólnego wychodzącego protokołu HTTP.** Funkcje AI nie mają otwartej podstawowej funkcji „wyślij żądanie do dowolnego adresu URL”. Integracje zewnętrzne przechodzą przez kanały o określonym zakresie z własną autoryzacją. - **Ścieżka audytu działań**. Każdy zapis, mutacja i działanie wychodzące wykonywane przez funkcję AI są rejestrowane wraz z wywołaniem modelu, które je zainicjowało, dzięki czemu osoba prowadząca dochodzenie może zrekonstruować, co zrobiła sztuczna inteligencja, a nie tylko to, o co została poproszona. Celem nie jest uniemożliwienie komunikacji zewnętrznej. Funkcje AI muszą odwoływać się do linków, aktualizować zadania i generować przydatne dane wyjściowe. Celem jest upewnienie się, że nie mogą tego robić _potajemnie_ w sposób niezamierzony przez użytkownika. ### **Wzorzec dla wartości generowanych przez sztuczną inteligencję** W tych ramach wciąż pojawia się ten sam konkretny podproblem: funkcja sztucznej inteligencji generuje coś (identyfikator obiektu, odbiorcę, adres URL), a kolejny kod działa na tej podstawie, często z szerszymi uprawnieniami niż sama sztuczna inteligencja. Halucynacje i wstrzykiwanie poleceń prowadzą do tego samego: wartość generowana przez model jest traktowana jako wiarygodna. Używamy czteroczęściowego wzorca jako listy kontrolnej do przeglądu projektu dla tych wartości: - **Ogranicz** to, co AI może wygenerować, zanim konieczne będzie uruchomienie walidacji. - **Zweryfikuj** każdą wartość wygenerowaną przez sztuczną inteligencję po stronie serwera na tej samej warstwie autoryzacji, co wszystko inne. Model jest traktowany jako niezaufany klient. - **Uzasadnij** wybór, zachowując wystarczający ustrukturyzowany kontekst, aby wyjaśnić_, dlaczego_ sztuczna inteligencja dokonała takiego wyboru. To właśnie umożliwia późniejsze badanie, ocenę i reagowanie na incydenty. - **Eskaluj** z frikcją, rozwiązaniem awaryjnym lub przeglądem przez człowieka, gdy wartość jest obarczona wysokim ryzykiem lub wykracza poza oczekiwany zakres. Wspólny wątek: **zachowanie modelu nie powinno być głównym elementem kontroli bezpieczeństwa.** Lepsze polecenia i „powiedzieliśmy modelowi, żeby tego nie robił” są przydatną, dogłębną obroną, ale trwałe mechanizmy kontrolne znajdują się w systemie wokół modelu. ### **Oparte na zasadach** Te wybory nie są doraźne. Wynikają z[opublikowanych zasad Asany dotyczących AI](https://asana.com/ai-principles). **Ludzie są odpowiedzialni za decyzje**, co jest podstawą struktury opartej na punktach kontrolnych. AI pomaga, ale ludzie są na bieżąco i ponoszą odpowiedzialność. **Zobowiązujemy się do zapewnienia bezpieczeństwa,**co uzasadnia inwestycję w wielopoziomowe mechanizmy kontrolne, nawet jeśli powodują one utrudnienia. Alternatywne rozwiązanie zwiększa ryzyko, ponieważ funkcje AI podejmują się bardziej złożonych zadań. **Promujemy przejrzystość,** dlatego piszemy ten post. Nie rozwiązaliśmy problemu bezpieczeństwa agentycznej sztucznej inteligencji. Jednak otwartość w kwestii tego, w jaki sposób rozumujemy na temat tych zagrożeń i jakie środki ograniczające stosujemy, pomaga szerszej społeczności poczynić postępy w rozwiązywaniu wspólnego wyzwania i zachęca do analizy, która czyni nas lepszymi. ### **Uczciwe limity** Problem **wstrzykiwania poleceń jest nadal zasadniczo nierozwiązany**, a pośrednie wstrzykiwanie poleceń (instrukcje od przeciwnika pojawiają się jako element treści, które AI pobiera podczas pracy, a nie jako treść przekazywana bezpośrednio przez użytkownika) jest wariantem, który najbardziej dotknął branżę w 2026 roku. **Tagowanie uwzględniające źródło** pomaga, ale nie eliminuje całkowicie tego problemu, ponieważ model nadal musi zdecydować o przestrzeganiu tagów. Nasze punkty kontrolne znacznie zmniejszają ryzyko, ale go nie eliminują. Dopóki instrukcje i dane mają wspólne okno kontekstowe, czasami będą się przemycać wrogie dane wejściowe pobrane za pośrednictwem wyszukiwania, publicznych formularzy lub integracji. Traktujemy to jako aktywny, ciągły obszar inwestycji, dokładniej analizując każdą ścieżkę, która umożliwia treściom stworzonym przez podmioty zewnętrzne dotarcie do funkcji agenta. Praca nad [wzorcami projektowymi do zabezpieczania agentów LLM](https://simonwillison.net/2025/Jun/13/prompt-injection-design-patterns/) wskazuje obiecujące kierunki, ale branżowy konsensus nadal dopiero się kształtuje. **Krajobraz zagrożeń szybko się zmienia.** Ciągle pojawiają się nowe wektory, od[niewidocznego wprowadzania poleceń za pomocą obrazów](https://brave.com/blog/unseeable-prompt-injections/) po wieloetapowe łańcuchy eksfiltracji. Projektujemy mechanizmy kontrolne tak, aby były wielowarstwowe i komponowalne, dzięki czemu można dodawać nowe środki łagodzące w miarę pojawiania się nowych zagrożeń. To wyścig zbrojeń, a nie problem, który rozwiązuje się raz. Lista [OWASP Top 10 dla aplikacji LLM](https://genai.owasp.org/llm-top-10/) jest przydatnym punktem odniesienia na bieżąco. Nie postrzegamy tych luk jako powodów do zwalniania tempa. Postrzegamy je jako powody, by działać świadomie. Śmiertelna trójka pokazuje nam, jak wysokie jest ryzyko. Kontekst, punkty kontrolne i mechanizmy kontrolne dają nam strukturę działania. A ponieważ żaden zespół nie rozwiązuje tego problemu samodzielnie, aktywnie inwestujemy wraz z naszymi partnerami badawczymi i klientami, aby wzmocnić te obszary w miarę ewolucji zagrożeń. #### **Materiały referencyjne** - Simon Willison,[„The lethal trifecta for AI agents”,](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/) czerwiec 2025 - Korny Sietsma,[„Agentic AI and Security”,](https://martinfowler.com/articles/agentic-ai-security.html) Martin Fowler, październik 2025 r. - Bruce Schneier,[„We Are Still Unable to Secure LLMs from Malicious Inputs”,](https://www.schneier.com/blog/archives/2025/08/we-are-still-unable-to-secure-llms-from-malicious-inputs.html) sierpień 2025 r. - [Zasady dotyczące Asana AI](https://asana.com/ai-principles) - OWASP,[„Top 10 for LLM Applications”](https://genai.owasp.org/llm-top-10/) - [Mikroframeworki w Konsoli administratora](/pl/inside-asana/microframeworks-admin-console) inżynieria Każde wdrożenie Asany ma konsolę administratora. To właśnie w niej administratorzy IT konfigurują sposób, w jaki ich firma korzysta z Asany, na przykład dostosowując wymagania dot ... - [Rozwój oparty na specyfikacjach: pozytywne aspekty – i czego nauczyliśmy się po trzech miesiącach](/pl/inside-asana/spec-driven-development) inżynieria #### Inżynier oprogramowania – personel Po trzech miesiącach mieliśmy jaśniejszy obraz tego, kiedy dodana struktura była pomocna, a kiedy przeszkadzała.Jeden z naszych inżynierów przygotowywał migrację danych i zdecydow ... - [Przeprowadziliśmy migrację z Enzyme w 2 tygodnie. Powinno to zająć pięć lat.](/pl/inside-asana/migrating-off-enzyme-2-weeks) inżynieria Niedawno użyliśmy AI, aby ukończyć lata pracy inżynieryjnej w czasie około jednego sprintu. Oto, jak to zrobiliśmy i dlaczego zmieniło to nasze myślenie o tym, co jest możliwe.Pro ... - [Jak AI Teammates budują pamięć: przekształcanie pracy w wiedzę wielokrotnego użytku](/pl/inside-asana/ai-teammates-turn-work-into-reusable-information) Sztuczna inteligencja (AI) inżynieria Większość produktów AI traktuje pamięć jako cechę osobistą — zapamiętuje fakty dotyczące jednego użytkownika lub jednej konwersacji. Ale AI, która współpracuje międzyzespołowo, po ... - [Przełamanie śmiertelnej trójki: jak Asana myśli o bezpieczeństwie agentycznej sztucznej inteligencji](/pl/inside-asana/how-asana-thinks-about-agentic-ai-security) inżynieria - [Inżynier ds. bezpieczeństwa personelu](/author/varun-prusty) Agentic AI wprowadza klasę zagrożeń bezpieczeństwa, których branża nie rozwiązała. Oto jak postrzegamy to w Asanie i jakie niezmienne zasady bezpieczeństwa stosujemy w odniesieniu ... - [inżynieria](/inside-asana/engineering-spotlight)