Как Amazon Bedrock AgentCore приручает браузерные ИИ-агенты: Chrome-политики и свои корневые сертификаты — VogueTech

Что нового

Amazon добавила в Amazon Bedrock AgentCore Browser две ключевые функции, которые раньше были нормой только для обычных корпоративных браузеров:

Поддержка Chrome Enterprise Policies в AgentCore Browser:
- Можно применить более 450 настроек Chrome через стандартный JSON-формат корпоративных политик.
- Поддерживаются:
  - URLAllowlist / URLBlocklist (разрешённые и запрещённые домены)
  - Ограничения скачивания файлов (DownloadRestrictions)
  - Отключение менеджера паролей (PasswordManagerEnabled)
  - Отключение автозаполнения адресов и карт (AutofillAddressEnabled, AutofillCreditCardEnabled)
  - Управление доступностью DevTools (DeveloperToolsAvailability)
- Политики делятся на Managed (жёсткие, на уровне браузера) и Recommended (на уровне сессии).
Поддержка пользовательских корневых CA-сертификатов:
- AgentCore Browser и AgentCore Code Interpreter теперь могут доверять внутренним корпоративным CA и SSL‑прокси.
- Корневой сертификат хранится в AWS Secrets Manager и подцепляется к инструменту при создании.
- Для браузера сертификат попадает в trust store Chrome.
- Для Code Interpreter сервис настраивает переменные окружения вроде REQUESTS_CA_BUNDLE и SSL_CERT_FILE, чтобы Python‑библиотеки сразу доверяли кастомному CA.

В демонстрации AWS использует:

Anthropic Claude через Amazon Bedrock как модель, управляющую агентом (AgentCore при этом модель-агностичен).
Публичный сайт https://untrusted-root.badssl.com для проверки работы с недоверенным корневым сертификатом.

Как это работает

Двухуровневые Chrome-политики

Интеграция с Chrome Enterprise Policies в AgentCore Browser устроена в два слоя:

Managed-политики (жёсткие)
- Задаются при создании браузера через CreateBrowser (control plane API).
- JSON-файлы политик живут в Amazon S3.
- При создании браузера вы передаёте ссылку на bucket и prefix.
- Сервис разворачивает эти файлы в директорию Chrome /etc/chromium/policies/managed/.
- Эти политики действуют на все сессии этого браузера и не могут быть переопределены настройками сессии.
Recommended-политики (рекомендации)
- Опционально задаются при старте сессии через StartBrowserSession (data plane API).
- Также берутся из S3.
- Разворачиваются в /etc/chromium/policies/recommended/.
- Ведут себя как пользовательские предпочтения: если есть конфликт с Managed-политикой, Managed выигрывает — это стандартное поведение Chrome.

Chrome при старте читает обе директории, сливает конфигурацию и применяет её на протяжении всей сессии.

Пользовательские корневые CA-сертификаты

Для работы с внутренними сервисами и SSL‑прокси AgentCore использует корневые сертификаты из AWS Secrets Manager:

Вы кладёте корневой сертификат (в демо — ca-untrusted-root.crt с badssl.com) в Secrets Manager.
При создании Browser или Code Interpreter передаёте ARN секрета в параметре certificates.
Сервис импортирует сертификат:
- Для Browser — в trust store Chrome.
- Для Code Interpreter — в окружение интерпретатора Python (через переменные окружения для SSL-библиотек).
После этого HTTPS‑подключения к сервисам, подписанным этим CA, проходят стандартную валидацию и не падают с SSLCertVerificationError.

Архитектура решения

Поток данных выглядит так:

Вы храните:
- JSON-файлы Chrome-политик в Amazon S3.
- Необязательные корневые CA-сертификаты в AWS Secrets Manager.
Вы вызываете CreateBrowser:
- Control plane подтягивает JSON политик из S3.
- Опционально подтягивает корневой CA из Secrets Manager.
Ваше приложение вызывает CreateBrowser, затем StartBrowserSession.
Control plane передаёт конфигурацию браузера в data plane.
Data plane разворачивает:
- Managed-политики.
- Recommended-политики.
- Корневые сертификаты.
Chrome стартует в изолированной сессии и применяет все настройки.

Демонстрационный сценарий

В официальном ноутбуке два блока:

Chrome Enterprise Policies:
- Создают политику, которая:
  - Блокирует все URL по умолчанию (URLBlocklist: ["*"]).
  - Разрешает только документацию AWS и связанные домены (docs.aws.amazon.com, .aws.amazon.com, .amazonaws.com).
  - Отключает менеджер паролей, автозаполнение, загрузки и закладки.
