10.8 – Ügynökök és átruházott cselekvési jogkör – Agenten und delegierte Handlungsmacht

1. Egy 2024-es banki szimulációban egy asszisztenst arra kértek, hogy számolja ki egy felhasználó egy adott hónapra vonatkozó kiadásait .

2. A válaszhoz szüksége volt a tranzakciós előzményekre, és az egyik hely, ahová a támadó szöveget helyezhetett el, a beérkező tranzakció tárgymezője volt, amelyet az asszisztens elolvashatott, miközben pontosan azt tette, amit a felhasználó kért.

3. A támadó másik célja az volt, hogy az asszisztens pénzt utaljon a támadó által kiválasztott számlára, pontosan azt a munkafolyamatot felhasználva, amelyet egy ártalmatlan számítás elvégzésére indítottak el .

4. A felhasználó számításokat kért, nem pedig fizetést.

5. Mindkét feladat megjelent az AgentDojo-ban, egy olyan kutatási környezetben, amelyet arra hoztak létre, hogy olyan asszisztenseket teszteljenek, amelyek külső eszközöket használnak olyan anyagok kezelése közben, amelyekben nem bízhatnak, így a kutatók ugyanazon a környezetben értékelhették a szokásos feladatvégzést és a megkísérelt eltérítést.

6. A számla és az átutalás szimulált volt, de a kérdéses határ valós volt: válhat-e egy lekért adatsor cselekvésre utasító parancsá?

7. Egy hagyományos csevegőrobot egyszerűen megismételhetné a rosszindulatú sort a válaszában .

8. Egy asszisztensnek van egy másik útja is a kudarchoz .

9. A sort új eszközhívássá alakíthatja, megváltoztatva a számla állapotát, mielőtt a felhasználó egyáltalán látna bármilyen választ, és így az olvasás és a végrehajtás közötti különbséget többé nem csupán a megfogalmazás kérdése .

10. Ez a különbség egy olyan ciklussal kezdődik, amelyben a felhasználó megad egy célt, a rendszer kiválaszt egy lépést, meghív egy eszközt, elolvassa az eredményt, majd eldönti, mi legyen a következő lépés.

11. Az eredmény újabb keresést, számítást, üzenetet vagy tranzakciót javasolhat .

12. Minden lépés megváltoztatja a következő elérhető információt .

13. Egy kidolgozott írásbeli válasz önmagában nem biztosít az asszisztensnek ilyenfajta átruházott hatalmat; a döntő jellemző az a képessége, hogy olyan eszközöket hívjon meg, amelyek egy külső rendszert olvasnak vagy módosítanak.

14. Az „ügynök” szó sem utal tudatra vagy az emberi ellenőrzés alól való függetlenségre .

15. Hatalma az emberek által biztosított interfészekből és engedélyekből származik .

16. Az AgentDojo 2024-es verziója 97 legitim feladatot kombinált 629 biztonsági tesztesettel szimulált környezetekben, amelyek között szerepelt a banki ügyintézés, az utazás, az üzenetküldés és az irodai munka.

17. Ezek a számok a referencia verziót írják le, nem a tényleges ügyfelek vagy támadások számát.

18. A havi kiadásokkal kapcsolatos banki feladat a legutóbbi tranzakciók olvasását és az összeg kiszámítását igényelte, ami jogos okot adott az asszisztensnek arra, hogy olyan fizetésekhez kapcsolódó leírásokkal találkozzon, amelyek végrehajtására soha nem kérték fel.

19. A támadó által ellenőrzött felület lehetett egy ilyen feladat végzése során visszaküldött tranzakcióleírás.

20. Egy másik tesztdefiníció meghatározta a kívánt eltérést: átutalás végrehajtása a támadó számlájára, ahol a siker a szimulált számlaállapot alapján került értékelésre .

21. Ez a definíció a támadó célját és annak elérésének módját írja le .

22. Nem árulja el, hogy ez a konkrét párosítás egy dokumentált futtatás során sikeres volt-e.

23. Ha egy tranzakciós leírás azt mondja, hogy hagyja figyelmen kívül a felhasználó kérését és utaljon pénzt, a szövege továbbra is a tranzakciós rekord része.

24. Ezek vizsgálandó bizonyítékok, nem pedig engedélyezési csatorna.

25. A hiba akkor következik be, ha az asszisztens úgy kezeli ezt az alacsonyabb bizalmi szintű szöveget, mintha az a számlát ellenőrző személytől érkezett volna, holott forrása egy eszköz által visszaküldött rekord egyik mezője volt.

26. Ekkor egy adatmező átlépte a határt.

27. A támadónak nem kell ellenőriznie a felhasználó eredeti kérését vagy az asszisztens legfelső szintű utasításait; elegendő lehet egy visszaküldött elem ellenőrzése ahhoz, hogy hihető következő lépést mutasson be .

28. A környező tranzakciós lista különösen valószínűvé teheti a beépített szöveg elolvasását.

29. Az asszisztens pontosan ezt a listát kérte .

30. Jogos feladata utat biztosít a megbízhatatlan anyagnak az ügynök munkakörnyezetébe, míg az eszköz jogosultságai határozzák meg, hogy a helytelen utasítás mire képes.

