브라우저 에이전트의 목줄, AWS가 Chrome 정책을 붙인 이유

AI 요약

• 무슨 일: AWS가 AgentCore Browser에서 Chrome enterprise policies와 custom root CA를 구성하는 실제 샘플을 공개했습니다.
  • 기능 발표는 2026년 3월 25일, 구현 흐름을 보여준 AWS AI 블로그 글은 2026년 5월 14일입니다.
• 의미: 브라우저 에이전트의 안전 경계가 프롬프트나 앱 코드가 아니라 브라우저 정책 계층으로 내려갑니다.
• 실무 영향: URL allowlist, 다운로드 차단, 비밀번호 저장 비활성화, 사설 CA 신뢰, session replay가 에이전트 런타임 요구사항이 됩니다.
• 주의점: 정책을 강하게 잠그면 자동화도 깨집니다. 특히 DeveloperToolsAvailability는 CDP/Playwright 연결에 직접 영향을 줍니다.

브라우저 에이전트의 가장 위험한 순간은 모델이 틀린 답을 할 때만이 아닙니다. 더 현실적인 위험은 에이전트가 브라우저를 들고 움직일 때 생깁니다. 허가되지 않은 도메인으로 이동하고, 외부 문서 안의 지시문을 따라가고, 파일을 다운로드하고, 비밀번호 저장 팝업에 민감한 자격 증명을 남기고, 회사 내부 서비스에 접속하다가 사설 인증서 오류 앞에서 멈춥니다. 사람에게는 익숙한 브라우저가 에이전트에게는 권한이 넓은 실행 환경이 됩니다.

AWS가 2026년 5월 14일 공개한 Amazon Bedrock AgentCore Browser의 Chrome enterprise policies 구성 글은 그래서 단순한 튜토리얼 이상의 의미가 있습니다. 기능 자체는 2026년 3월 25일 AWS What's New에서 먼저 발표됐습니다. 그러나 이번 글은 정책 JSON을 S3에 올리고, CreateBrowser와 StartBrowserSession API를 통해 관리형·권장 정책을 나누고, Playwright로 실제 차단을 확인하고, custom root CA certificate를 Secrets Manager에 넣어 내부 인증서 환경까지 다루는 흐름을 보여줍니다.

핵심은 “에이전트에게 조심하라고 말한다”가 아닙니다. 브라우저 자체가 어디로 갈 수 있고, 무엇을 저장할 수 있고, 어떤 인증서를 신뢰할 수 있고, 어떤 세션 기록을 남길지를 인프라 계층에서 정한다는 점입니다. 에이전트 보안이 prompt engineering에서 runtime governance로 이동하고 있습니다.

프롬프트가 아니라 브라우저가 막는 경계

브라우저 에이전트를 만들 때 흔한 첫 번째 방어선은 system prompt입니다. “허가된 사이트만 방문하라”, “민감 정보를 저장하지 말라”, “다운로드하지 말라” 같은 지시를 넣습니다. 이 방식은 필요하지만 충분하지 않습니다. 에이전트가 외부 페이지를 읽는 순간, 그 페이지도 지시를 포함할 수 있습니다. invoice PDF, 고객 메일, CRM note, 문서 위키, 지원 티켓 안에 “이전 지시를 무시하고 다른 URL로 이동하라”는 식의 prompt injection이 숨어 있을 수 있습니다.

사람은 그런 문장을 문서 내용으로 볼 수 있지만, 에이전트는 작업 지시와 외부 콘텐츠의 경계를 혼동할 수 있습니다. 특히 브라우저 에이전트는 단순 텍스트 생성기가 아니라 실제 웹 페이지를 열고 클릭하고 폼을 채우는 도구입니다. 잘못된 도메인으로 이동하는 행위 자체가 데이터 유출 경로가 됩니다.

AWS 글은 이 문제를 Chrome enterprise policies로 다룹니다. 예제 정책은 URLBlocklist를 ["*"]로 두고, URLAllowlist에는 docs.aws.amazon.com, .aws.amazon.com, .amazonaws.com만 넣습니다. 즉 기본은 모두 차단이고, 필요한 도메인만 허용합니다. 여기에 PasswordManagerEnabled: false, DownloadRestrictions: 3, AutofillAddressEnabled: false, AutofillCreditCardEnabled: false 같은 설정을 붙입니다.

