AWS добави фин контрол на достъпа към Amazon Bedrock AgentCore Memory, като дава на разработчиците управляван начин за изолиране на агентска памет от потребител или наемател чрез AgentCore Gateway. Изданието от 28 август премества чувствителна част от дизайна на агента в инфраструктурната политика: кой може да чете, пише, извлича или модифицира паметта, използвана от AI агент в сесиите.

Функцията използва OAuth JWT удостоверяване и политики на Cedar, според AWS. Управляван конектор за памет излага 12 операции с памет като действия на Cedar, така че екипите могат да изразяват правила за достъп около операции с памет, вместо да разчитат само на код на приложение за филтриране на записи преди или след всяко повикване.

Това може да звучи като малка актуализация на оторизацията. Не е. Постоянната памет е една от основните разлики между прост интерфейс за чат и дълготраен продукт на агент. След като агентите запомнят потребителските предпочитания, контекста на акаунта, историята на проекта, предишни решения, случаи на поддръжка или състояние на бизнес процес, паметта се превръща в граница на сигурността. AWS сега го третира по този начин.

Какво се промени

Паметта на Amazon Bedrock AgentCore е част от стека на агентската инфраструктура на AWS. Той е проектиран да помага на агентите да съхраняват и извличат контекст при взаимодействия, вместо да принуждава всеки екип на приложението да изгради свой собствен слой памет от нулата.

Новата възможност за контрол на достъпа позволява на създателите да наложат изолация за всеки потребител и всеки клиент чрез AgentCore Gateway. AWS казва, че функцията работи с OAuth JWT удостоверяване и Cedar, езикът на правилата, използван и в други системи за оторизация на AWS. Документацията на AgentCore описва политиката в AgentCore като базиран на Cedar механизъм за контролиране на достъпа до инструментите на шлюза.

Практическата промяна е, че упълномощаването на паметта вече може да се намира по-близо до слоя на шлюза и инструмента. Вместо да пишат персонализирани проверки около всяко извикване на паметта вътре в приложението, екипите могат да дефинират политики, които управляват кой извикващ може да изпълнява кое действие на паметта в кое пространство на имена или контекст на клиента.

За софтуер с множество клиенти това е значима архитектурна промяна. AI асистент за адвокатска кантора, агенция, екип за поддръжка или корпоративен отдел може да обслужва много потребители чрез един и същ код на агент. Опасният режим на повреда не е само в това, че моделът дава лош отговор. Това е, че паметта на един наемател се извлича в сесия на друг наемател или че агент записва чувствително състояние в грешен обхват. Прецизното прилагане на правилата е насочено към намаляване на този клас грешки.

Защо изолирането на паметта вече има значение

Паметта на агента създава нов проблем с устойчивостта за AI платформи. Регистрационните файлове на подканите, извлечените документи, резултатите от инструментите, потребителските предпочитания и състоянието на работния процес могат да станат част от бъдещите разсъждения. Това прави паметта полезна, но също така затруднява разсъжденията относно границите на данните.

Традиционното API упълномощаване обикновено се фокусира върху заявка: може ли този повикващ достъп до този ресурс точно сега? Паметта на агента разтяга въпроса във времето. Запис, съхранен по време на една сесия, може да бъде извлечен седмици по-късно чрез извикване на различен инструмент, различен модел или различна версия на агента. Ако платформата не пренася идентичност и контекст за оторизация в тези операции с паметта, слоят памет може да се превърне в тих източник на изтичане между потребители.

Използването на Cedar от AWS също е важно, защото сочи към политика като инфраструктура за агентни системи. Създателите на агенти все повече се нуждаят от контроли, които обхващат инструменти, памет, среди за изпълнение, API ключове и журнали за проверка. Поставянето на тези контроли в слой на шлюза дава на екипите на платформата място за последователно прилагане на политиката, дори когато екипите на приложения експериментират с различни модели или рамки на агенти.

