# AWS дозволив AgentCore-агентам читати чужі бази знань > AWS розширив Bedrock AgentCore підтримкою cross-account knowledge bases: агенти читають бази знань з інших AWS-акаунтів без копіювання даних. - Опубліковано: 26 серпня 2026 р. (2026-08-26T16:44:55.951286+00:00) - Розділ: Агенти - На основі публікації: [AWS ML](https://aws.amazon.com/blogs/machine-learning/connect-amazon-bedrock-agentcore-to-cross-account-knowledge-bases/) - Видання: AiiN (https://aiin.news) - URL: https://aiin.news/article?slug=aws-%D0%B4%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D0%B8%D0%B2-agentcore-%D0%B0%D0%B3%D0%B5%D0%BD%D1%82%D0%B0%D0%BC-%D1%87%D0%B8%D1%82%D0%B0%D1%82%D0%B8-%D1%87%D1%83%D0%B6%D1%96-%D0%B1%D0%B0%D0%B7%D0%B8-%D0%B7%D0%BD%D0%B0%D0%BD%D1%8C --- Amazon Web Services додав до Bedrock AgentCore підтримку cross-account knowledge bases — можливість, яка дозволяє AI-агентам, розгорнутим в одному AWS-акаунті, напряму звертатися до баз знань Bedrock Knowledge Bases, що зберігаються в іншому акаунті, без копіювання чи синхронізації даних. Для великих організацій це закриває болючу дірку. У типовій enterprise-структурі AWS дані рідко живуть там само, де агенти: команда data governance тримає векторні індекси й документи в одному акаунті з жорсткими політиками доступу, а продуктова команда розгортає AI-агентів в іншому — з власним білінгом, IAM-межами й циклом релізів. До цього оновлення підключити агента до чужої бази знань означало або дублювати дані (з ризиком розсинхрону й подвійними витратами на зберігання), або зводити обидва компоненти в один акаунт, жертвуючи ізоляцією. За нашою оцінкою, це рутинне, але показове доповнення: AWS підганяє AgentCore під те, як реально влаштовані великі AWS-організації — з десятками акаунтів під landing zone, а не під один спільний простір. ## Що саме дозволяє нова функція? Агент, розгорнутий на AgentCore в акаунті A, тепер може напряму запитувати Bedrock Knowledge Base, що фізично існує в акаунті B. [За даними AWS ML](https://aws.amazon.com/blogs/machine-learning/connect-amazon-bedrock-agentcore-to-cross-account-knowledge-bases/), агент отримує доступ до чужої бази знань напряму, без окремого ETL-процесу, який копіював би документи чи ембединги між акаунтами. Практично це означає, що дані знань залишаються під контролем власника — того акаунту, де діють його політики шифрування, аудиту й retention, — а споживає їх агент з іншого акаунту, підпорядкований своїм власним правилам розгортання. ## Чому проблема з акаунтами взагалі виникла? AWS роками рекомендує multi-account стратегію через AWS Organizations: окремі акаунти під продакшн, стейджинг, дата-платформу, кожну бізнес-юніт чи навіть кожного клієнта в агентських/SaaS-моделях. Це стандарт для контролю blast radius і білінгу. Проблема в тому, що агентні фреймворки зазвичай проєктували в припущенні «один акаунт — усі ресурси поруч». Коли AWS почав просувати AgentCore як керовану платформу для продакшн-агентів, розбіжність між multi-account реальністю клієнтів і single-account дизайном платформи стала вузьким місцем — особливо для компаній, де дані регулюються окремо від compute. ## Кому це реально полегшить роботу? - Enterprise-командам із централізованою data-платформою, де knowledge bases належать окремій дата-команді, а агентів будують продуктові команди у власних акаунтах. - Регульованим галузям (фінанси, охорона здоров'я), де аудит і доступ до чутливих документів мають лишатися в одному, ізольованому акаунті. - Агенціям і консалтингам, що керують AgentCore-агентами для кількох клієнтів, кожен з яких тримає власні дані у власному акаунті. Для стартапів і команд з одним AWS-акаунтом ця функція практично непомітна — вона вирішує проблему, якої в них немає. ## Що з цим робити AI-білдерам зараз? Якщо ваша компанія вже розділяє AWS-акаунти за принципом найменших привілеїв, варто переглянути архітектуру AgentCore-агентів: можливо, більше не потрібно тримати копію бази знань поруч із compute. Це прибирає окремий пайплайн синхронізації і точку, де дані можуть розійтися. Водночас варто заздалегідь перевірити межі доступу при підключенні до чужого акаунту — розширення поверхні довіри між акаунтами саме по собі створює новий вектор, який варто окремо аудитувати, а не просто увімкнути й забути. Подібна логіка спільного контексту між агентами вже з'являється й на рівні окремих моделей — ми розбирали, як [Claude отримав єдину пам'ять для агентів](https://aiin.news/article?slug=claude-отримав-єдину-пам-ять-що-змінюється-для-агентів), що піднімає схожі питання довіри між сесіями. ## Висновок AiiN Наша теза: cross-account knowledge bases — це не проривна фіча, а визнання того, що продакшн-агенти живуть у корпоративній інфраструктурі, а не в демо-акаунті одного розробника. AWS системно прибирає бар'єри між «де є дані» і «де працює агент» — подібні кроки для інших сервісів AWS з часом ставали стандартом інтеграції. Компанії, що будують enterprise-агентів на AgentCore, отримують менше причин копіювати дані і більше причин довіряти AWS у ролі клею між акаунтами. ## Що таке Bedrock AgentCore? Bedrock AgentCore — керована платформа AWS для розгортання й запуску AI-агентів у продакшні, яка бере на себе інфраструктурні задачі: пам'ять, ідентифікацію, спостережуваність та інтеграцію з інструментами й базами знань. ## Чи потрібно платити окремо за cross-account доступ? Джерело AWS ML не деталізує окрему тарифікацію саме за цю функцію — орієнтуйтеся на стандартну модель оплати Bedrock Knowledge Bases і AgentCore та перевіряйте актуальний прайсинг перед впровадженням. ## Чи працює це з будь-якою базою знань Bedrock? За описом AWS ML, функція розрахована на бази знань, створені через Bedrock Knowledge Bases в іншому AWS-акаунті, а не на довільні зовнішні джерела даних поза AWS. --- Теги: AWS, Bedrock, AgentCore, AIагенти, enterprise Джерело: AiiN — https://aiin.news/article?slug=aws-%D0%B4%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D0%B8%D0%B2-agentcore-%D0%B0%D0%B3%D0%B5%D0%BD%D1%82%D0%B0%D0%BC-%D1%87%D0%B8%D1%82%D0%B0%D1%82%D0%B8-%D1%87%D1%83%D0%B6%D1%96-%D0%B1%D0%B0%D0%B7%D0%B8-%D0%B7%D0%BD%D0%B0%D0%BD%D1%8C. Цитуючи, посилайтесь на канонічний URL.