Контроль браузерного доступа AI-агентов с Chrome enterprise policies в Amazon Bedrock AgentCore

AI-агенты с неограниченным доступом к вебу создают серьезные риски безопасности. Без Chrome enterprise policies, которые управляют поведением браузера, агент может перейти на несанкционированные домены, сохранить учетные данные в менеджере паролей браузера или загрузить файлы вне утвержденных рабочих процессов. Для организаций, у которых внутренние сервисы используют частный центр сертификации (CA), существует дополнительное препятствие: каждое HTTPS-подключение к таким сервисам завершается ошибкой проверки сертификата.

Amazon Bedrock AgentCore Browser теперь поддерживает Chrome enterprise policies и пользовательские корневые сертификаты root CA, чтобы дать организациям точный контроль над поведением браузера агента и его подключениями. С Chrome policies можно настраивать более 450 параметров браузера, включая фильтрацию URL, ограничения загрузок и управление менеджером паролей, через знакомую JSON-конфигурацию Chrome enterprise. Поддержка пользовательских root CA позволяет агентам подключаться к внутренним сервисам и работать через корпоративные SSL-intercepting прокси, доверяя сертификатам вашей организации. Полный список доступных настроек см. в списке политик Chrome Enterprise.

В этом материале вы настроите Chrome enterprise policies, чтобы ограничить браузерного агента одним конкретным сайтом, увидите применение политики через запись сеанса и продемонстрируете пользовательские root CA на публичном тестовом сайте. В результате получится рабочее решение, которое исследует документацию Amazon Bedrock AgentCore при действующих корпоративных ограничениях браузера.

Зачем применять политики браузера для AI-агентов

Chrome enterprise policies решают три организационные задачи при использовании AI-браузерных агентов.

Во-первых, можно ограничить область работы агента разрешенными доменами. Allowlist и denylist для URL ограничивают, куда агент может переходить. Агенту, который обрабатывает счета на конкретном портале, не нужен доступ к социальным сетям или поисковым системам. Эти границы задаются на уровне браузера и не зависят от prompt или логики рассуждений агента.

Во-вторых, можно отключить рискованные функции браузера. С помощью Chrome policies можно выключить менеджер паролей, заблокировать загрузку файлов, отключить autofill и контролировать десятки других возможностей браузера. Для агентов ввода данных, работающих с чувствительными системами, такие меры снижают риск непреднамеренного хранения или утечки данных.

В-третьих, можно разделить управление политиками и разработку агента. Managed policies настраиваются на уровне браузера через control plane API и применяются к каждому сеансу, созданному из этого браузера. Это позволяет команде безопасности определять утвержденные конфигурации браузера, а команде разработки сосредоточиться на логике агента, не встраивая решения по политике в код приложения.

Как применяются Chrome policies и root CA certificates

Интеграция имеет два уровня применения политик и дополнительную необязательную настройку доверия к сертификатам.

Managed policies работают на уровне браузера. При создании браузера через control plane API вы передаете JSON-файлы Chrome enterprise policy, хранящиеся в Amazon Simple Storage Service (Amazon S3). Сервис сохраняет эти политики и применяет их к каждому сеансу, созданному из этого браузера. Managed policies соответствуют каталогу Chrome /etc/chromium/policies/managed/. Их нельзя переопределить настройками уровня сеанса.

Recommended policies работают на уровне сеанса. При запуске сеанса браузера через data plane API можно дополнительно передать JSON-файлы политик. Они соответствуют каталогу Chrome /etc/chromium/policies/recommended/ и работают как пользовательские предпочтения. Если managed policy и recommended policy конфликтуют по одному и тому же параметру, приоритет остается за managed policy. Это стандартное поведение Chrome.

Пользовательские root CA certificates позволяют хранить корневой сертификат вашей организации в AWS Secrets Manager и ссылаться на него при создании браузера или AgentCore Code Interpreter. Сервис импортирует сертификат в хранилище доверенных сертификатов, поэтому подключения к внутренним сервисам и SSL-intercepting прокси проходят без отключения проверки сертификатов.

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

На следующей схеме показано, как JSON-файлы политик Chrome и root CA certificates проходят из вашей среды через control plane и data plane Amazon Bedrock AgentCore в изолированный сеанс браузера.