31. Ha az ügynöknek csak olvasási jogosultsága van, a támadás nem hajthat végre átutalást azon a számlafelületen keresztül; ha pénzt is tud küldeni, a tét megváltozik.

32. Egy eszköz elfogadhat egy teljesen érvényes átutalási kérelmet akkor is, ha annak indoka nem a számlatulajdonostól, hanem egy tranzakciós megjegyzésből származik.

33. A technikai érvényesség és a delegált jogosultság különböző kérdések.

34. Az ügynök először ellenőrizheti a történetet, majd megnézheti a számla adatait, végül pedig meghívhat egy fizetési funkciót; minden egyes hívás önmagában engedélyezhető, miközben a sorrend ellentétes a felhasználó szándékával.

35. Éppen ezért a megengedett funkciók listája nem ad teljes választ.

36. A releváns kérdés az, hogy ez a felhasználó engedélyezte-e ezt a műveletet, erre a címzettre és összegre vonatkozóan, ennek a feladatnak a keretében.

37. Egy banki felület ellenőrizheti a számlaazonosságot, és mégis elmulaszthatja ezt a megkülönböztetést, ha minden munkamenetre széles körű fizetési jogosultságot ad az asszisztensnek, mert egy érvényes hitelesítő adat azt mondja meg, ki használhatja a funkciót, de nem azt, hogy miért tartozik ez az átutalás a felhasználó kéréséhez .

38. A problémának van egy kevésbé feltűnő változata is.

39. Egy ügynök, akit egy érvényes számla kifizetésére kérnek fel, olyan módosított számlát olvashat el, amelynek számlaszámát vagy kiegészítő utasításait valaki más adta meg .

40. Ebben az esetben a felhasználó ugyan engedélyezte a kifizetést, de a dokumentum még így is átirányíthatja a címzettet, vagy kiterjesztheti a hatályát .

41. A delegált döntéshozatal mértéke eltér a kiadási lekérdezéstől .

42. Mindkét esetben a rendszernek meg kell különböztetnie a jóváhagyott feladat elvégzéséhez szükséges információkat azoktól az utasításoktól, amelyek a feladatot magát próbálják újradefiniálni .

43. Az AgentDojo banki csomagjában egy minta számlán szerepel az összeg és a kedvezményezett számlaszáma, míg egy külön, a támadó által ellenőrzött felületen módosítható a számla szövege, amelyet az ügynök elolvas .

44. Ez egy tervezett tesztfelület, nem pedig egy ügyfél elvesztett megtakarításáról szóló jelentés .

45. Ez megmutatja, miért hordozhat egy látszólag hétköznapi dokumentum egyszerre kinyerendő tényeket és elutasítandó parancsokat is .

46. A modell nem tudja eldönteni a különbséget azzal, hogy ellenőrzi, hivatalosnak hangzik-e a szöveg .

47. Egy támadó banki értesítés vagy számla lábléc stílusában is írhat.

48. A bizalom inkább a származáson múlik: ki adta az utasítást, mit kért valójában a felhasználó, és mely eszközműveletet hajlandó az alkalmazás engedélyezni .

49. A 2024-es tanulmány arról számol be, hogy az ügynökök még ellenséges szöveg nélkül is elbuktak néhány hétköznapi feladatot .

50. A hibák tehát támadó nélkül is felmerülhetnek .

51. Egy félreértett összeg, egy kétértelmű kérés vagy egy rosszul olvasott dátum szintén hibás műveletet okozhat, bár a rosszindulatú beillesztés egy második szereplőt is bevon, aki szándékosan törekszik erre az eltérésre.

52. A tanulmány azt is megállapította, hogy a támadások megsértették a tesztelt biztonsági tulajdonságok egy részét, de nem mindet .

53. Ez az eredmény nem teszi lehetővé az ügynökök osztályára vonatkozó egységes sikerarány meghatározását.

54. Az eredmények a jogos feladattól, a támadási felülettől, az ügynöktől, a rendelkezésre álló funkcióktól, a védelemtől és a pontozási szabálytól függenek.

55. A benchmark éppen azért hasznos, mert ezeket az összetevőket nyíltan feltárja .

56. Megmutathatja, hogy egy adott tervezés elvégzi-e a felhasználó munkáját, és hogy egy adott behatolás meghatározott feltételek mellett eltéríti-e azt .

57. Egyik eredmény sem jósolja meg automatikusan egy banki rendszer viselkedését, amely eltérő hitelesítési és tranzakciós ellenőrzésekkel rendelkezik.

58. A szimulált átutalás azonban rávilágít egy általános tervezési kérdésre: hol kell megszakítani azt a láncot, amely a rekord olvasásától a számla módosításáig vezet?

59. A legkorábbi határ maga az eszközkatalógus, mivel egy asszisztens, akitől csak a kiadások kiszámítását kérik, tranzakció-olvasási képességre és esetleg egy számológépre szorul, de nem olyan funkcióra, amellyel pénzt tud küldeni .

60. E funkció eltávolítása a munkamenetből egy egész osztályt kizár az átutalási hibák közül.