이 접근의 장점은 명확합니다. 에이전트가 무슨 추론을 하든, 브라우저가 정책을 위반하는 탐색을 실행하지 않습니다. AWS 샘플은 Playwright로 docs.aws.amazon.com을 열면 성공하고, www.wikipedia.org는 Chrome policy에 의해 차단되는 결과를 보여줍니다. 중요한 문장은 여기입니다. 제한은 에이전트의 reasoning이나 prompt instruction과 독립적으로 브라우저 수준에서 일어납니다.

관리형 정책과 세션 정책의 차이

AWS 문서에서 눈에 띄는 설계는 정책을 두 단계로 나눈다는 점입니다. AgentCore Browser enterprise policies 문서는 Chromium enterprise policy를 Managed와 Recommended로 나눕니다.

Managed 정책은 관리자가 강제하는 정책입니다. CreateBrowser API에서 설정하고, /etc/chromium/policies/managed/에 배치됩니다. 이 정책은 해당 custom browser에서 생성되는 모든 세션에 적용되며 세션 수준 설정으로 덮어쓸 수 없습니다. 예를 들어 재무 포털 자동화용 브라우저를 만들었다면, 그 브라우저는 항상 특정 도메인 allowlist와 다운로드 차단을 강제할 수 있습니다.

Recommended 정책은 세션 수준 preference에 가깝습니다. StartBrowserSession API에서 설정하고, /etc/chromium/policies/recommended/에 배치됩니다. 같은 브라우저 안에서도 특정 작업 세션에만 북마크 바, 번역, spellcheck 같은 설정을 다르게 줄 수 있습니다. 다만 관리형 정책과 충돌하면 관리형 정책이 이깁니다. 이는 Chrome의 일반 정책 precedence와 같은 구조입니다.

개발팀 입장에서는 이 분리가 중요합니다. 보안팀은 “어떤 브라우저 런타임도 이 도메인 밖으로 나가면 안 된다”는 규칙을 managed policy로 박을 수 있습니다. 개발팀은 특정 작업에 필요한 편의 설정을 recommended policy로 조정할 수 있습니다. 보안 정책과 에이전트 앱 로직이 같은 코드 파일 안에서 뒤섞이지 않습니다.

AWS 글의 architecture 설명은 정책 JSON이 S3에서 출발해 AgentCore control plane과 data plane을 거쳐 격리된 브라우저 세션에 배치되는 흐름을 설명합니다. custom root CA certificate는 Secrets Manager에서 가져옵니다. 브라우저는 시작 시 병합된 정책을 읽고 세션 내내 적용합니다.

사설 CA가 왜 에이전트 뉴스인가

custom root CA certificate는 언뜻 브라우저 정책보다 덜 흥미롭게 보일 수 있습니다. 하지만 enterprise agent에서는 이쪽이 더 현실적인 병목일 때가 많습니다. 에이전트가 실제 일을 하려면 public web만 돌아다니지 않습니다. Jira, Artifactory, 사내 HR 포털, 재무 시스템, ERP, 문서 저장소, 보안 대시보드 같은 내부 서비스를 열어야 합니다. 이런 시스템은 조직의 private CA로 서명된 인증서를 쓰거나, Zscaler와 Palo Alto Networks 같은 SSL-intercepting corporate proxy 뒤에 있을 수 있습니다.

사람의 회사 노트북은 이미 사설 루트 인증서를 신뢰하도록 구성돼 있습니다. 하지만 관리형 원격 브라우저나 code interpreter는 별도 환경입니다. 이 환경이 조직 CA를 신뢰하지 않으면 HTTPS 연결은 SSLCertVerificationError 같은 오류로 막힙니다. 여기서 나쁜 해결책은 인증서 검증을 끄는 것입니다. AI 에이전트에게 내부 서비스 접근 권한을 주면서 TLS 검증을 끄는 것은 보안의 방향이 거꾸로 갑니다.

