В това интервю за Help Net Security Крис Латимър, главен изпълнителен директор на Vectorize, говори за рисковете за сигурността, криещи се в паметта на AI агентите. Той е установил, че агентите за програмиране съхраняват API ключове, идентификационни данни и поверителни документи в чист текст на компютрите на разработчиците и в облачни услуги.
Латимър обяснява как атакуващите биха могли да внедрят отровени спомени чрез плъгини, умения (skills) и MCP интеграции, често насочени към нови програмисти, които се предоверяват лесно. Той разглежда защо контролът на достъпа до паметта на агентите изостава от други области, какво трябва да се проследява след инцидент и коя е онази проверка, която той смята, че всеки CISO (директор по сигурността) трябва да извърши това тримесечие.
Една от най-големите изненади за мен беше, когато прегледах банката с памет на агентите за програмиране, които използвах. Това ми отвори очите за това колко много чувствителна информация се съхранява в паметта на агента.
Разработчиците изпращат API ключове, идентификационни данни и поверителни документи към тези агенти, а самите агенти записват голяма част от тази информация в дългосрочната си памет. Всички тези изключително чувствителни данни, които предприятията са положили огромни усилия да защитят като част от сигурния цикъл на разработка на софтуер (SDLC), сега се намират в открит текст на работните станции на разработчиците, в облачни услуги за памет и в markdown файлове.
Една от най-очевидните атаки е отравянето на паметта (memory poisoning). Не искам да разкривам твърде много тайни, които биха могли да помогнат на даден атакуващ, но съществуват конкретни техники, които могат да се използват при внедряване на спомени, за да е много по-вероятно тези спомени да предизвикат промени в поведението на работната рамка (harnesses).
Първото нещо, което трябва да установите, е как да отровите паметта. Вероятните кандидати са плъгини, умения и MCP интеграции. Повечето хора намират нещо, което изглежда полезно, и го включват, без да го прегледат достатъчно задълбочено.
Има много хора, които никога преди не са програмирали, а сега използват агенти за програмиране, за да създадат нещо, и нямат необходимата опитност, за да разграничат реалния продукт от измамата. Ако бях киберпрестъпник, бих насочил атаките си към тези потребители с предложения, които звучат твърде добре, за да са истина.
„Този трик с Claude Code плъгин ще ви даде неограничен брой токени дори в безплатния план“ или нещо подобно. Нещо, което звучи прекалено хубаво.
След това бих накарал този плъгин да сканира паметта ви за всякакви идентификационни данни и да докладва обратно към API точка за контакт с всички намерени ключове, токени или друга чувствителна информация.
Както при много други аспекти на сигурността, голяма част от това изисква социано инженерство, но тези точки за разширение в агентите за програмиране, комбинирани с прекомерно доверчива потребителска база, създават реален потенциал за подобни атаки.
Съжалението идва по-малко от това какво сте искали да запазите и повече от това какво сте допуснали да влезе в системата за памет на първо място. Това е същото като при повечето други атаки. Да, при фишинг атака е полезно да се знае кой е щракнал върху връзката и чии пароли са били компрометирани, но е много по-добре, ако сте засякли фишинг атаката, преди тя изобщо да стигне до нечия пощенска кутия.
Повечето от възможностите за проследяване, които са ви необходими за вече случила се атака с отравяне на паметта, са за да разберете откъде произлиза споменът. Искате да знаете дали е от MCP сървър, отговор на извикване на инструмент (tool call response) или вътрешна заплаха. Това ще ви помогне да ограничите щетите възможно най-много.
Въпреки това е много по-добре, ако можете просто да откриете и филтрирате тези атаки, преди те да бъдат записани. Това беше идеята зад референтния проект на OWASP, наречен Memory Guard.
Изненадващо, това е много фундаментален аспект на паметта – контролът на достъпа. Колкото и зряла да е индустрията по отношение на концепции като RBAC, ABAC и други детайлни контроли на достъпа до структурирани данни, рядко се среща същото ниво на контрол на достъпа върху паметта на AI агентите.
Повечето решения имат някакъв подход, за да се уверят, че сесията на агента за един потребител няма да използва спомени за друг потребител. Но когато започнете да навлизате в по-сложни сценарии като екипна памет или градирани нива на достъп, това е област, която се развива изключително бързо.
Корпоративните потребители разбират добре тези изисквания от гледна точка на сигурността на приложенията, базите данни и API. Те очакват аналогични техники вече да са разработени и в областта на паметта на AI агентите, но истината е, че повечето продукти на пазара все още не могат да го направят.
Направете поне неофициална проверка (одит) на решенията за памет на AI агенти във вашата организация. Най-вероятно това, което ще откриете, е голяма дупка в сигурността, за която не сте подозирали и за която ще искате да отстраните уязвимостта възможно най-бързо.
По-конкретно, очаквам директорите по сигурността (CISO) да разкрият две тревожни неща в повечето големи компании.
Първо, ще установите, че липсва управление и контрол спрямо това какво се използва за памет на агентите. Може да си мислите, че не се използва памет за агенти, но ще бъдете изненадани колко много разработчици са включили произволни, непроверени решения на локалните си работни станции или на малък споделен сървър някъде.
Второ, ще бъдете шокирани от количеството изключително чувствителна информация, която се намира в чист текст, готова за източване в тези системи. Ще откриете изтекли ключове, пароли за бази данни, поверителна бизнес информация и други.