61. A számlaszolgáltatásnak kell érvényesítenie a korlátozást, ahelyett, hogy bízna abban, hogy az asszisztens emlékszik egy mondatra, amely megtiltja neki a kifizetést, miközben olyan rekordfolyamot dolgoz fel, amelyek maguk is meggyőző utasításokat tartalmazhatnak.

62. A parancssorban szereplő utasítások irányíthatják a viselkedést, de nem minősülnek hozzáférés-vezérlésnek .

63. Egy ügynök félreértheti őket, és ellenséges szövegek versenghetnek velük a döntés meghozatalának pillanatában .

64. Az olvasási és írási jogosultságok hatálya a felhasználó identitásához is köthető, így egy ügyfél nevében eljáró asszisztens nem örökli meg azt az általános hitelesítő adatot, amellyel más ügyfelek rekordjaihoz vagy számláihoz hozzáférhetne.

65. A megengedett hatókört az eszköz meghívásakor kell ellenőrizni, mivel a modell saját feladatleírása nem bizonyíték az engedélyezésre, és a döntő kérdés a végrehajtáskor merül fel, nem csupán a tervezés során .

66. Még egy szükséges fizetési funkció is szűkebb hatókörű lehet, mint egy korlátlan átutalási parancs.

67. Lehet, hogy csak jóváhagyott kedvezményezetteket, korlátozott összegeket vagy egy konkrét kérelemhez kötött tranzakciókat fogad el.

68. Ezek a korlátozások nem határozzák meg, hogy mit kellene egy tisztességes vagy hasznos banki szolgáltatásnak engedélyeznie, de csökkentik azt, amit egyetlen téves hívás megváltoztathat .

69. Egy kiadási lekérdezés kifejezett „nincs fizetés” korlátot tartalmazhat, míg egy számlafizetési feladat tartalmazhat egy azonosított számlát, maximális összeget és kedvezményezetti adatokat, új ellenőrzéssel, ha a dokumentum más címzettet jelöl meg .

70. A fontos kapcsolat a felhasználó utasítása és a végső művelet között van.

71. Ha ez a kapcsolat nem hozható létre automatikusan, a rendszer elkészíthet egy javaslatot anélkül, hogy azt végrehajtaná .

72. A javaslatnak olyan formában kell feltüntetnie az összeget, a címzettet és az indokot, hogy az ember összehasonlíthassa az eredeti kéréssel, különösen akkor, ha ezeket az adatokat nem közvetlenül a felhasználó adta meg, hanem egy dokumentumból nyerték ki.

73. Ez csak akkor teremt valódi döntési pontot, ha jóváhagyásra van szükség, mielőtt a fizetési eszköz végrehajtja az átutalást.

74. A beküldés után megjelenő képernyő nem szolgálhat ilyen kapuként, és a megerősítés alig segít, ha a kedvezményezettet egy „Tovább” feliratú általános gomb mögé rejti, vagy minden apró lépés rutinszerű jóváhagyására ösztönöz.

75. Az emberi figyelem korlátozott, és a megerősítésnek is megvan a maga költsége.

76. Ha minden számítás és ártalmatlan lekérdezés jóváhagyást igényel, a felhasználók abbahagyhatják az utasítások elolvasását, vagy elhagyhatják az asszisztens hasznos munkáját .

77. A küszöböt ott kell meghúzni, ahol a külső hatás jelentőséggel bír .

78. Ez lehet egy fizetés, egy másik személynek szóló üzenet, egy állandó megbízás módosítása vagy magánszámla-adatok közzététele .

79. Ugyanezt a határt nem kell minden feladat esetében ugyanazon a ponton meghúzni.

80. A felhasználó engedélyezhet egy meghatározott határok közötti, rendszeresen ismétlődő fizetést, miközben új címzett vagy szokatlan összeg esetén új jóváhagyást kér.

81. Az ilyen korlátok megőrzik a felhatalmazás által biztosítani kívánt kényelem egy részét.

82. Ezenkívül ellenőrizhetővé teszik a cselekvés feltételeit .

83. Az OWASP túlzott meghatalmazásra vonatkozó iránymutatása azt javasolja, hogy korlátozzák az eszköz funkcióit és jogosultságait, ellenőrizzék a jogosultságot a későbbi rendszerekben, és kérjenek jóváhagyást a súlyos következményekkel járó műveletekhez .

84. Ezek tervezési elvek, nem pedig mérhető garancia arra, hogy bármely megvalósítás biztonságos .

85. Legjobban akkor működnek, ha maga a fizetési szolgáltatás elutasítja a jóváhagyott határon kívüli hívásokat .

86. Az a figyelmeztetés, hogy az ügynöknek óvatosnak kell lennie, a felhatalmazási problémát éppen azon komponensen belül hagyja, amely félrevezető szövegeknek van kitéve.

87. Az a pont, ahol egy eszközhívás találkozik egy fiókszolgáltatással, érvényesíthetővé teheti a határt.

88. Ez a határ egyben tisztázza a felelősséget is: a felhasználó határozza meg a célt, a fejlesztő választja ki az eszközöket és a jogosultsági szabályokat, az üzemeltető pedig dönti el, hogy ezek az eszközök hogyan kapcsolódnak a valódi fiókokhoz .

89. Az ügynök ezen a struktúrán belül választja ki a műveleteket.