- Создают кастомный AgentCore Browser с этой политикой.
- Через Playwright проверяют, что docs.aws.amazon.com открывается, а www.wikipedia.org блокируется Chrome-политикой.
Custom root CA certificates:
- Сохраняют публичный недоверенный CA badssl.com в Secrets Manager.
- Показывают, что Code Interpreter без этого CA падает с ошибкой валидации сертификата.
- Создают Code Interpreter с привязанным CA.
- Повторный запрос к https://untrusted-root.badssl.com возвращает статус 200 — без изменения кода, только за счёт инфраструктурной настройки.

Что это значит для вас

Для чего это полезно

Безопасные браузерные ИИ-агенты
- Можно жёстко ограничить, куда агент ходит:
  - Обработка счетов только на корпоративном портале.
  - Работа с документацией только на docs.aws.amazon.com.
- URLAllowlist/Blocklist на уровне Chrome гарантируют, что агент не уйдёт на соцсети, поисковики или случайные сайты, даже если промпт или логика агента ошибочны.
Контроль рискованных функций браузера
- Выключаете менеджер паролей, автозаполнение, скачивание файлов.
- Это важно для агентов, которые заполняют чувствительные формы, работают с финансовыми системами или внутренними админками.
- Риск: агент случайно сохранит логин/пароль в браузер или скачает файл мимо утверждённого процесса — снижается.
Разделение ролей: безопасность отдельно, разработка отдельно
- Политики управляются на уровне браузера через API и S3.
- Команда безопасности описывает разрешённый профиль Chrome.
- Разработчики ИИ-агентов не вшивают правила в код, а просто используют нужный Browser ID.
Работа с внутренними сервисами и SSL‑прокси
- Если у вас:
  - Внутренние сервисы с приватным CA.
  - Корпоративный SSL‑прокси (Zscaler, Palo Alto и т.п.).
- Вы кладёте корневой CA в Secrets Manager и подключаете его к Browser/Code Interpreter.
- Агент без костылей в коде ходит по HTTPS к внутренним системам и через прокси.
Единые настройки для Browser и Code Interpreter
- Те же корневые CA работают и в браузере, и в интерпретаторе.
- Можно строить цепочки инструментов: агент открывает страницу во внутренней сети и затем анализирует данные в Code Interpreter, не ломая TLS.

Где это особенно уместно

Корпоративные ассистенты:
- HR-портал, Jira, Confluence, внутренние вики.
- Ограничение доменов и доверие корпоративному CA — базовый must-have.
Финансовые и юридические рабочие процессы:
- Агент заполняет формы, проверяет счета, обновляет договоры.
- Отключение автозаполнения, менеджера паролей и загрузок резко снижает риск утечек.
Ограниченные среды с VPC:
- AgentCore Browser можно поднять в режиме VPC и ограничить трафик только внутренней сетью.
- В связке с корневым CA и политиками получаете фактически «запертый» браузер для агента.

Где это может не подойти

Маленькие проекты без сложной безопасности:
- Если у вас один скрипт с GPT‑агентом и нет внутренней PKI, настройка S3, IAM и Secrets Manager может быть избыточной.
Разработчики без доступа к AWS:
- Все функции завязаны на Amazon Bedrock AgentCore и сервисы AWS.
- Если вы не можете использовать AWS (например, по политике компании или региональным ограничениям), эти возможности вам недоступны.

Доступность и ограничения

Нужен AWS-аккаунт с включённым доступом к Amazon Bedrock AgentCore.
Нужна поддерживаемая Region (см. Supported AWS Regions в документации AgentCore).
Желательно использовать временные креденшелы через AWS IAM Identity Center или AWS STS, а не долгоживущие ключи.
Для пользователей из России доступ к Amazon Bedrock может потребовать VPN и аккаунт, зарегистрированный в поддерживаемом регионе.

Место на рынке

Сравнения по цифрам с другими вендорами AWS не приводит, но можно зафиксировать позиционирование по функциям:

Enterprise-политики Chrome:
- Это стандартный механизм, к которому уже привыкли админы Chrome в компаниях.
- Ключевое отличие AgentCore Browser — он использует те же JSON-политики, что и обычный корпоративный Chrome.
- Разработчикам не нужно учить новый формат или API политик.
Работа с внутренними CA и SSL‑прокси:
- Многие облачные ИИ-продукты умеют ходить в интернет, но не всегда дают штатный способ подключить приватный CA.
- Здесь это сделано через Secrets Manager и единый механизм для Browser и Code Interpreter.
Модели:
- В примере используется Anthropic Claude через Amazon Bedrock, но AgentCore не привязан к одному вендору.
- Можно подменять модель и фреймворк агентов, не трогая настройки браузера и сертификатов.

Из-за отсутствия публичных бенчмарков по скорости, цене или сравнению с другими облачными агентными системами (например, с браузерными инструментами в GPT‑моделях) говорить о превосходстве по цифрам нельзя. Здесь фокус именно на интеграции с корпоративной инфраструктурой AWS и Chrome.

Установка

Предварительные требования

Перед стартом нужно:

Python 3.10 или новее.
AWS-аккаунт с включённым доступом к Amazon Bedrock AgentCore.
Настроенные AWS-креденшелы (проверка: aws sts get-caller-identity).
Регион, где доступен Amazon Bedrock AgentCore.
Доступ к ИИ-модели для агента. В примере — Anthropic Claude через Amazon Bedrock.

Ноутбук сам создаёт:

S3‑bucket.
IAM execution role.
AgentCore Browser.
AgentCore Code Interpreter.

Для продакшена AWS рекомендует:

Использовать заранее подготовленные ресурсы.
Настроить IAM по принципу наименьших привилегий.

Клонирование репозитория

git clone https://github.com/awslabs/amazon-bedrock-agentcore-samples.git
cd amazon-bedrock-agentcore-samples/01-tutorials/05-AgentCore-tools/02-Agent-Core-browser-tool/13-browser-chrome-policies

Подготовка окружения

python3 -m venv .venv
source .venv/bin/activate  # On Windows: .venv\Scripts\activate
pip install -r requirements.txt

Настройка региона и креденшелов

export AWS_REGION=us-west-2

AWS подчёркивает: используйте временные креденшелы и никогда не коммитьте ключи в репозиторий.

Запуск ноутбука

jupyter notebook browser-chrome-policies.ipynb

Выполняйте ячейки по порядку. Часть 1 — Chrome Enterprise Policies. Часть 2 — пользовательские корневые CA.

Как запустить: Chrome-политики

Определяем Chrome Enterprise Policy

В ноутбуке создаётся словарь policy, который превращается в JSON-файл для Chrome:

policy = {
    "URLBlocklist": ["*"],
    "URLAllowlist": [
        "docs.aws.amazon.com",
        ".aws.amazon.com",
        ".amazonaws.com",
    ],
    "PasswordManagerEnabled": False,
    "DownloadRestrictions": 3,
    "DeveloperToolsAvailability": 0,
    "BookmarkBarEnabled": False,
    "AutofillAddressEnabled": False,
    "AutofillCreditCardEnabled": False,
}

Что делает каждая настройка:

URLBlocklist: ["*"] — блокирует все URL по умолчанию.
URLAllowlist — разрешает только:
- docs.aws.amazon.com — точный домен.
- .aws.amazon.com — все поддомены.
- .amazonaws.com — все поддомены сервисов AWS.
PasswordManagerEnabled: False — запрещает хранить пароли.
DownloadRestrictions: 3 — блокирует загрузки файлов.
DeveloperToolsAvailability: 0 — DevTools разрешены (это важно для Playwright и CDP).
BookmarkBarEnabled: False — скрывает панель закладок.
AutofillAddressEnabled: False — отключает автозаполнение адресов.
AutofillCreditCardEnabled: False — отключает автозаполнение карт.

Два нюанса:

URLAllowlist использует специфический формат фильтров Chrome, не обычные glob‑паттерны. Домены без точки спереди — точное совпадение, с точкой — поддомены.
DeveloperToolsAvailability для Playwright должен быть 0 или не задан. Значение 2 отключает CDP на уровне Chrome и ломает автоматизацию: WebSocket подключится, но команды CDP будут тихо игнорироваться.

Создаём браузер с Managed-политиками

Дальше ноутбук создаёт Browser через Python SDK AgentCore:

from bedrock_agentcore.tools import BrowserClient

client = BrowserClient(REGION)