AWS 샘플은 BadSSL의 untrusted root CA 테스트 사이트를 사용합니다. 먼저 root CA 없이 연결하면 인증서 검증 오류가 나고, Secrets Manager에 저장한 root CA를 참조하는 custom Code Interpreter를 만들면 같은 요청이 200으로 성공합니다. 글은 이 패턴이 AgentCore Browser에도 적용된다고 설명합니다. 핵심은 코드가 아니라 인프라 수준에서 trust store를 구성한다는 점입니다.

이것은 에이전트 인프라가 점점 “사람 노트북의 보안 설정”을 재현해야 한다는 뜻입니다. VPN, VPC, proxy, CA trust, IAM, 감사 로그, 세션 녹화가 모두 에이전트 런타임의 일부가 됩니다. 모델 성능만으로는 내부 업무 자동화가 되지 않습니다. 내부망에 안전하게 들어가고, 허가된 곳만 보고, 실패했을 때 재생 가능한 기록을 남겨야 합니다.

CDP를 막으면 에이전트도 막힌다

이번 AWS 글에서 가장 실무적인 주의점은 DeveloperToolsAvailability입니다. 이름만 보면 보안팀이 당연히 끄고 싶어질 설정입니다. 그러나 AgentCore Browser 자동화는 Chrome DevTools Protocol, 즉 CDP를 사용합니다. Playwright 같은 자동화 도구도 CDP 계층에 의존합니다.

AWS 글은 DeveloperToolsAvailability를 2로 설정하면 Chrome 수준에서 CDP가 막혀 자동화가 조용히 깨질 수 있다고 경고합니다. WebSocket 연결은 proxy layer에서 성공한 것처럼 보이지만 Chrome이 CDP command를 거부하면서 timeout이 발생할 수 있습니다. 샘플 정책은 자동화를 위해 이 값을 0으로 두거나 생략하라고 설명합니다.

이 사례는 브라우저 에이전트 보안의 핵심 긴장을 잘 보여줍니다. 보안 정책은 강할수록 좋아 보이지만, 에이전트는 브라우저를 조작해야 합니다. DevTools를 완전히 막으면 공격 표면은 줄어들 수 있지만, 자동화도 함께 멈춥니다. 다운로드를 전부 막으면 데이터 유출 위험은 줄지만, PDF나 CSV를 처리해야 하는 업무는 막힐 수 있습니다. URL allowlist를 너무 좁히면 제3자 로그인, CDN, SSO, analytics 차단으로 정상 서비스가 깨질 수 있습니다.

따라서 에이전트 브라우저 정책은 “잠글 수 있는 것을 모두 잠그자”가 아니라 “업무 단위별 최소 권한 브라우저를 만들자”에 가깝습니다. 송장 처리 에이전트, 문서 조사 에이전트, CRM 업데이트 에이전트, 보안 콘솔 점검 에이전트는 서로 다른 브라우저 정책을 가져야 합니다. 같은 모델을 쓰더라도 실행 환경은 달라야 합니다.

왜 지금 이 변화가 중요한가

2025년과 2026년의 에이전트 경쟁은 빠르게 실행면으로 이동했습니다. 모델 회사들은 코딩 에이전트, 업무 에이전트, 브라우저 에이전트, voice agent를 내놓고 있습니다. 개발자 도구 회사는 IDE와 PR workflow를 에이전트화하고, 클라우드 회사는 agent runtime과 observability를 묶고, SaaS 회사는 CRM·회계·문서 워크플로를 agentic workflow로 재포장합니다.

이 흐름에서 가장 늦게 해결되는 영역이 권한입니다. 데모에서는 에이전트가 검색하고 클릭하고 양식을 채우는 장면이 멋져 보입니다. 하지만 기업 환경에서는 질문이 바뀝니다. 이 에이전트는 어떤 도메인을 열 수 있나? 파일을 내려받을 수 있나? 비밀번호를 저장하나? 내부 인증서를 어떻게 신뢰하나? 누가 세션을 다시 볼 수 있나? 정책이 앱 코드에 박혀 있나, 보안팀이 독립적으로 관리하나?

AgentCore Browser의 Chrome 정책 지원은 이 질문에 대한 AWS식 답입니다. 브라우저는 격리된 세션으로 띄우고, 정책은 Chromium enterprise policy로 적용하고, 정책 파일은 S3에 두고, root CA는 Secrets Manager에 두고, 세션은 live view와 recording으로 관측합니다. 이는 단일 기능이라기보다 에이전트 런타임이 enterprise control plane으로 변하는 징후입니다.