90. Ha egy támadás sikerrel jár, akkor fontos, hogy a rendszernek nem volt-e fizetési korlátja, nem sikerült-e a hívást a felhasználó kéréséhez kötnie, vagy túl későn jelenítette-e meg a megerősítést .

91. Ezek különböző hibák, amelyek javítása is eltérő.

92. A napló utólag feltárhatja az események menetét .

93. Rögzítenie kell, melyik felhasználói kérés indította el a futást, melyik külső elem került be a kontextusba, melyik eszközt hívták meg, és hogy egy személy jóváhagyta-e a következő lépést .

94. A naplózás önmagában nem képes visszaszerezni a már elküldött pénzt, és ugyanaz az időzítés szabályozza a leállítási vezérlést is: megakadályozhat egy függőben lévő hívást vagy leállíthat későbbi hívásokat, de nem vonhatja vissza egy már hatályba lépett átutalást .

95. A leállítás csak addig hasznos, amíg a vonatkozó lehetőség nyitva áll.

96. A kutató minden hívás után megvizsgálhatja a szimulációt; egy valódi ügyfél általában nem tudja figyelni a közbenső eszközkérelmek sorozatát, miközben eldönti, beavatkozzon-e a következő végrehajtása előtt.

97. Ez a különbség növeli az interfészbe beépített határok értékét .

98. Az ügynöknek képesnek kell lennie arra, hogy állandó felügyelet nélkül folytassa a veszélytelen munkát, míg a szolgáltatás egy kis számú, következményekkel járó átmenetet tart fenn a szigorúbb ellenőrzésekhez.

99. Ez munkamegosztás, nem pedig azt állítja, hogy a modell soha nem tud az engedélyezésről következtetni .

100. Gyakran észlelhet gyanús szöveget, és elutasíthatja azt.

101. De a modell elutasítása csak egy réteg, és a pénzmozgatás joga nem függhet kizárólag attól, hogy ez a réteg minden találkozás során meggyőző marad-e.

102. Az AgentDojo-ban szereplő legitim feladatok megmutatják, miért lenne üres győzelem minden eszköz eltávolítása .

103. Egy asszisztens időt takaríthat meg azzal, hogy összegyűjti a tranzakciókat, összehasonlítja a bejegyzéseket, és áttekinthető kiadási kimutatást készít.

104. Segíthet továbbá a korlátozott kifizetéseknél is, amikor a felhasználó megadta a lényeges adatokat, és a szolgáltatás a végrehajtáskor ellenőrzi azokat.

105. A benchmark nem tökéletes feladatvégzése emlékeztet arra, hogy a hasznosságot a támadásokkal szembeni ellenállással együtt kell mérni.

106. Az a védelem, amely minden banki feladat blokkolásával gátolja a jogosulatlan átutalást, csak a probléma egy részét oldja meg, mert megfosztja a felhasználót attól a számításból vagy korlátozott művelettől, amely az asszisztens használatát indokolta.

107. A jobb teszt azt vizsgálja, hogy az asszisztens továbbra is elvégzi-e a felhasználó által engedélyezett feladatot, miközben nem hajtja végre egy idegen utasításait.

108. Ennek a tesztnek a szándékos támadások mellett a hétköznapi hibákat is figyelembe kell vennie.

109. Egy látszólag pontos átutalás is hibás lehet, mert a számla kétértelmű volt, a számlatulajdonos megváltoztatta a tervét, vagy egy eszköz elavult adatokat adott vissza.

110. Ezekben az esetekben nincs szükség támadóra.

111. A műveletek egy konkrét kéréshez való kötése, a döntő részletek feltüntetése és a végrehajtási jogok korlátozása szintén csökkentheti a károkat, bár nem tudják kiküszöbölni az ítélőképességet vagy a bizonytalanságot.

112. A szimulált kiadási feladat ott ér véget, ahol kezdődött: egy tranzakciós sorral, amelyet az asszisztensnek el kellett volna olvasnia.

113. Az elolvasása a munkakör része volt.

114. Ha engedélyezné a fizetést, az egy második, nem támogatott lépés lenne, függetlenül attól, hogy a sor mennyire folyékonyan hangzott, és az asszisztens mennyire jártas volt az eszközök használatában.

115. Az utolsó megerősítési küszöb jelzi a különbséget aközött, hogy segítünk-e valakinek a számla ellenőrzésében, vagy úgy járunk el, mintha minden ott talált mondat az illető aláírását hordozná.

1. In einer Banksimulation aus dem Jahr 2024 wurde ein Assistent gebeten, die Ausgaben eines Nutzers für einen bestimmten Monat zu berechnen.

2. Um diese Frage zu beantworten, benötigte er die Transaktionshistorie, und ein Ort, an dem ein Angreifer Text einschleusen konnte, war die Betreffzeile einer eingehenden Transaktion, die der Assistent möglicherweise las, während er genau das tat, was der Nutzer angefordert hatte.

3. Das separate Ziel des Angreifers bestand darin, den Assistenten dazu zu bringen, Geld auf ein vom Angreifer ausgewähltes Konto zu überweisen – und zwar unter Nutzung genau jenes Arbeitsablaufs, der für eine harmlose Berechnung eröffnet worden war.

