https://thedotnetblog.com/pl/tags/middleware/Articles, tutorials and insights from the .NET community.Hugopl@thedotnetblog (The .NET Blog)@thedotnetblogWed, 10 Jun 2026 00:00:00 +0000https://thedotnetblog.com/pl/news/emiliano-montesdeoca/fides-prompt-injection-deterministic-agent-security/Wed, 10 Jun 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/pl/news/emiliano-montesdeoca/fides-prompt-injection-deterministic-agent-security/Nowe możliwości FIDES w Agent Framework są ważne, ponieważ przesuwają obronę przed prompt injection z heurystyk w stronę egzekwowalnej polityki opartej na oznaczonych treściach i kontrolach middleware.<blockquote> <p><em>Ten wpis został przetłumaczony automatycznie. Aby zobaczyć oryginał, <a href="https://thedotnetblog.com/pl/news/emiliano-montesdeoca/fides-prompt-injection-deterministic-agent-security/">kliknij tutaj</a>.</em></p> </blockquote> <p>Obrona przed prompt injection często sprawia wrażenie, jakby stała na chwiejnej ziemi.</p> <p>Dodajesz mocniejszy system prompt. Dodajesz filtr. Ustawiasz kilka allowlist. I liczysz, że następne dziwne wejście nie złamie założeń.</p> <p>Dlatego <strong>FIDES</strong> jest interesujący.</p> <p>Mocna strona tej historii polega na tym, że przesuwa bezpieczeństwo w stronę czegoś bardziej deterministycznego:</p> <ul> <li>oznaczenia treści</li> <li>propagacja oznaczeń przez workflow</li> <li>egzekwowanie przez middleware przed uruchomieniem uprzywilejowanych narzędzi</li> <li>jasne granice polityki wokół tego, na co może wpływać nieufny kontekst</li> </ul> <h2 id="artykuł-źródłowy-mówi-wprost-w-dobrym-sensie">Artykuł źródłowy mówi wprost w dobrym sensie</h2> <p>Otwiera go stwierdzenie, że prompt injection to &ldquo;<strong>zagrożenie numer 1 w OWASP LLM Top 10</strong>&rdquo;.</p> <p>Dobrze.</p> <p>Lubię taką bezpośredniość, bo zbyt wiele zespołów nadal traktuje bezpieczeństwo agentów tak, jakby było problemem przyszłości, a nie aktualnym problemem projektowania runtime.</p> <p>Artykuł idzie dalej z mocnym praktycznym kontrastem: większość obecnych zabezpieczeń jest heurystyczna, podczas gdy FIDES próbuje przesunąć system w stronę polityki i egzekwowania.</p> <p>To jest dokładnie właściwa zmiana.</p> <h2 id="co-czyni-to-bardziej-przekonującym-niż-kolejny-whitepaper-o-bezpieczeństwie">Co czyni to bardziej przekonującym niż kolejny whitepaper o bezpieczeństwie</h2> <p>Wiele tekstów o bezpieczeństwie AI pozostaje abstrakcyjnych.</p> <p>Ten artykuł robi coś lepszego. Przechodzi przez bardzo konkretny przykład: agenta do triage issue GitHub, złośliwy body issue, uprzywilejowany odczyt pliku i próbę wycieku publicznego komentarza.</p> <p>To jest użyteczne, bo osadza całą dyskusję w rzeczywistym workflow.</p> <p>I kiedy zobaczysz ten scenariusz, wartość deterministycznych kontroli staje się dużo łatwiejsza do zrozumienia.</p> <h2 id="kluczowy-pomysł-nie-brzmi-zrób-model-mądrzejszym">Kluczowy pomysł nie brzmi „zrób model mądrzejszym”</h2> <p>Najważniejsze tutaj jest to, że FIDES nie prosi modelu o magicznie lepsze wykrywanie ataków.</p> <p>Zmienia kontrakt runtime.</p> <p>To oznacza:</p> <ul> <li>treści są oznaczane</li> <li>oznaczenia propagują się dalej</li> <li>narzędzia deklarują, co akceptują</li> <li>middleware blokuje niebezpieczne ścieżki przed wykonaniem</li> </ul> <p>To znacznie zdrowsze podejście.</p> <p>Bo gdy agent może wywoływać narzędzia z realnymi konsekwencjami, bezpieczeństwo nie może zależeć tylko od tego, czy model ma dobry dzień.</p> <h2 id="moja-opinia">Moja opinia</h2> <p>To dokładnie taki kierunek w bezpieczeństwie agentów, który chcę widywać częściej.</p> <p>Nie „zaufaj modelowi, że zignoruje złe instrukcje”, tylko „wbuduj policy fence w runtime”.</p> <p>To znacznie zdrowszy model.</p> <p>I jeśli frameworki agentów mają być traktowane poważnie w produkcji, będą potrzebowały więcej takich historii.</p> <p>Oryginalny wpis: <a href="https://devblogs.microsoft.com/agent-framework/fides/">Stop prompt injection from hijacking your agent, new security capabilities now released within Agent Framework</a></p>