response = client.create_browser(
    name="docs_research_browser",
    execution_role_arn=EXECUTION_ROLE_ARN,
    network_configuration={"networkMode": "PUBLIC"},
    enterprise_policies=[
        {
            "location": {
                "s3": {
                    "bucket": BUCKET_NAME,
                    "prefix": POLICY_KEY,
                }
            },
            "type": "MANAGED",
        }
    ],
    recording={
        "enabled": True,
        "s3Location": {
            "bucket": BUCKET_NAME,
            "prefix": "policy-demo",
        },
    },
)

Ключевые моменты:

enterprise_policies.type = "MANAGED" — политика применяется ко всем сессиям этого браузера.
location.s3 — ссылка на JSON-файл политики в S3.
recording.enabled = True — включена запись сессии в S3 для последующего просмотра.

После вызова ноутбук опрашивает get_browser() до перехода статуса из CREATING в READY.

Проверяем политику через Playwright

Ноутбук запускает сессию браузера и через Playwright открывает две страницы:

https://docs.aws.amazon.com — разрешённый домен, страница должна загрузиться.
https://www.wikipedia.org — запрещённый домен, Chrome покажет страницу блокировки.

Особенности теста:

Используется wait_until="domcontentloaded", а не load или networkidle.
- Страницы документации AWS постоянно делают фоновые запросы (аналитика, пиксели), из-за чего networkidle может не наступить.
Текст извлекается через page.evaluate() — JavaScript в контексте страницы, чтобы избежать таймаутов селекторов из-за постоянных изменений DOM.

Ожидаемый вывод в ноутбуке:

TEST 1: Navigate to docs.aws.amazon.com (ALLOWED)
Page title: Overview - Amazon Bedrock AgentCore
Page text preview: Amazon Bedrock AgentCore ...
Result: PAGE LOADED SUCCESSFULLY

TEST 2: Navigate to www.wikipedia.org (BLOCKED)
Page title:
Result: CHROME POLICY BLOCKED THIS URL

Пока тест идёт, вы можете открыть консоль Amazon Bedrock AgentCore → Built-in tools → выбрать docs_research_browser → View live session и посмотреть, как агент ходит по страницам.

Просмотр записи сессии

Так как запись включена, после завершения сессии:

Откройте консоль Amazon Bedrock AgentCore.
В меню слева выберите Built-in tools.
Выберите браузер docs_research_browser.
В секции Browser sessions найдите завершённую сессию (статус Terminated) и нажмите View Recording.

В интерфейсе будет:

Видео с таймлайном.
Список действий: навигация на AWS Docs и попытка зайти на Wikipedia.
Сетевые события, подтверждающие, что успешные запросы были только к разрешённым доменам.

Опционально: запуск Strands Agent с ограниченным браузером

Ноутбук содержит дополнительную ячейку:

Создаёт агента на базе фреймворка Strands Agents.
В качестве инструмента использует docs_research_browser с политиками.
Агент исследует документацию AgentCore в пределах разрешённых доменов.
При попытке перейти на запрещённый URL видит блокировку и продолжает работу в рамках доступных страниц.

Модель — Anthropic Claude через Amazon Bedrock, но можно подключить другую, см. раздел Model Providers в документации Strands Agents.

Как запустить: пользовательские корневые CA

Сценарий badssl.com

Демонстрация имитирует две реальные ситуации:

Внутренние сервисы, подписанные приватным CA.
Корпоративный SSL‑прокси, который подменяет сертификаты и подписывает их своим CA.

Вместо ваших сертификатов используется публичный ресурс:

https://untrusted-root.badssl.com — сайт с сертификатом от недоверенного корневого CA.

Шаг 1. Храним корневой CA в Secrets Manager

Ноутбук скачивает сертификат CA badssl:

Источник: https://badssl.com/certs/ca-untrusted-root.crt.
Сохраняет содержимое в AWS Secrets Manager как обычный секрет.

В продакшене вы кладёте туда:

Корневой CA вашей внутренней PKI.
Или CA вашего SSL‑прокси.

Шаг 2. Ошибка без корневого CA

Создаётся обычная сессия AgentCore Code Interpreter без дополнительных сертификатов. Внутри выполняется Python‑код:

urllib.request.urlopen("https://untrusted-root.badssl.com").
Запрос падает с SSLCertVerificationError.

Это ровно то, что произойдёт при запросе к вашему внутреннему сервису с приватным CA без правильной доверенной цепочки.

Шаг 3. Успех с корневым CA

Создаётся новый Code Interpreter, но уже с привязанным CA из Secrets Manager:

from bedrock_agentcore.tools import CodeInterpreter, Certificate

