Як Benchling ізолювали ШІ-агентів для тисяч клієнтів
Benchling запускає ШІ-згенерований науковий код для понад 250 тенантів щотижня — понад 600 сеансів на день, нуль інцидентів безпеки. Виконання ізольоване в окремому AWS-акаунті без internet gateway і NAT gateway. DNS-запити фільтрує Route 53 Resolver DNS Firewall у три рівні: блок відомих шкідливих доменів, дозвіл лише перелічених S3-ендпоінтів, усе інше — NODATA, що робить DNS-тунелювання неможливим. Замість IAM-ролі на кожного тенанта доступ видається через AWS STS окремо на кожне завдання.
Чому саме DNS — слабке місце
У Benchling ШІ-агенти генерують науковий код, який виконується від імені дослідників у тисячах клієнтських акаунтів. Стандартні обмеження — блокування HTTP, вихідних портів, прямих з'єднань — не закривають один канал: DNS-запити часто лишаються дозволеними, і компанія може не мати повного контролю над тим, як система їх обмежує. Стандартний режим ізоляції Sandbox в AgentCore Code Interpreter обмежує вихідний трафік лише операціями з Amazon S3, але команді безпеки потрібен був контроль на своєму боці: самим визначати, які домени резолвляться і які ендпоінти доступні, і постійно перевіряти це власними тестами. Тому обрали режим VPC, де мережеву політику налаштовує сама компанія.
Три рівні DNS-фаєрвола
В окремому акаунті для виконання ненадійного коду немає internet gateway і NAT gateway — прямого виходу в інтернет фізично не існує. Усі DNS-запити проходять через Amazon Route 53 Resolver DNS Firewall за трьома пріоритетами:
- Пріоритет 10 — блок-лист: одразу відхиляє відомі шкідливі домени незалежно від інших правил; такі спроби логуються як раннє попередження.
- Пріоритет 100 — allow-list: дозволяє резолвити лише явно перелічені S3-ендпоінти. Список навмисно мінімальний — кожен дозволений домен є потенційним каналом витоку.
- Пріоритет 200 — NODATA на все інше: будь-який запит поза allow-list отримує порожню відповідь, тому закодувати вкрадені дані в піддомен і відправити на зовнішній сервер (DNS-тунелінг) неможливо.
Доступ до даних без ролі на кожного клієнта
Окрема IAM-роль на кожного з тисяч тенантів створила б некероване розростання ролей. Замість цього доступ видається одноразово на завдання через AWS STS: продакшн-акаунт визначає, які саме дані потрібні, генерує тимчасові облікові дані й обмежує їх префіксом шляху конкретного тенанта в бакеті. Команда розглядала альтернативу — дати ролі виконання широкий доступ одразу до всіх бакетів тенантів — і відхилила її: скомпрометована сесія тоді відкривала б шлях до даних будь-якого клієнта. Трафік додатково йде лише через VPC-ендпоінти (Gateway — для S3 у тому ж регіоні, Interface — для міжрегіонального доступу) з політикою, що явно перелічує дозволені бакети: запит поза цим списком мережа відхилить ще до S3, навіть якщо код отримав дійсні чужі облікові дані. NACL і маршрутизація обмежують трафік портом 443 і зворотними ефемерними портами.
Перевірка на практиці
Спершу команда протестувала кожен шар окремо на пробній VPC: DNS-тунелінг, прямі з'єднання по IP в обхід DNS, звернення до заборонених бакетів. Потім ті самі сценарії ексфільтрації інтегрували в CI-конвеєр — якщо тест резолвить непередбачений домен чи дістається зовнішнього ендпоінта, реліз блокується. Причина: мережеві налаштування змінюються разом з інфраструктурою, і без постійної перевірки конфігурація, безпечна на момент запуску, може непомітно ослабнути. Замість власного sandbox-рішення з нуля Benchling взяла готовий AgentCore Code Interpreter у режимі VPC, а власні шари безпеки наклала зверху. Із квітня 2026 року система обробляє понад 600 сесій виконання коду на день для понад 250 тенантів щотижня; за словами компанії, за цей час — нуль інцидентів безпеки й нуль витоків між тенантами. У Benchling наголошують: жоден окремий контроль у цій архітектурі сам собою не достатній — результат дає лише комбінація шарів разом з постійною автоматизованою перевіркою.