Рисунок 1: Поток применения политик из вашей среды через Amazon Bedrock AgentCore в изолированный сеанс браузера.

1. В вашей среде вы храните JSON-файлы политик Chrome в Amazon S3, а необязательные root CA certificates — в AWS Secrets Manager.
2. Control plane извлекает JSON политик из вашего S3 bucket при вызове CreateBrowser (стрелка 1) и получает root CA certificate из AWS Secrets Manager, если он настроен (стрелка 2, пунктиром показано, что шаг необязательный).
3. Ваше приложение вызывает API CreateBrowser (стрелка 3), а затем API StartBrowserSession (стрелка 4).
4. Control plane передает метаданные конфигурации браузера в data plane (стрелка 5).
5. Data plane разворачивает managed policies, recommended policies и root CA certificates в изолированном сеансе браузера (стрелка 6). Chrome считывает объединенную конфигурацию при запуске и применяет политики на протяжении всего сеанса.

Требования

Перед началом убедитесь, что у вас есть следующее:

• Python 3.10 или новее
• Аккаунт AWS с включенным доступом к Amazon Bedrock AgentCore
• Настроенные учетные данные AWS. Проверить их можно командой aws sts get-caller-identity
• Регион AWS, в котором доступен Amazon Bedrock AgentCore (см. поддерживаемые регионы AWS в документации AgentCore)
• Доступ к модели ИИ, которая будет управлять агентом. В этом материале используется Anthropic Claude через Amazon Bedrock. AgentCore не привязан к конкретной модели. Можно использовать других провайдеров и фреймворки агентов. Подробности по настройке разных моделей в Strands Agents см. в разделе Model Providers документации Strands Agents.

Ноутбук автоматически создает необходимые ресурсы AWS, включая S3 bucket, IAM execution role, AgentCore Browser и AgentCore Code Interpreter. Такая автоматическая подготовка предназначена для демонстрации. Для production-развертываний следует использовать уже существующие ресурсы с IAM-политиками на основе принципа наименьших привилегий, предварительно проверенными вашей командой безопасности. Полные сведения о IAM-политиках см. в README примера.

Важно: Используйте временные учетные данные из AWS IAM Identity Center или AWS Security Token Service (AWS STS). Не используйте долгоживущие access keys. При настройке IAM-подключений соблюдайте принцип наименьших привилегий.

Настройка окружения

Полный код для этого walkthrough доступен в виде Jupyter notebook в репозитории с примерами. Склонируйте его и запускайте ячейки по порядку.

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

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 # На Windows: .venv\Scripts\activate
pip install -r requirements.txt

Настроить учетные данные

export AWS_REGION=us-west-2

Важно: Используйте временные учетные данные. Не размещайте credentials в системе контроля версий.

Запустить notebook

jupyter notebook browser-chrome-policies.ipynb

Запускайте ячейки последовательно. Часть 1 посвящена Chrome enterprise policies. Часть 2 посвящена пользовательским root CA certificates. Ниже объясняется, что делает каждая часть и на чем строится ключевой код.

Пошаговое руководство

Ноутбук состоит из двух частей. В первой создается Chrome enterprise policy, она применяется к пользовательскому AgentCore Browser, а Playwright используется для проверки того, что разрешенные URL открываются, а заблокированные отклоняются. Во второй демонстрируются пользовательские root CA certificates с AgentCore Code Interpreter.

Определить Chrome enterprise policy

Первые ячейки notebook задают Chrome enterprise policy, которая ограничивает браузер документацией AWS и отключает функции, не нужные агенту. JSON политики использует стандартные настройки Chrome enterprise policy.

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

Следующая таблица описывает каждый параметр политики.

Обратите внимание: URLAllowlist использует формат pattern для URL-фильтрации Chrome, который отличается от обычных glob-шаблонов. Доменные шаблоны вроде docs.aws.amazon.com совпадают с точным доменом. Лидирующая точка, например в .aws.amazon.com, соответствует поддоменам. Полный синтаксис шаблонов см. в документации политики URLAllowlist.