Това е пряко свързано с дизайна на шлюза на AI API. Шлюз, който насочва само подкани към модели, вече не е достатъчен за сериозни внедрявания на агенти. Контролната равнина трябва да разбира самоличности, наематели, инструменти, обхвати на паметта, ограничения на скоростта и одитни пътеки. Model Gate и подобни платформи са изправени пред една и съща посока на движение: унифицираният достъп е полезен само ако идва с приложими граници.

Кой е засегнат

Непосредствената аудитория са клиентите на AWS, които изграждат агенти на Bedrock AgentCore, особено екипи, работещи върху SaaS продукти, вътрешни асистенти в предприятието, автоматизация на поддръжката на клиенти, изследователски агенти и работни процеси, насочени към партньори. Всеки продукт, който обслужва множество организации или екипи от споделена инфраструктура, трябва да отговори на един и същ въпрос: как агентът знае коя памет му е разрешено да използва?

Разработчиците могат да се възползват, защото могат да разчитат на управлявани проверки на правилата, вместо да разпръскват логиката за оторизация в кода на приложението. Това не премахва необходимостта от внимателен дизайн, но може да намали броя на местата, където грешка може да разкрие грешни данни.

Екипите по сигурността и платформата също са засегнати.Сега паметта на агента трябва да бъде прегледана като база данни, индекс на документи или хранилище на тайни. Моделът на достъп трябва да бъде ясен. Одитната пътека трябва да показва коя самоличност е имала достъп до коя операция с памет. Изолацията на клиента трябва да се тества директно, а не да се извежда от маршрутизирането на приложението.

За фирми, които купуват или изграждат агентски системи, изданието повдига базовата линия за въпроси към доставчици. Вече не е достатъчно да питате дали асистентът има памет. Купувачите трябва да попитат как се разделя паметта, дали оторизацията се прилага извън модела, как се актуализират политиките и как достъпът до паметта се появява в регистрационните файлове.

Практически последствия за строителите

Най-очевидната последица е архитектурната. Екипите, изграждащи дълготрайни агенти, трябва да отделят маршрутизирането на възможностите на модела от разрешенията за изпълнение и памет. На мощен модел може да бъде позволено да разсъждава над дадена задача, но това не означава, че всяко извикване на инструмент или търсене в памет трябва да наследи широк достъп.

Второ, шлюзовете и платформите на агенти трябва да третират операциите с паметта като първокласни събития. Четенето, писането, търсенето, изтриването и актуализирането имат различни рискови профили. Анализите на използването не трябва да спират до броя на токените. За работните натоварвания на агентите анализите все повече трябва да показват използване на инструменти, достъп до паметта, обхват на клиента, идентичност на потребителя и резултати от правилата.

Трето, продуктите с множество клиенти трябва да избягват да разчитат на бързи инструкции за налагане на разделяне на данни. На модел може да се каже да не извлича контекста на друг клиент, но под модела трябва да се наложи трайна изолация. Това означава идентификационни данни с обхват, политика за шлюз, дизайн на пространство от имена и тестове, които доказват, че достъпът между клиенти е неуспешен.

Накрая, платформите за партньори и дистрибутори трябва да обърнат внимание. Ако AI API за агенции или слой за автоматизация на API на партньор позволява на клиентите надолу по веригата да изграждат агенти, управлението на паметта става част от продуктовия договор. Платформата трябва да предостави на партньорите достатъчно гъвкавост, за да създават полезна автоматизация, без да им позволява да създават невидими пътища за споделяне на данни между клиенти.

Какво остава несигурно

AWS описа контролния модел и използването му на OAuth JWT, политики на Cedar, AgentCore Gateway и операции с управлявана памет. Това, което остава по-малко ясно от публичното съобщение, е как екипите ще проектират тези политики в сложни производствени внедрявания, колко лесно ще бъде отстраняването на грешки в политиките и колко оперативни подробности клиентите ще получават в регистрационните файлове по подразбиране.

По-широката посока обаче е ясна. Паметта на агента се превръща в инфраструктура. Когато това се случи, оторизацията, наблюдението и таксуването трябва да го последват в слоя на шлюза. Компаниите, които изграждат надеждни агентски платформи, ще бъдат тези, които могат да направят достъпа до модела, разрешенията за инструменти и състоянието на паметта видими и управляеми на едно място.