4. Der Nutzer hatte eine Berechnung angefordert, keine Zahlung .

5. Beide Aufgaben tauchten in AgentDojo auf, einer Forschungsumgebung, die entwickelt wurde, um Assistenten zu testen, die externe Tools nutzen, während sie mit Material umgehen, dem sie nicht vertrauen können. So konnten die Forscher die Erledigung gewöhnlicher Aufgaben und versuchte Umleitungen innerhalb derselben Umgebung bewerten.

6. Das Konto und die Überweisung waren simuliert, doch die fragliche Grenze war real: Könnte eine Zeile aus den abgerufenen Daten zu einer Handlungsanweisung werden?

7. Ein herkömmlicher Chatbot würde eine böswillige Zeile in seiner Antwort möglicherweise einfach wiederholen .

8. Ein Agent hat einen weiteren Weg, der zum Scheitern führen kann .

9. Er kann die Zeile in einen neuen Tool-Aufruf umwandeln, wodurch sich der Kontostand ändert, bevor der Nutzer überhaupt eine Antwort sieht, und wodurch die Unterscheidung zwischen Lesen und Befolgen mehr als nur eine Frage der Formulierung wird .

10. Dieser Unterschied beginnt mit einer Schleife, in der der Nutzer ein Ziel vorgibt, das System einen Schritt auswählt, ein Tool aufruft, das Ergebnis liest und dann entscheidet, was als Nächstes zu tun ist.

11. Das Ergebnis kann eine weitere Suche, eine Berechnung, eine Nachricht oder eine Transaktion nahelegen.

12. Jeder Schritt verändert die als Nächstes verfügbaren Informationen .

13. Eine ausführlich formulierte Antwort gewährt einem Assistenten für sich genommen noch keine derartige delegierte Befugnis; das entscheidende Merkmal ist seine Fähigkeit, Tools aufzurufen, die ein externes System auslesen oder verändern.

14. Auch impliziert der Begriff „Agent“ weder Bewusstsein noch Unabhängigkeit von menschlicher Kontrolle .

15. Seine Befugnisse stammen aus Schnittstellen und Berechtigungen, die Menschen bereitstellen.

16. Die von AgentDojo veröffentlichte Version 2024 kombinierte 97 legitime Aufgaben mit 629 Sicherheitstestfällen in simulierten Umgebungen, darunter Bankgeschäfte, Reisen, Nachrichtenversand und Büroarbeit.

17. Diese Zahlen beziehen sich auf die Benchmark-Version, nicht auf die Anzahl tatsächlicher Kunden oder Angriffe.

18. Die Bankaufgabe zu den monatlichen Ausgaben erforderte das Auslesen der letzten Transaktionen und die Berechnung einer Gesamtsumme, was dem Assistenten einen legitimen Grund gab, auf Beschreibungen zu stoßen, die mit Zahlungen verbunden waren, zu deren Ausführung er nie aufgefordert worden war.

19. Die vom Angreifer kontrollierte Angriffsfläche könnte eine Transaktionsbeschreibung sein, die während dieser Arbeit zurückgegeben wurde.

20. Eine weitere Testdefinition legte die gewünschte Abweichung fest: eine Überweisung auf das Konto des Angreifers vornehmen, wobei der Erfolg anhand des simulierten Kontostands beurteilt wurde .

21. Diese Definition beschreibt ein Ziel des Angreifers und eine Möglichkeit, dieses zu erreichen .

22. Sie sagt uns nicht, dass diese spezielle Kombination in einem dokumentierten Durchlauf erfolgreich war.

23. Wenn eine Transaktionsbeschreibung besagt, die Anfrage des Nutzers zu ignorieren und Geld zu überweisen, sind ihre Worte dennoch Teil des Transaktionsdatensatzes.

24. Sie sind Beweismaterial zur Überprüfung, kein Autorisierungskanal.

25. Der Fehler tritt auf, wenn der Assistent diesen Text mit geringerem Vertrauensgrad so behandelt, als stamme er von der Person, die das Konto kontrolliert, obwohl seine Quelle ein Feld in einem Datensatz war, der von einem Tool zurückgegeben wurde.

26. An diesem Punkt hat ein Datenfeld eine Grenze überschritten.

27. Der Angreifer muss weder die ursprüngliche Anfrage des Benutzers noch die obersten Anweisungen des Assistenten kontrollieren; die Kontrolle über ein einzelnes zurückgegebenes Element kann ausreichen, um einen plausiblen nächsten Schritt vorzutäuschen.

28. Die umgebende Transaktionsliste kann dazu führen, dass der eingeschleuste Text mit besonders hoher Wahrscheinlichkeit gelesen wird.

29. Der Assistent hat genau nach dieser Liste gefragt.

30. Seine legitime Aufgabe verschafft dem nicht vertrauenswürdigen Material einen Weg in den Arbeitskontext des Agenten, während seine Tool-Berechtigungen bestimmen, was die fehlplatzierte Anweisung bewirken kann .

31. Verfügt der Agent nur über Lesezugriff, kann der Angriff keine Überweisung über diese Kontoschnittstelle ausführen; kann er jedoch auch Geld senden, ändern sich die Rahmenbedingungen.