Также обратите внимание, что DeveloperToolsAvailability должен быть установлен в 0 (или опущен) для браузеров, которые будут использоваться с Playwright или другой CDP-автоматизацией. Автоматизация AgentCore Browser использует Chrome DevTools Protocol (CDP). Если установить это значение в 2, CDP на уровне Chrome будет отключен, и автоматизация тихо перестанет работать. WebSocket-соединение на уровне proxy установится, но Chrome будет отклонять CDP-команды, из-за чего возникнут тайм-ауты.

Создать браузер с managed policies

Следующие ячейки создают пользовательский браузер, который применяет политику к каждому сеансу. Ключевой вызов API использует параметр enterprise_policies с типом MANAGED. Также включается запись сеанса, чтобы затем можно было воспроизвести работу браузера.

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",
        },
    },
)

Затем notebook опрашивает get_browser() до тех пор, пока статус не перейдет из CREATING в READY.

Полный код см. в sample notebook.

Показать применение Chrome policy с помощью Playwright

Notebook запускает сеанс браузера и использует Playwright для перехода по двум URL. Первый URL, docs.aws.amazon.com, разрешен политикой, поэтому страница загружается успешно. Второй URL, www.wikipedia.org, блокируется политикой, поэтому Chrome отображает страницу ошибки.

В тесте используется wait_until=»domcontentloaded» вместо события load по умолчанию. На страницах документации AWS постоянно идет фоновая сетевая активность из-за скриптов аналитики и tracking pixels, из-за чего Playwright может не дождаться состояний networkidle и default load. Аналогично извлечение текста использует page.evaluate(), чтобы запускать JavaScript напрямую в контексте браузера, обходя тайм-ауты selector engine Playwright на страницах с постоянными изменениями 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

В этом и состоит основная ценность Chrome policies. Ограничение срабатывает на уровне браузера и не зависит от рассуждений агента или инструкций prompt.

Пока выполняется ячейка, вы можете наблюдать браузер вживую в консоли Amazon Bedrock AgentCore. Перейдите в раздел Built-in tools, выберите браузер docs_research_browser и нажмите View live session для активного сеанса.

Полный код см. в sample notebook.

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

Поскольку при создании браузера была включена запись сеанса, вы можете воспроизвести сеанс и увидеть применение политики.

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

Интерфейс воспроизведения сеанса показывает интерактивное видео с ползунком по таймлайну, помеченные по времени действия пользователя, включая каждое событие навигации и попытку, которая была заблокирована, а также сетевые события, подтверждающие, что успешным был только разрешенный трафик.

Запустить Strands Agent с ограниченным браузером (необязательно)

В notebook есть необязательная ячейка, которая создает агента Strands с браузером, ограниченным политикой. Агент исследует документацию AgentCore внутри разрешенного домена. Когда он пытается перейти на неразрешенный URL, он видит, что страница заблокирована, и продолжает работу с доступными страницами.

В примере используется Anthropic Claude через Amazon Bedrock. AgentCore не зависит от конкретной модели. Можно подставить других провайдеров моделей. Для настройки моделей см. раздел Model Providers в документации Strands Agents.

Полный код см. в sample notebook.

Демонстрация пользовательских root CA certificates

Организациям, которые используют внутренние сервисы с private CA или направляют трафик через корпоративные SSL-intercepting прокси, нужно, чтобы агенты доверяли таким непубличным сертификатам. Для этого AgentCore Browser и AgentCore Code Interpreter поддерживают пользовательские root CA certificates.

В этом разделе используется https://untrusted-root.badssl.com — публичный сайт, который намеренно предъявляет сертификат, подписанный недоверенным root CA. HTTPS-подключения к этому сайту завершаются ошибками проверки сертификата так же, как подключения к внутренним сервисам без правильного root CA.

Notebook выполняет три шага.

Сохранить root CA certificate в AWS Secrets Manager

Недоверенный root CA certificate сайта BadSSL доступен публично (источник: badssl.com/certs/ca-untrusted-root.crt). Notebook сохраняет его в AWS Secrets Manager, чтобы Amazon Bedrock AgentCore мог импортировать его в trust store сертификатов. В production-среде таким же способом в Secrets Manager будет помещен внутренний CA certificate организации или root CA certificate SSL-intercepting proxy.

Показать ошибку без root CA