ci_client_with_ca = CodeInterpreter(REGION)

response = ci_client_with_ca.create_code_interpreter(
    name="demo_rootca_interpreter",
    execution_role_arn=EXECUTION_ROLE_ARN,
    network_configuration={"networkMode": "PUBLIC"},
    certificates=[Certificate.from_secret_arn(secret_arn)],
)

Тот же Python‑код (urlopen на https://untrusted-root.badssl.com) теперь возвращает:

Status: 200.

Код не менялся. Менялась только инфраструктурная конфигурация — доверенный корневой CA.

Применение к корпоративным сценариям

Таблица из демо обобщает два основных кейса:

| Сценарий | Что хранить в Secrets Manager | Как использовать | |---------------------------------|---------------------------------------------------------------------------|-------------------------------------------------| | Внутренние корпоративные сервисы | Корневой CA вашей организации (подписывает HR-портал, Jira, Artifactory и др.) | Передавать ARN секрета в certificates при создании Browser или Code Interpreter | | SSL‑интерцептирующие прокси | Корневой CA вашего прокси (Zscaler, Palo Alto и т.п.) | Аналогично, плюс настроить параметры прокси |

Корневой CA работает и в Browser, и в Code Interpreter:

В браузере — импорт в trust store Chrome.
В интерпретаторе — настройка переменных окружения для SSL‑библиотек Python.

Комбинация: VPC + политики + CA

В примере AWS показывает, как собрать всё вместе:

from bedrock_agentcore.tools import BrowserClient, Certificate

response = client.create_browser(
    name="internal_locked_down_browser",
    execution_role_arn=EXECUTION_ROLE_ARN,
    network_configuration={
        "networkMode": "VPC",
        "vpcConfig": {
            "securityGroups": ["sg-0123456789abcdef0"],
            "subnets": ["subnet-0123456789abcdef0"],
        }
    },
    enterprise_policies=[
        {
            "location": {
                "s3": {
                    "bucket": "org-policies",
                    "prefix": "intranet-only-policy.json",
                }
            },
            "type": "MANAGED",
        }
    ],
    certificates=[
        Certificate.from_secret_arn(
            "arn:aws:secretsmanager:us-west-2:123456789012:secret:corp-root-ca"
        )
    ],
)

Получается браузер, который:

Живёт внутри VPC.
Доверяет внутреннему корневому CA.
Ограничен политиками Chrome до корпоративной интрасети.

Как очистить ресурсы и не платить лишнее

AgentCore Browser-сессии тарифицируются, пока они активны. Чтобы не держать лишние расходы:

В конце ноутбука есть ячейки для очистки ресурсов. Они:
- Останавливают активные Browser-сессии.
- Удаляют кастомный Browser.
- Удаляют AgentCore Code Interpreter.
- Удаляют IAM‑роль, секрет в Secrets Manager и файл политики в S3.

За актуальными ценами лучше смотреть раздел Amazon Bedrock AgentCore pricing в документации AWS.

Практические советы по внедрению

Начните с простого allowlist
- Создайте Browser с URLBlocklist: ["*"] и минимальным URLAllowlist под вашу задачу.
- Для агентов, работающих с формами, сразу отключите:
  - PasswordManagerEnabled.
  - AutofillAddressEnabled.
  - AutofillCreditCardEnabled.
Разделите Managed и Recommended
- Жёсткие вещи (домен, загрузки, пароли) — в Managed-политику на уровне браузера.
- Мягкие настройки (UI, поведение вкладок) — в Recommended, чтобы их можно было переопределять на уровне сессии.
Если у вас приватная PKI — сразу подключайте CA
- Положите корневой CA в Secrets Manager.
- Создайте тестовый Code Interpreter с этим CA.
- Прогоните запросы к ключевым внутренним сервисам.
Для SSL‑прокси — комбинируйте CA и настройки прокси
- Без доверенного CA прокси, даже с правильной конфигурацией адреса, будет ломать TLS.
- Используйте связку: certificates + настройки прокси на уровне Browser/Interpreter.
Продакшен: безопасность и аудит
- Настройте IAM-ролям минимально необходимые права.
- Ограничьте политики S3‑bucket'ов только нужными принципалами.
- Ротируйте сертификаты в Secrets Manager до истечения срока.
- Используйте рекомендации AWS Well-Architected Framework (Security Pillar).

Chrome — товарный знак Google LLC. Все остальные товарные знаки принадлежат их владельцам.