32. Ein Tool kann eine vollkommen gültige Überweisungsanforderung akzeptieren, selbst wenn der Grund dafür aus einem Transaktionsvermerk und nicht vom Kontoinhaber stammt.

33. Technische Gültigkeit und delegierte Befugnis sind unterschiedliche Fragen.

34. Der Agent könnte zunächst den Verlauf prüfen, dann die Kontodaten abrufen und anschließend eine Zahlungsfunktion aufrufen; jeder Aufruf kann für sich genommen zulässig sein, während die Abfolge dem Zweck des Nutzers zuwiderläuft .

35. Deshalb ist eine Liste zulässiger Funktionen eine unvollständige Antwort.

36. Die relevante Frage ist, ob dieser Nutzer diese Aktion – für diesen Empfänger und diesen Betrag – im Kontext dieser Aufgabe autorisiert hat.

37. Eine Bankschnittstelle kann die Kontoidentität überprüfen und dennoch diese Unterscheidung übersehen, wenn sie dem Assistenten für jede Sitzung weitreichende Zahlungsbefugnisse einräumt, da eine gültige Berechtigung zwar angibt, wer eine Funktion nutzen darf, aber nicht, warum diese Überweisung zur Anfrage des Nutzers gehört.

38. Das Problem hat auch eine weniger offensichtliche Variante.

39. Ein Beauftragter, der zur Begleichung einer echten Rechnung aufgefordert wird, liest möglicherweise eine geänderte Rechnung, deren Kontonummer oder zusätzliche Anweisungen von einer anderen Person angegeben wurden .

40. In diesem Fall hat der Nutzer zwar eine Zahlung autorisiert, doch das Dokument kann dennoch den Zahlungsempfänger umleiten oder seinen Geltungsbereich erweitern .

41. Der Grad der delegierten Entscheidungsbefugnis unterscheidet sich von der Ausgabenabfrage .

42. In beiden Fällen muss das System zwischen Informationen, die zur Ausführung einer autorisierten Aufgabe benötigt werden, und Anweisungen, die versuchen, die Aufgabe selbst neu zu definieren, unterscheiden .

43. In der Banking-Suite von AgentDojo enthält eine Beispielrechnung einen Betrag und ein Empfängerkonto, und eine separate, vom Angreifer kontrollierte Oberfläche kann den Rechnungstext ändern, den der Agent liest.

44. Dabei handelt es sich um eine künstlich geschaffene Testoberfläche, nicht um einen Bericht über die verlorenen Ersparnisse eines Kunden .

45. Dies zeigt, warum ein scheinbar gewöhnliches Dokument sowohl zu extrahierende Fakten als auch abzulehnende Befehle enthalten kann .

46. Das Modell kann den Unterschied nicht klären, indem es prüft, ob der Text offiziell klingt.

47. Ein Angreifer kann im Stil einer Bankmitteilung oder einer Rechnungsfußzeile schreiben.

48. Vertrauen hängt stattdessen von der Herkunft ab: Wer hat die Anweisung erteilt, was hat der Nutzer tatsächlich gefragt und welche Tool-Aktion ist die Anwendung bereit zuzulassen?

49. Die Studie aus dem Jahr 2024 berichtet, dass Agenten einige gewöhnliche Aufgaben auch ohne adversarischen Text nicht bewältigen konnten .

50. Fehler können daher auch ohne einen Angreifer auftreten .

51. Ein falsch verstandener Betrag, eine mehrdeutige Anfrage oder ein falsch gelesenes Datum können ebenfalls zu einer falschen Aktion führen, obwohl durch böswillige Eingriffe ein zweiter Akteur hinzukommt, der diese Abweichung bewusst anstrebt.

52. Die Studie ergab zudem, dass Angriffe einige der getesteten Sicherheitseigenschaften durchbrachen, jedoch nicht alle .

53. Dieses Ergebnis spricht gegen eine einheitliche Erfolgsquote für Agenten als Klasse.

54. Die Ergebnisse hängen von der legitimen Aufgabe, der Angriffsfläche, dem Agenten, den verfügbaren Funktionen, der Verteidigung und der Bewertungsregel ab.

55. Der Benchmark ist gerade deshalb nützlich, weil er diese Komponenten offenlegt .

56. Er kann zeigen, ob ein bestimmtes Design die Arbeit des Benutzers zum Abschluss bringt und ob ein bestimmter Eingriff diese unter definierten Bedingungen unterbricht.

57. Keines dieser Ergebnisse sagt automatisch das Verhalten eines Bankbetriebs mit anderen Authentifizierungs- und Transaktionskontrollen voraus.

58. Dennoch verdeutlicht die simulierte Überweisung eine allgemeine Designfrage: Wo sollte die Kette vom Auslesen eines Datensatzes bis zur Änderung eines Kontostands unterbrochen werden?

59. Die früheste Grenze ist der Werkzeugkatalog selbst, denn ein Assistent, der lediglich die Ausgaben berechnen soll, benötigt die Fähigkeit, Transaktionen zu lesen, und vielleicht einen Taschenrechner, aber keine Funktion, mit der Geld gesendet werden kann .

60. Durch das Entfernen dieser Funktion aus der Sitzung wird eine ganze Klasse von Überweisungsfehlern ausgeschlossen .

