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

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

Сега AWS публикува подробна архитектура, използваща Amazon Bedrock AgentCore, която запълва тази празнина, като изнася оторизацията извън кода на агента и я премества в самата инфраструктура.

AWS показва как да се предотврати достъпът до данни от AI агенти

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

Ако атакуващ манипулира агента чрез инжектиране на подкана (prompt injection) или експлоатира грешка в този код за филтриране, целият основен набор от данни на агента се оказва компрометиран. Оценяването на стабилен софтуер за сигурност на AI става необходимо, тъй като предприятията внедряват автономни агенти.

Предложеното от AWS решение, съобразено с най-добрата практика AGENTSEC03 в AWS Well-Architected Agentic AI Lens, разглежда агента чисто като оркестратор, който координира извикванията на инструменти и разсъжденията, докато действителните решения за достъп се налагат от услугите, с които агентът комуникира.

Демонстрацията се фокусира върху CRM чат приложение, споделено от служители по продажбите и финансите, като всеки от тях се нуждае от изолиран достъп до клиентски записи в Amazon DynamoDB, документи с етикети на отдели в Amazon Bedrock Knowledge Bases, съхранявани в Amazon S3, и външни CRM данни в Salesforce.

Когато даден потребител се впише чрез Amazon Cognito потребителски пул, Lambda тригър за предварително генериране на токени инжектира твърдение за отдел и метаданни с тагове за сесия на AWS директно в JSON Web Token, преди той да достигне до приложението.

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

За DynamoDB агентът заменя подписания ID токен на потребителя за временни, ограничени до потребителя идентификационни данни чрез AssumeRoleWithWebIdentity, позволявайки на AWS Identity and Access Management да оцени условие LeadingKeys, свързано с тага на отдела на потребителя, така че заявките между различните отдели се отхвърлят на ниво политика, вместо да се филтрират впоследствие. Приемането на тези ограничения за идентичност се съгласува директно с основните принципи за защита на облачни API в мултинаемателски среди.

За Bedrock Knowledge Bases документите се маркират с метаданни за отдела при въвеждането им, а агентът добавя съответстващ филтър за метаданни към всяко извикване за извличане – контрол на ниво приложение, тъй като API за извличане все още не излага филтри като IAM условия.

За Salesforce, AgentCore Identity извършва обмен на токени от името на потребителя съгласно RFC 8693, заменяйки удостоверената идентичност на потребителя с токен, разпознат от Salesforce, без никакви идентификационни данни да докосват агента, позволявайки на собствените правила за споделяне на Salesforce да управляват върнатите данни.

Както е описано подробно в ръководството за архитектура, споделено от AWS Security Blog, налагането на оторизация на инфраструктурно ниво гарантира, че границите на данните остават непокътнати, независимо от манипулации на ниво агент.

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

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

AWS рамкира това като общоприложим модел: обхватът на отделите в примера се картира също толкова лесно към контроли за достъп, базирани на роли, бизнес единици, региони или проекти в други среди.

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