Notebook создает стандартный сеанс AgentCore Code Interpreter и запускает Python-код, который вызывает urllib.request.urlopen() для недоверенного сайта. Подключение завершается ошибкой SSLCertVerificationError. Это та же ошибка, которую вы увидели бы при подключении к внутренним корпоративным сервисам, использующим private CA.

Показать успешное подключение с root CA

Затем notebook создает пользовательский AgentCore Code Interpreter, который доверяет root CA сертификату BadSSL с помощью параметра certificates. Этот же шаблон уже доступен в BrowserClient.create_browser().

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)],
)

После запуска того же кода urlopen() в пользовательском interpreter вывод показывает Status: 200. Подключение успешно, потому что root CA BadSSL теперь доверенный. Изменения в коде не потребовались. Доверие было настроено на уровне инфраструктуры.

Полный код см. в sample notebook.

Применение для вашей организации

Демонстрация badssl.com отражает два реальных сценария.

Пользовательские root CA certificates работают и в AgentCore Browser, и в AgentCore Code Interpreter. В браузере сертификат импортируется в trust store Chrome. В interpreter сервис настраивает переменные окружения, такие как REQUESTS_CA_BUNDLE и SSL_CERT_FILE, чтобы библиотеки Python доверяли пользовательскому CA без обходных решений на уровне кода.

Можно объединить root CA certificates и Chrome policies в одном браузере. В примере ниже создается браузер, подключенный к VPC, который доверяет внутреннему CA и ограничивает навигацию корпоративным intranet.

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"
        )
    ],
)

Очистка ресурсов

Чтобы избежать расходов, удалите созданные ресурсы. Запустите ячейки очистки в конце notebook: сначала они остановят активные сеансы браузера, а затем удалят пользовательский браузер, AgentCore Code Interpreter, IAM role, секрет в Secrets Manager и S3 policy file.

Сеансы Amazon Bedrock AgentCore Browser тарифицируются, пока они активны. Подробности см. в разделе о ценах Amazon Bedrock AgentCore.

Заключение

В этом материале вы настроили Chrome enterprise policies, чтобы ограничить браузерного агента разрешенными доменами и отключить рискованные функции браузера. Вы увидели применение ограничений через live view и запись сеанса. Также вы продемонстрировали пользовательские root CA certificates на публичном тестовом сайте, показав, что сеансы AgentCore Code Interpreter могут подключаться к сервисам с непубличными CA.

С этими возможностями можно разворачивать AI-агентов, которые работают в рамках security и compliance-ограничений вашей организации. Chrome policies дают управление на уровне браузера, независимо от кода приложения агента. Поддержка пользовательских root CA устраняет барьеры подключения к внутренней инфраструктуре.

Что делать дальше

Начните с создания браузера с allowlist URL, настроенным под ваш сценарий. В списке политик Chrome Enterprise описано более 450 настраиваемых параметров. Для агентов ввода данных, работающих с чувствительными формами, стоит отключить autofill и менеджер паролей. Для агентов, обрабатывающих документы на конкретном портале, ограничьте загрузки и навигацию доменом этого портала.

Если в вашей организации используется private PKI, настройте root CA certificates и проверьте подключение к внутренним сервисам. Для агентов, работающих за SSL-intercepting прокси, объедините настройку root CA с функцией proxy configuration, чтобы направлять трафик через корпоративный proxy и при этом доверять его сертификату.

Подробнее о возможностях Amazon Bedrock AgentCore Browser см. в документации Amazon Bedrock AgentCore Browser. Если у вас есть замечания, создайте issue в репозитории Amazon Bedrock AgentCore Python SDK.

Важно: Этот пример кода предназначен для разработки и демонстрации. Для production-развертываний соблюдайте принцип наименьших привилегий для IAM-полномочий, ограничивайте политики Amazon S3 bucket только авторизованными субъектами, обновляйте сертификаты AWS Secrets Manager до истечения срока действия и следуйте разделу безопасности AWS Well-Architected Framework.

Chrome является товарным знаком Google LLC. Все прочие товарные знаки принадлежат их соответствующим владельцам.

Материал — перевод статьи с английского.

Оригинал: Control where your AI agents can browse with Chrome enterprise policies on Amazon Bedrock AgentCore