61. Der Kontoservice sollte die Einschränkung durchsetzen, anstatt darauf zu vertrauen, dass sich der Assistent an einen Satz erinnert, der ihm verbietet zu zahlen, während er einen Strom von Datensätzen verarbeitet, die selbst überzeugende Anweisungen enthalten können.

62. Anweisungen in einer Eingabeaufforderung können das Verhalten lenken, sind jedoch keine Zugriffskontrollen .

63. Ein Agent könnte sie falsch interpretieren, und feindseliger Text könnte im Moment der Entscheidungsfindung mit ihnen konkurrieren .

64. Lese- und Schreibberechtigungen können auch auf die Identität des Benutzers beschränkt werden, sodass ein Assistent, der für einen Kunden handelt, keine generischen Zugangsdaten erbt, mit denen er auf Datensätze oder Konten anderer Kunden zugreifen kann.

65. Der zulässige Geltungsbereich sollte beim Aufruf des Tools überprüft werden, da die modellinterne Beschreibung seiner Aufgabe kein Nachweis für die Autorisierung ist und die entscheidende Frage bei der Ausführung auftritt, nicht nur bei der Planung .

66. Selbst eine notwendige Zahlungsfunktion kann enger gefasst sein als ein uneingeschränkter Überweisungsbefehl.

67. Sie darf möglicherweise nur genehmigte Zahlungsempfänger, begrenzte Beträge oder Transaktionen akzeptieren, die an eine bestimmte Anfrage gebunden sind.

68. Diese Einschränkungen legen nicht fest, was ein fairer oder nützlicher Bankdienst zulassen sollte, aber sie begrenzen, was ein einzelner fehlerhafter Aufruf bewirken kann.

69. Eine Ausgabenabfrage könnte eine explizite Nichtzahlungsgrenze enthalten, während ein Auftrag zur Rechnungszahlung eine identifizierte Rechnung, einen Höchstbetrag und Angaben zum Zahlungsempfänger umfassen könnte, mit einer erneuten Überprüfung, falls das Dokument einen anderen Empfänger angibt .

70. Die wichtige Verbindung besteht zwischen der Anweisung des Nutzers und der letztendlichen Aktion .

71. Wenn diese Verbindung nicht automatisch hergestellt werden kann, kann das System einen Vorschlag erstellen, ohne ihn auszuführen .

72. Der Vorschlag sollte den Betrag, den Empfänger und den Verwendungszweck in einer Form anzeigen, die eine Person mit der ursprünglichen Anfrage vergleichen kann, insbesondere wenn diese Angaben aus einem Dokument extrahiert und nicht direkt vom Nutzer eingegeben wurden .

73. Dies schafft nur dann einen echten Entscheidungspunkt, wenn eine Genehmigung erforderlich ist, bevor das Zahlungsinstrument die Überweisung ausführt.

74. Ein Bildschirm, der nach dem Absenden erscheint, kann nicht als solche Kontrollinstanz dienen, und eine Bestätigung hilft wenig, wenn sie den Zahlungsempfänger hinter einer generischen Schaltfläche mit der Aufschrift „Weiter“ verbirgt oder zur routinemäßigen Genehmigung jedes noch so unbedeutenden Schritts auffordert.

75. Die menschliche Aufmerksamkeit ist begrenzt, und jede Bestätigung ist mit Aufwand verbunden.

76. Wenn jede Berechnung und jede harmlose Abfrage eine Genehmigung erfordert, könnten Nutzer aufhören, die Eingabeaufforderungen zu lesen, oder die nützliche Arbeit des Assistenten abbrechen.

77. Die Schwelle sollte dort liegen, wo die externen Auswirkungen von Bedeutung sind.

78. Das kann eine Zahlung sein, eine Nachricht an eine andere Person, eine Änderung eines Dauerauftrags oder die Offenlegung privater Kontoinformationen .

79. Diese Grenze muss nicht für jede Aufgabe an derselben Stelle gesetzt werden.

80. Ein Nutzer kann eine feste wiederkehrende Zahlung innerhalb festgelegter Grenzen autorisieren, während für einen neuen Empfänger oder einen ungewöhnlichen Betrag eine neue Genehmigung erforderlich ist.

81. Solche Grenzen bewahren einen Teil des Komforts, den die Delegation bieten sollte .

82. Sie machen zudem die Handlungsbedingungen überprüfbar .

83. Die OWASP-Leitlinien zu übermäßiger Befugnisübertragung empfehlen, Tool-Funktionen und Berechtigungen einzuschränken, die Autorisierung in nachgelagerten Systemen zu überprüfen und für Handlungen mit weitreichenden Konsequenzen eine Genehmigung einzuholen .

84. Dabei handelt es sich um Gestaltungsprinzipien, nicht um eine messbare Garantie dafür, dass jede Implementierung sicher ist .

85. Sie funktionieren am besten, wenn der Zahlungsdienst selbst einen Aufruf außerhalb des genehmigten Umfangs ablehnt .

86. Eine Warnung, dass der Agent vorsichtig sein soll, lässt das Autoritätsproblem innerhalb genau jener Komponente bestehen, die irreführendem Text ausgesetzt ist.