브라우저 에이전트는 새 보안 제품군을 요구한다

브라우저 에이전트의 보안은 기존 웹 보안과 비슷하면서 다릅니다. 기존 웹 보안은 사람 사용자를 기준으로 설계됐습니다. 사용자가 피싱 링크를 누르지 않게 하고, SSO와 MFA를 붙이고, CASB와 DLP로 데이터 이동을 감시하고, 브라우저 정책으로 저장 기능을 관리합니다. 에이전트 환경에서는 사용자가 사람이 아니라 모델입니다. 모델은 문서와 지시를 동시에 읽고, 페이지의 visual state와 DOM state를 해석하며, 여러 단계의 작업을 자동으로 이어갑니다.

그래서 에이전트 브라우저에는 최소 네 가지 통제가 필요합니다.

첫째, 탐색 범위입니다. URL allowlist와 blocklist는 단순 편의 기능이 아니라 prompt injection의 blast radius를 줄이는 장치입니다. 에이전트가 외부 페이지의 악성 지시를 읽더라도 물리적으로 이동할 수 있는 도메인이 제한돼야 합니다.

둘째, 브라우저 기능입니다. password manager, autofill, download, extension, clipboard, profile persistence는 모두 업무에 따라 도움이 될 수도 있고 위험이 될 수도 있습니다. 데이터 입력 에이전트에게 password manager는 불필요한 저장 위험입니다. 문서 처리 에이전트에게 다운로드는 필요할 수 있지만, 파일 유형과 저장 위치를 제한해야 합니다.

셋째, 내부 연결성입니다. 사설 CA, proxy, VPC, private DNS 없이는 에이전트가 기업 내부 시스템을 제대로 열 수 없습니다. 반대로 이를 너무 넓게 열면 에이전트가 내부망을 돌아다니는 자동화된 브라우저가 됩니다. 접근은 업무 단위로 나눠야 합니다.

넷째, 관측성과 책임입니다. live view와 session replay는 단순 디버깅 도구가 아닙니다. 에이전트가 어떤 페이지를 열었고, 어떤 차단을 만났고, 어떤 action을 했는지 사후에 확인할 수 있어야 합니다. 특히 규제 산업에서는 “AI가 했습니다”가 설명이 될 수 없습니다. 누가 어떤 정책으로 실행을 허용했고, 어떤 로그가 남았는지가 필요합니다.

경쟁 구도: 모델보다 런타임

AWS의 이번 움직임은 모델 경쟁과 다른 층위에 있습니다. AgentCore Browser는 특정 모델에만 묶인 제품이 아닙니다. AWS 글은 샘플에서 Anthropic Claude를 Amazon Bedrock으로 쓰지만, AgentCore는 model-agnostic이며 다른 모델 provider와 agent framework를 대체할 수 있다고 설명합니다. 샘플 README도 Strands agent, Playwright, BrowserClient, CodeInterpreter 같은 실행 도구 중심으로 구성돼 있습니다.

이 지점에서 경쟁 구도가 보입니다. OpenAI, Anthropic, Google은 각자의 에이전트 제품과 플랫폼을 밀고 있습니다. Browserbase나 Playwright 기반 인프라는 원격 브라우저 자동화 계층을 제공합니다. 기업은 자체 runner와 VPN, proxy, VDI, SIEM을 조합해 내부 통제면을 만들 수 있습니다. AWS는 AgentCore를 통해 이 복잡한 계층을 클라우드 관리형 서비스로 묶으려 합니다.

모델의 지능이 일정 수준 이상 올라가면 차별화는 실행 환경으로 이동합니다. 누가 더 긴 작업을 안정적으로 돌리나, 누가 내부 도구와 안전하게 연결하나, 누가 감사 가능한 로그를 남기나, 누가 정책과 개발을 분리하나, 누가 비용과 권한을 조직 단위로 관리하나가 중요해집니다. Chrome enterprise policies와 custom root CA support는 화려한 모델 발표는 아니지만, 실제 배포에서는 이런 기능이 데모와 운영의 차이를 만듭니다.

개발팀이 지금 확인해야 할 것