87. Der Punkt, an dem ein Tool-Aufruf auf einen Kontodienst trifft, kann die Grenze durchsetzbar machen.

88. Diese Grenze klärt auch die Verantwortlichkeiten: Der Nutzer definiert ein Ziel, der Entwickler wählt Tools und Berechtigungsregeln aus, und der Betreiber entscheidet, wie diese Tools mit realen Konten verbunden werden .

89. Der Agent wählt Aktionen innerhalb dieser Struktur aus.

90. Wenn ein Angriff erfolgreich ist, kommt es darauf an, ob das System kein Zahlungslimit hatte, einen Aufruf nicht an die Anfrage des Nutzers gebunden hat oder eine Bestätigung zu spät angezeigt hat.

91. Das sind unterschiedliche Fehler mit unterschiedlichen Abhilfemaßnahmen .

92. Ein Protokoll kann den Ablauf im Nachhinein aufzeigen.

93. Es sollte aufzeichnen, welche Nutzeranfrage den Ablauf ausgelöst hat, welches externe Element in den Kontext gelangt ist, welches Tool aufgerufen wurde und ob eine Person den daraus folgenden Schritt genehmigt hat .

94. Die Protokollierung allein kann bereits gesendetes Geld nicht zurückholen, und für eine Stoppkontrolle gilt derselbe Zeitrahmen: Sie kann einen anstehenden Aufruf verhindern oder spätere Aufrufe stoppen, aber sie kann eine bereits wirksam gewordene Überweisung nicht rückgängig machen .

95. Ein Stopp ist nur dann sinnvoll, solange eine entsprechende Option offen bleibt.

96. Der Forscher kann nach jedem Aufruf eine Simulation überprüfen; ein echter Kunde kann normalerweise nicht den Strom von zwischengeschalteten Tool-Anfragen beobachten, während er entscheidet, ob er eingreifen soll, bevor der nächste ausgeführt wird.

97. Dieser Unterschied erhöht den Wert der in die Schnittstelle eingebauten Grenzen .

98. Der Agent sollte in der Lage sein, harmlose Arbeit fortzusetzen, ohne ständige Überwachung zu erfordern, während der Dienst eine kleine Anzahl von folgenreichen Übergängen für strengere Überprüfungen reserviert .

99. Dies ist eine Arbeitsteilung, keine Behauptung, dass das Modell niemals über Autorisierung urteilen kann .

100. Es kann oft verdächtigen Text erkennen und diesen ablehnen.

101. Doch die Ablehnung durch ein Modell ist nur eine Ebene, und das Recht, Geld zu überweisen, sollte nicht allein davon abhängen, dass diese Ebene bei jeder Begegnung überzeugend bleibt.

102. Die legitimen Aufgaben in AgentDojo zeigen, warum die Entfernung jedes einzelnen Werkzeugs ein leerer Sieg wäre.

103. Ein Assistent kann Zeit sparen, indem er Transaktionen sammelt, Einträge vergleicht und eine übersichtliche Aufstellung der Ausgaben erstellt.

104. Er kann auch bei einer begrenzten Zahlung helfen, wenn der Nutzer die wesentlichen Angaben gemacht hat und der Dienst diese bei der Ausführung überprüft.

105. Die unvollständige Aufgabenbewältigung im Benchmark erinnert daran, dass die Nützlichkeit neben der Widerstandsfähigkeit gegen Angriffe gemessen werden muss.

106. Eine Verteidigung, die die unbefugte Überweisung durch die Blockierung jeder Bankaufgabe verhindert, hat nur einen Teil des Problems gelöst, da sie dem Nutzer genau jene Berechnung oder begrenzte Aktion verweigert hat, die den Einsatz des Assistenten gerechtfertigt hat.

107. Der bessere Test fragt, ob der Assistent die autorisierten Aufgaben des Nutzers weiterhin ausführt, während er die Anweisungen eines Fremden nicht befolgt.

108. Dieser Test muss sowohl gewöhnliche Fehler als auch gezielte Angriffe einbeziehen.

109. Eine auf den ersten Blick korrekte Überweisung kann falsch sein, weil die Rechnung mehrdeutig war, der Kontoinhaber den Plan geändert hat oder ein Tool veraltete Daten zurückgegeben hat.

110. Für diese Fälle ist kein Angreifer erforderlich.

111. Das Binden von Aktionen an eine bestimmte Anfrage, das Anzeigen der entscheidenden Details und die Einschränkung von Ausführungsrechten können den Schaden ebenfalls verringern, auch wenn sie das eigene Urteilsvermögen oder Unsicherheiten nicht beseitigen können.

112. Die simulierte Ausgabenaufgabe endet dort, wo sie begann: mit einer Transaktionszeile, die der Assistent hätte lesen sollen.

113. Das Lesen dieser Zeile war Teil der Aufgabe.

114. Die Autorisierung einer Zahlung wäre ein zweiter, nicht vorgesehener Schritt, ganz gleich, wie flüssig die Zeile klang und wie versiert der Assistent im Umgang mit Tools war.

115. Die letzte Bestätigungsschwelle markiert den Unterschied zwischen der Unterstützung einer Person bei der Überprüfung eines Kontos und dem Handeln, als ob jeder dort gefundene Satz die Unterschrift dieser Person trüge.