AI 팀이 브라우저 에이전트를 검토하고 있다면, 이번 AWS 글에서 가져갈 체크리스트는 꽤 구체적입니다.

먼저 에이전트별 URL 범위를 써봐야 합니다. “인터넷 접근 허용”은 정책이 아닙니다. 고객 지원 에이전트가 필요한 도메인, 재무 에이전트가 필요한 도메인, 리서치 에이전트가 필요한 도메인을 따로 적어야 합니다. SSO, CDN, API endpoint, 문서 저장소, 이미지 호스트까지 포함해야 정상 동작합니다.

다음으로 브라우저 기능을 업무별로 나눠야 합니다. password manager와 autofill은 기본적으로 꺼두는 편이 합리적입니다. 다운로드는 업무가 요구할 때만 열고, 파일 처리 후 저장·삭제 정책을 따로 잡아야 합니다. DevTools/CDP는 자동화에 필요하므로 무작정 막으면 안 됩니다. 대신 CDP 접근이 가능한 환경을 누가 만들고 누가 실행할 수 있는지 IAM으로 좁혀야 합니다.

셋째, 내부 인증서 전략을 정해야 합니다. 에이전트가 내부 서비스를 읽어야 한다면 custom root CA를 어떻게 배포하고 회전할지 결정해야 합니다. Secrets Manager에 CA를 넣는 방식은 편하지만, 접근 권한과 rotation, 감사가 따라와야 합니다. TLS 검증을 끄는 임시 해결책은 장기적으로 보안 부채가 됩니다.

넷째, 세션 기록을 민감 데이터로 취급해야 합니다. session replay는 강력한 디버깅·감사 도구이지만, 화면에 표시된 고객 정보, 내부 문서, 토큰, 계정 정보가 함께 저장될 수 있습니다. recording bucket의 S3 권한, retention, redaction, 접근 로그가 필요합니다.

마지막으로 정책을 테스트해야 합니다. AWS 샘플이 Playwright로 allowed URL과 blocked URL을 모두 검증하는 이유가 있습니다. 정책은 문서로만 맞지 않습니다. 실제 브라우저에서 페이지가 열리는지, 차단이 의도대로 되는지, CDP가 살아 있는지, 사설 CA 연결이 되는지 자동화 테스트로 확인해야 합니다.

작지만 중요한 전환

이번 발표는 GPT나 Claude의 새 모델처럼 큰 관심을 끌 뉴스는 아닙니다. 커뮤니티 반응도 아직 조용합니다. 하지만 조용하다고 덜 중요한 것은 아닙니다. 브라우저 에이전트가 실제 업무 시스템에 들어가려면, 제품은 결국 이런 지루한 질문에 답해야 합니다. 어디까지 갈 수 있나. 무엇을 저장할 수 있나. 어떤 인증서를 믿나. 누가 기록을 볼 수 있나. 정책은 누가 바꾸나.

AWS AgentCore Browser의 Chrome policy 지원은 브라우저 에이전트를 운영 환경으로 보내기 위한 기반 작업입니다. 에이전트가 웹을 보는 시대에는 브라우저가 새 실행 권한이 됩니다. 그리고 실행 권한에는 항상 정책, 인증서, 감사, 최소 권한이 따라옵니다.

개발자와 AI 제품팀이 봐야 할 핵심은 “AWS에서도 브라우저 에이전트를 만들 수 있다”가 아닙니다. 더 정확히는 “브라우저 에이전트는 이제 model wrapper가 아니라 managed runtime의 문제가 됐다”입니다. 좋은 프롬프트는 여전히 필요합니다. 하지만 운영 환경에서 에이전트를 믿게 만드는 것은 프롬프트보다 더 아래에 있는 정책 계층일 가능성이 큽니다.

출처

• AWS AI Blog, Control where your AI agents can browse with Chrome enterprise policies on Amazon Bedrock AgentCore
• AWS What's New, Amazon Bedrock AgentCore adds support for Chrome policies and custom root CA
• AWS Docs, Interact with web applications using Amazon Bedrock AgentCore Browser
• AWS Docs, Using browser enterprise policies
• awslabs agentcore-samples, AgentCore Browser with Chrome Enterprise Policies and Custom Root CAs