Amazon Google 브라우저 에이전트, 완벽한 해결책 없는 프롬프트 인젝션 문제에 직면

Amazon Google 브라우저 에이전트는 이제 같은 충돌에 직면해 있다. 자율성이 커질수록 프롬프트 인젝션 공격이 피해를 일으킬 여지도 커진다. 새로운 보호 장치에도 불구하고 연구자들은 일반 웹페이지, 이메일, 양식, 소셜 게시물을 통해 에이전트를 조종하는 방법을 계속 찾아내고 있다. 이 취약점은 깔끔한 패치 하나를 기다리는 또 다른 브라우저 버그가 아니라 AI 브라우저 설계에 지속적으로 제약을 가하는 요소가 되고 있다.

당면한 우려는 AI 에이전트가 읽는 콘텐츠에 악의적 지시가 숨겨지는 간접 프롬프트 인젝션이다. 이러한 지시는 사용자의 요청과 경쟁하며 에이전트의 다음 행동에 영향을 미칠 수 있다. 기존 브라우저는 악의적 콘텐츠를 표시한다. 에이전틱 브라우저는 이를 해석하고 다른 서비스로 넘어가 사용자의 권한으로 행동할 수 있다.

이 차이는 Amazon과 Google을 Microsoft, OpenAI, Anthropic, Perplexity, 전문 브라우저 공급업체가 참여하는 더 광범위한 보안 경쟁 구도에 놓이게 한다. 각 기업은 웹 전반에서 유용한 작업을 완료할 수 있는 에이전트를 원한다. 그러나 추가되는 모든 권한은 에이전트가 누구의 지시를 따라야 하는지 오해할 때의 결과를 확대한다.

불편한 결론은 브라우저 에이전트를 사용할 수 없다는 것이 아니다. 공급업체가 프롬프트 인젝션 탐지를 완전한 보안 경계로 취급할 수 없다는 점이다. 기업은 일부 악성 지시가 통과할 수 있다고 가정하고, 침해된 에이전트가 접근·변경·공개할 수 있는 범위를 제한해야 한다.

Amazon Google 브라우저 보안 경쟁에서 달라진 점

프롬프트 인젝션은 이론적인 모델 취약점에서 운영 환경의 브라우저 보안 문제로 옮겨갔다.

보안 연구자들은 악성 콘텐츠가 브라우저의 전통적인 코드 실행 경로를 악용하지 않고도 에이전트의 방향을 바꿀 수 있음을 반복적으로 보여왔다. 공격자는 대신 콘텐츠에 대한 모델의 해석을 노린다. 숨겨진 지시는 웹페이지, 이메일, 문서, 심지어 사용자 인터페이스 요소 안에도 나타날 수 있다.

에이전트가 인증된 브라우저 세션을 사용할 수 있을 때 공격은 심각해진다. 에이전트는 받은편지함을 읽고, 다른 탭을 열며, 양식을 제출하거나, 연결된 서비스에서 정보를 가져올 수 있다. 정상적인 작업 중에는 편리해 보이는 행동이 공격 체인의 유용한 구성 요소가 된다.

Zenity 연구자들은 이러한 광범위한 에이전틱 브라우저 취약점 범주를 PleaseFix로 설명했다. 이들의 테스트는 에이전트가 웹사이트와 로컬 리소스 사이를 이동하면서 자연어 목표를 따르는 방식을 겨냥했다. 브라우저 보안 연구 결과에 따르면 연구자들은 서로 다른 설계와 보호 장치를 확인했지만, 상용 에이전틱 브라우저 전반에서 여전히 공격 경로를 찾아냈다.

중요한 변화는 공격자의 경로다. 기존 브라우저 공격은 흔히 소프트웨어 취약점, 악성 확장 프로그램, 탈취된 자격 증명 또는 기만적인 클릭에 의존한다. 프롬프트 인젝션은 에이전트가 일반적인 요청을 처리하는 과정에서 읽도록 예상됐던 콘텐츠에서 시작될 수 있다.

사용자는 어시스턴트에게 제품 페이지를 요약해 달라고 요청할 수 있다. 해당 페이지에는 시각적으로는 숨겨져 있지만 모델이 읽을 수 있는 지시가 포함될 수 있다. 공격자는 공개 게시물, 뉴스레터 양식 또는 브라우저 도구를 통해 가져온 콘텐츠 안에도 지시를 삽입할 수 있다.

그렇다고 주입된 모든 지시가 성공한다는 뜻은 아니다. 모델, 분류기, 권한 시스템, 작업 확인 절차는 많은 시도를 차단할 수 있다. 문제는 이런 통제가 표현 방식, 제시 형태, 시점, 맥락을 바꿔 가며 대응하는 적응형 공격자와 맞서야 한다는 데 있다.

Google의 자체 측정 결과도 이러한 변화를 뒷받침한다. Google 보안팀은 알려진 간접 프롬프트 인젝션 패턴을 찾아 공개 웹 콘텐츠를 스캔했으며, 2025년 11월부터 2026년 2월 사이 악성 탐지 건수가 상대적으로 32% 증가했다고 보고했다. 또한 공격과 유사한 상당량의 정상 텍스트도 발견해 신뢰할 수 있는 분류를 어렵게 만들었다.

이 웹 위협 연구가 중요한 이유는 브라우저 방어 체계가 상충하는 두 가지 오류를 처리해야 하기 때문이다. 악성 콘텐츠를 놓치면 에이전트가 조작될 수 있다. 너무 공격적으로 차단하면 일반 페이지와 정당한 지시를 사용할 수 없게 된다.

Amazon은 대중용 브라우저가 아닌 클라우드 에이전트 플랫폼을 통해 이 문제에 접근한다. Bedrock AgentCore Browser는 사이트 탐색, 양식 작성, 정보 추출을 수행하는 에이전트를 위한 격리 환경을 개발자에게 제공한다. 기반 브라우저 세션이 격리돼 있더라도, 이러한 기능은 여전히 에이전트를 신뢰할 수 없는 콘텐츠에 노출한다.

따라서 Amazon Google 비교는 서로 다른 두 배포 모델을 반영한다. Google은 사람이 직접 사용하는 브라우저에 에이전틱 기능을 추가하고 있다. Amazon은 기업이 자체 브라우저 자동화를 구축하는 데 쓰는 인프라를 제공한다. 두 기업 모두 개방형 웹 콘텐츠와 권한 있는 에이전트 행동이 충돌하는 문제를 관리해야 한다.

브라우저 에이전트가 오래된 보안 경계를 약화시키는 이유

핵심 취약점은 하나의 모델이 공유된 추론 과정에서 신뢰된 지시와 신뢰할 수 없는 데이터를 함께 받을 때 나타난다.

웹 브라우저는 수십 년에 걸쳐 웹사이트들을 서로 분리해 왔다. 동일 출처 정책은 일반적으로 한 출처가 다른 출처의 민감한 정보를 자유롭게 읽지 못하도록 막는다. 샌드박스, 권한 요청, 프로세스 격리, 콘텐츠 보안 정책도 추가적인 장벽을 제공한다.

AI 에이전트는 사용자가 작업 수행을 승인하기 때문에 이러한 경계를 넘을 수 있다. 한 페이지를 읽고 다른 서비스를 참조해 결과를 결합할 수 있다. 이 능력은 제품의 핵심 이점이지만, 동시에 악성 콘텐츠가 통제하려 시도할 수 있는 다리를 만든다.

모델이 동일 출처 정책을 직접 깨뜨릴 필요는 없다. 사용자에게 허용된 정당한 브라우저 기능을 사용할 수 있기 때문이다. 악성 페이지가 에이전트를 설득해 받은편지함을 열고, 메시지를 읽고, 정보를 전송하게 한다면 각 단계는 모두 승인된 것처럼 보일 수 있다.

이를 흔히 혼동된 대리인 문제라고 부른다. 신뢰받는 구성 요소는 정당한 권한을 갖지만, 공격자가 이를 조작해 잘못된 목적으로 그 권한을 사용하게 만든다. 브라우저 에이전트는 이 대리인을 대화형, 확률적이며 여러 단계를 계획할 수 있는 존재로 만든다.

오픈소스 브라우저 에이전트 연구는 이러한 패턴이 자격 증명 노출과 무단 행동으로 이어질 수 있음을 보여줬다. 한 학술 연구는 브라우저 자동화 프레임워크에서 프롬프트 인젝션, 도메인 검증 우회, 자격 증명 유출을 보고했다. 해당 브라우저 에이전트 분석에는 공개된 취약점과 작동하는 개념 증명도 포함됐다.

에이전트가 작업 간 메모리를 유지하면 문제는 더 커진다. 악성 지시가 항상 즉각적인 피해를 유발할 필요는 없다. 저장된 맥락을 바꾸거나, 오해를 부르는 선호를 만들거나, 민감한 리소스를 사용할 수 있게 된 뒤의 의사결정에 영향을 주려 할 수 있다.

시각적 이해 능력은 또 다른 경로를 제공한다. 스크린샷을 해석하는 에이전트는 이미지나 인터페이스 요소에 삽입된 지시를 마주할 수 있다. 원시 페이지 텍스트만 필터링해서는 멀티모달 모델이 인식할 수 있는 모든 메시지를 잡아내지 못한다.

공격자는 “이전 지시를 무시하라” 같은 명백한 문구를 피할 수도 있다. 악성 단계를 사용자의 원래 목표를 달성하는 데 필요한 부분으로 포장할 수 있다. 예를 들어 뉴스레터 가입 요청은 데이터를 가져오거나 다른 도구를 여는 구실이 될 수 있다.

이 기법이 중요한 이유는 많은 방어 체계가 사용자의 목표와 적대적 지시 사이의 충돌을 찾기 때문이다. 공격자는 대신 악성 행동이 그 목표와 일치하는 것처럼 보이게 만들 수 있다. 문구는 덜 의심스러워지지만, 요구되는 기능은 여전히 위험하다.

프롬프트 인젝션은 한 가지 결정적 측면에서 SQL 인젝션과 다르다. 소프트웨어는 엄격한 문법과 매개변수화된 쿼리를 통해 SQL 명령과 데이터를 분리할 수 있다. 자연어 에이전트는 맥락적 해석에 의존하므로 지시와 정보가 언제나 명확한 기술적 경계를 갖는 것은 아니다.

구조화된 메시지와 출처 라벨은 이러한 분리를 개선할 수 있다. 개발자는 어떤 콘텐츠가 사용자, 웹페이지, 도구 또는 애플리케이션에서 왔는지 표시할 수 있다. 그러나 작업이 외부 콘텐츠의 의미에 의존할 경우, 모델은 여전히 그 콘텐츠를 해석해야 한다.

BrowseSafe로 발표된 연구는 브라우저 에이전트 내부의 프롬프트 인젝션 위험을 평가하고 현실적인 환경에서의 방어 수단을 검토했다. 이 연구는 새롭게 형성되는 합의를 반영한다. 탐지는 도움이 되지만, 최종적인 영향은 브라우저 아키텍처와 권한 설계가 결정한다.

이 때문에 완벽한 분류기가 존재하더라도 전체 문제를 해결하지는 못한다. 분류기 역시 모호한 언어를 처리하며, 공격자는 새로운 변형을 시험할 수 있다. 방어자는 하나의 잘못된 판단이 사용자의 전체 브라우저 세션을 열어주지 않도록 여러 독립적인 통제 수단을 마련해야 한다.

Amazon Google의 방어 체계는 완벽한 탐지보다 통제를 선택한다

Amazon과 Google은 어느 한쪽도 단일 프롬프트 인젝션 필터에 의존할 수 없기 때문에 계층형 방어 체계를 구축하고 있다.

Google은 에이전트의 행동이 브라우저에 도달하기 전에 이를 점검하는 아키텍처를 설명했다. User Alignment Critic은 제안된 행동이 사용자가 명시한 목표와 일치하는지 평가하도록 설계된 별도 구성 요소다. 이러한 분리는 주 에이전트가 자체적인 위험 해석을 승인하는 일을 방지하는 데 도움이 된다.

Google은 출처 정보, 행동 확인, 모델 학습, 탐지 시스템도 사용한다. 민감한 작업은 명시적인 사용자 승인을 요구할 수 있다. 브라우저는 어떤 정보가 에이전트에 전달되는지 제한하고 자격 증명 주변의 보안 경계를 유지할 수 있다.

Google은 에이전틱 Chrome 설계에서 신뢰할 수 없는 웹 콘텐츠에 노출되는 것이 본질적인 간접 프롬프트 인젝션 위험을 만든다고 인정한다. 이 표현은 중요하다. Google은 이 문제를 지속적인 완화 조치가 필요한 아키텍처상 위협으로 제시한다.

행동 확인은 중요한 단계 이전에 인간의 판단을 복원한다는 점에서 유용하다. 사용자는 예상치 못한 구매, 메시지, 로그인 또는 데이터 전송을 거부할 수 있다. 그러나 빈번한 요청은 일상화되어 쿠키 알림과 권한 대화상자에서 나타나는 것과 같은 피로를 만들 수도 있다.

따라서 확인 절차는 의미 있는 전환에 집중해야 한다. 새로운 도메인으로 데이터를 전송하는 일은 페이지를 스크롤하는 것보다 더 면밀한 검토가 필요하다. 비밀번호 관리자를 여는 일은 공개 헤드라인을 추출하는 것보다 더 큰 위험을 수반한다. 획일적인 승인 모델은 서로 다른 수준의 행동을 동등한 것으로 취급한다.

Amazon은 관리형 브라우저 환경을 둘러싼 정책 적용을 강조한다. Bedrock AgentCore를 사용하는 개발자는 에이전트의 탐색 위치를 제한하는 Chrome 엔터프라이즈 정책을 적용할 수 있다. 이러한 규칙은 에이전트의 프롬프트나 추론과 독립적으로 브라우저 계층에서 작동한다.

이 차이는 중요하다. 모델은 조작될 수 있지만, 결정론적인 네트워크 또는 브라우저 정책은 여전히 금지된 목적지를 차단한다. Amazon의 브라우저 정책 제어를 사용하면 개발자는 에이전트가 작업을 시작하기 전에 허용 및 차단 위치를 정의할 수 있다.

허용 목록은 범위가 좁은 기업 워크플로에서 노출을 크게 줄일 수 있다. 조달 에이전트는 소수의 승인된 공급업체 포털에만 접근하면 될 수 있다. 고객 서비스 에이전트는 지원 플랫폼과 내부 지식 시스템만 필요로 할 수 있다.

이러한 경계는 일반적인 조사 작업에서는 유지하기가 더 어렵다. 제품 비교나 뉴스 추적을 맡은 에이전트에는 광범위한 웹 접근 권한이 필요하다. 작업이 더 개방적일수록 엄격한 목적지 허용 목록의 실용성은 낮아진다.

격리는 또 하나의 방어 계층을 제공한다. 관리형 브라우저 세션은 에이전트 활동을 직원의 일상적인 브라우저 프로필과 분리할 수 있다. 에이전트가 침해되더라도 사용자가 이용할 수 있는 모든 쿠키, 열린 탭, 저장된 자격 증명, 확장 프로그램을 자동으로 물려받아서는 안 된다.

격리는 지시가 악의적인지 여부를 판단하지 않는다. 잘못된 판단 이후 사용 가능한 리소스를 제한할 뿐이다. 이는 컨테이너, 가상 머신, 제한된 서비스 계정의 기반이 되는 실용적인 논리와 같다.

최소 권한 원칙은 이 접근 방식을 도구와 데이터까지 확장한다. 공개 페이지를 읽기만 하면 되는 에이전트에 이메일 발송 권한을 줄 필요는 없다. 거래 초안을 작성하는 에이전트가 이를 승인할 수 있어서는 안 된다. 문서를 읽는 에이전트가 연결된 모든 폴더에 자동으로 접근해서도 안 된다.

따라서 Amazon과 Google의 방어 경로는 하나의 공통 원칙으로 수렴한다. 모델은 계속 오류를 낼 수 있으므로 보안은 모델 외부에 존재해야 한다. 브라우저 정책, ID 경계, 승인 게이트, 로깅, 격리 세션은 탐지가 막지 못한 오류를 억제할 수 있다.

진짜 상충 관계는 기능과 격리의 균형이다

프롬프트 인젝션의 영향을 확실하게 줄이는 모든 방어책은 에이전트 자율성의 일부를 제한한다.

브라우저 에이전트는 서비스 간을 자유롭게 이동하고, 맥락을 기억하며, 여러 단계의 작업을 완료할 수 있을수록 더 유용해진다. 그러나 같은 기능은 공격자가 영향을 미칠 수 있는 결정의 수를 늘린다. 보안상의 상충 관계는 제품의 가치 제안 자체에 내재돼 있다.

여행 준비를 요청받은 에이전트를 생각해 보자. 항공편을 검색하고, 호텔을 비교하며, 캘린더를 확인하고, 로열티 정보를 가져와 예약을 준비할 수 있다. 외부 콘텐츠가 계획을 다른 방향으로 유도하면 에이전트는 개인 정보를 노출하거나 공격자가 통제하는 목적지를 선택할 수 있다.

강하게 제한된 시스템은 에이전트를 읽기 전용 검색으로 한정해 이런 결과를 막을 수 있다. 하지만 더 이상 예약을 완료하지는 못한다. 구매 권한을 추가하면 편의성은 회복되지만, 잘못된 행동이 초래하는 영향도 커진다.

기업 내부에서도 같은 패턴이 적용된다. 영업 에이전트는 계정을 조사하고 아웃리치 초안을 작성하는 데는 큰 위험 없이 활용될 수 있다. 메시지 전송, 고객 기록 업데이트, 내부 문서 첨부 권한을 부여하면 자동화의 가치는 커지지만 실패의 반경도 넓어진다.

이 때문에 프롬프트 인젝션은 기능 보안 문제로 평가해야 한다. 팀은 에이전트가 악의적인 지시를 수용한 뒤 무엇을 할 수 있는지 물어야 한다. 모델의 공격 성공률도 중요하지만, 허용된 결과가 더 중요하다.

읽기 전용 요약기는 결제 시스템에 연결된 에이전트와 다른 위험을 제시한다. 둘 다 오해를 불러일으키는 출력을 만들 수 있다. 하지만 추가 통제 없이 잘못된 해석을 외부 거래로 전환할 수 있는 것은 후자뿐이다.

벤더는 때때로 더 높은 탐지율을 안전성 향상의 증거로 홍보한다. 이런 결과는 가치가 있을 수 있지만, 테스트 세트, 공격자 지식, 모델 버전, 허용된 도구에 따라 달라진다. 적응형 공격은 벤치마크에 포함되지 않은 사례를 겨냥할 수 있다.

오탐도 운영 비용을 만든다. 방어 모델은 인젝션 시도와 유사한 정상 콘텐츠를 거부할 수 있다. 보안 팀은 민감도를 높여 누락을 줄일 수 있지만, 그러면 사용자는 더 많은 차단된 작업과 불필요한 확인 절차를 마주하게 된다.

에이전트 기능은 계속 변하기 때문에 설계 문제에는 고정된 종착점이 없다. 페이지 요약을 상대로 테스트한 보호 장치가 시각적 탐색, 파일 다운로드, 운영체제 대화상자, 새로운 도구 프로토콜과의 상호작용까지 자동으로 포괄하지는 않는다.

브라우저 업데이트는 추가 동작을 도입할 수 있다. 모델 업그레이드는 에이전트가 모호한 지시를 해석하는 방식을 바꿀 수 있다. 연결된 서비스는 브라우저 벤더가 인터페이스를 통제하지 못하는 상황에서도 새로운 작업을 노출할 수 있다. 보안 테스트는 하나의 모델 스냅샷이 아니라 완전한 시스템을 따라가야 한다.

서드파티 확장 프로그램과 통합은 상황을 더욱 복잡하게 만든다. 이들은 에이전트에 보이는 콘텐츠를 확장하거나 새로운 실행 경로를 제공할 수 있다. 기업은 주 브라우저를 신중하게 구성하면서도 광범위한 페이지 접근 권한을 가진 확장 프로그램을 간과할 수 있다.

따라서 회의적인 관점이 필요하다. 계층형 방어는 위험을 줄이지만, “안전한 에이전트”에 대한 공개 주장은 면역성을 뜻하는 것으로 해석해서는 안 된다. 기업은 테스트한 환경, 차단된 작업, 사용자 확인 규칙, 남아 있는 공격 표면을 공개해야 한다.

동시에 모든 AI 브라우저를 범주적으로 안전하지 않다고 선언하는 것도 결정을 지나치게 단순화한다. 위험은 에이전트의 권한, 접근 가능한 데이터, 격리, 작업에 따라 달라진다. 제약된 리서치 어시스턴트는 구매 에이전트가 적합하지 않은 저위험 환경에도 적합할 수 있다.

보안 팀에는 포괄적인 단일 승인 대신 배포 등급이 필요하다. 저위험 에이전트는 격리된 읽기 전용 세션에서 운영할 수 있다. 중간 위험 시스템은 사람이 검토할 수 있도록 작업 초안을 작성할 수 있다. 고위험 워크플로는 모델 외부의 결정론적 승인을 요구해야 한다.

이 구조는 핵심 상충 관계가 사라진 척하지 않고 이를 받아들인다. 사용자는 여전히 자동화의 이점을 얻지만, 자율성은 주변 통제가 모델 실패를 흡수할 수 있을 때에만 높아진다.

프롬프트 인젝션 문제로 압박받는 주체

브라우저 벤더가 헤드라인을 장식하지만, 실질적인 부담의 상당 부분은 엔터프라이즈 ID 및 애플리케이션 팀이 지고 있다.

Google은 브라우저 프로필에 이미 가치 있는 세션이 담긴 사용자를 보호해야 한다. Chrome은 에이전트를 이메일, 캘린더, 문서, 쇼핑 계정, 업무 도구에 연결할 수 있다. 따라서 하나의 인터페이스가 매우 다양한 신뢰 도메인을 노출할 수 있다.

Amazon 고객이 마주하는 책임은 다르다. Bedrock AgentCore는 관리형 구성 요소와 통제를 제공하지만, 에이전트가 접근할 수 있는 목적지, ID, 도구, 데이터는 여전히 개발자가 결정한다. 안전한 서비스가 안전하지 않은 애플리케이션 구성을 지원할 수도 있다.

Microsoft, OpenAI, Anthropic, Perplexity도 같은 경쟁 압력에 직면해 있다. 사용자는 브라우저 에이전트가 더 많은 업무를 처리하기를 기대하는 반면, 보안 연구자들은 새로운 기능을 하나씩 시험한다. 더 폭넓은 자동화를 허용하는 경쟁사 옆에서 제한적인 설계는 덜 유용해 보일 수 있다.

이러한 경쟁 순환은 기업이 거버넌스를 업데이트하는 속도보다 벤더가 권한을 더 빠르게 확대하도록 부추길 수 있다. 새로운 에이전트 기능은 별도 애플리케이션에 필요한 조달 검토를 피해 익숙한 브라우저와 생산성 도구를 통해 도입될 수 있다.

보안 팀은 제품명이 아니라 기능을 기준으로 에이전트 기능을 목록화해야 한다. 핵심 질문은 인증된 세션, 로컬 파일, 연결된 애플리케이션, 메모리, 메시징, 다운로드, 코드 실행에 대한 접근과 관련돼 있다.

애플리케이션 소유자 역시 웹페이지 콘텐츠를 재고해야 한다. 내부 대시보드는 과거에는 주로 사람이 읽도록 설계됐다. 에이전트가 텍스트를 정보이자 잠재적 지시로 소비한다면, 콘텐츠 출처는 애플리케이션 보안의 일부가 된다.

ID 팀은 에이전트가 사람의 자격 증명을 공유할지, 별도의 서비스 ID를 받을지 결정해야 한다. 공유 세션은 편리하지만 책임 추적성을 약화시킨다. 별도 ID는 더 엄격한 권한, 더 명확한 로그, 더 빠른 권한 철회를 지원한다.

개발자에게는 에이전트가 무엇을 보고 왜 행동했는지 설명하는 이벤트 기록이 필요하다. 기존 브라우저 기록은 방문한 페이지를 보여주지만, 에이전트의 작업 뒤에 있는 정확한 콘텐츠, 모델 결정, 도구 호출, 권한 부여를 포착하지 못할 수 있다.

사고 대응팀은 또 다른 어려움에 직면한다. 성공적인 프롬프트 인젝션은 에이전트가 유효한 자격 증명과 정상적인 브라우저 기능을 사용하기 때문에 정상 사용자 활동처럼 보일 수 있다. 탐지는 의도, 순서, 목적지, 데이터 이동을 살펴봐야 한다.

직원에게도 더 명확한 신호가 필요하다. 에이전트가 페이지를 읽는 시점, 다른 서비스로 넘어가는 시점, 비공개 정보에 접근하는 시점, 되돌릴 수 없는 작업을 준비하는 시점을 알아야 한다. 작은 애니메이션 아이콘만으로는 완전한 신뢰 전환을 전달할 수 없다.

엔터프라이즈 구매자는 콘텐츠가 시각적이거나 난독화됐거나 다국어이거나 여러 단계에 걸쳐 분산된 경우 방어 체계가 어떻게 작동하는지 벤더에 물어야 한다. 또한 보안 검사가 주 에이전트와 독립적으로 실행되는지, 모델 변경 후에도 정책을 강제할 수 있는지도 확인해야 한다.

가장 강력한 평가는 조직의 실제 워크플로를 상대로 한 적대적 테스트를 포함한다. 일반적인 벤치마크는 모든 내부 애플리케이션, 데이터 소스, 권한 조합을 재현할 수 없다. 레드 팀은 악성 콘텐츠를 다양하게 바꾸면서 현실적인 목표를 테스트해야 한다.

조달 계약에도 명확한 사고 관련 조항이 필요하다. 구매자는 로그 보존 기간, 취약점 공개, 모델 업데이트 관행, 안전하지 않은 구성에 대한 책임을 이해해야 한다. 프롬프트 인젝션은 벤더 행동과 고객 설계의 경계를 가로지른다.

어떤 기업도 모델 업데이트만으로 이 공동 책임 문제를 해결할 수 없다. 벤더는 강제 가능한 통제를 제공해야 하고, 고객은 이를 특정 작업에 맞춰 구성해야 한다. 양측 모두 통제가 함께 작동한다는 증거가 필요하다.

Amazon, Google, AI 브라우저 벤더에서 다음으로 주목할 점

다음 단계는 프롬프트 인젝션이 제거됐다는 약속이 아니라 격리의 증거로 평가받게 될 것이다.

첫 번째 신호는 벤더가 완전한 브라우저 워크플로를 포괄하는 재현 가능한 평가를 공개하는지 여부다. 테스트에는 숨겨진 페이지 텍스트, 이미지, 탭 간 작업, 저장된 메모리, 연결된 계정, 여러 단계의 의도 조작이 포함돼야 한다. 단일 거부 벤치마크는 지나치게 좁은 관점만 제공한다.

결과는 탐지와 영향을 분리해야 한다. 요약에 영향을 미치는 공격은 데이터를 전송하거나 구매를 완료하는 공격과 다르다. 구매자는 에이전트가 적대적 콘텐츠를 따르는 빈도와 그에 따른 행동을 막는 통제가 무엇인지 모두 알아야 한다.

두 번째 신호는 결정론적 제한의 활용이 더 넓어지는지다. Amazon의 브라우저 정책은 모델 추론과 무관하게 목적지를 차단할 수 있기 때문에 하나의 사례를 제공한다. Google의 행동 검사와 권한 게이트도 사용자 정렬을 중심으로 유사한 역할을 한다.

이러한 통제를 세부 수준에서 더 쉽게 구성할 수 있게 되는지 지켜봐야 한다. 기업에는 목적지, 데이터 민감도, 작업 유형, ID, 업무에 기반한 정책이 필요하다. 브라우저 전체에 적용되는 단일 켜기·끄기 스위치로는 이런 차이를 표현할 수 없다.

세 번째 신호는 벤더가 새로 공개된 공격 체인을 어떻게 처리하는지다. 취약점 유형이 지속되더라도 신속한 패치는 여전히 중요하다. 릴리스 노트는 수정이 탐지, 권한 범위, 격리, 기반 에이전트 아키텍처 중 무엇을 바꾸는지 설명해야 한다.

에이전트의 행동은 비결정적이므로 연구자들은 계속해서 변형 공격을 찾아낼 것이다. 한 문구나 웹페이지 패턴을 막는 패치는 서로 다른 맥락에서 발생하는 의도 충돌을 해결하지 못한다. 지속적인 개선은 신뢰할 수 없는 경로에서 기능을 제거하거나 독립적인 권한 부여를 추가해야 한다.

Google이 보고한 악성 웹 패턴의 증가는 이 작업의 긴급성을 높인다. 회사의 스캔에서는 공격의 정교함이 여전히 제한적이었지만, 활동 증가는 공격자에게 배포된 제품을 시험할 기회를 더 많이 제공한다. 브라우저 에이전트 채택이 확대될수록 성공적인 기법의 가치는 커진다.

Amazon과 Google의 경쟁은 사용자가 어떤 안전성 절충을 받아들이는지도 드러낼 것이다. Google은 개인이 직접 보는 Chrome 안에 확인 절차를 배치할 수 있다. Amazon은 개발자에게 인프라 정책을 제공할 수 있지만, 각 고객은 해당 정책을 얼마나 제한적으로 설정할지 결정해야 한다.

엔터프라이즈 배포를 위한 단기 기준은 단순해야 한다. 에이전트를 격리하고, 별도 ID를 부여하며, 목적지를 제한하고, 도구를 최소화하고, 중요한 작업 전에 승인을 요구해야 한다. 신뢰할 수 없는 콘텐츠와 권한 있는 동작 사이의 모든 전환을 기록해야 한다.

지식 노동자는 가능하다면 민감한 계정을 실험적인 에이전트 세션과 분리해 두어야 한다. 또한 제안된 메시지, 거래, 다운로드, 데이터 전송을 직접 점검해야 한다. 브라우저 업데이트도 중요하지만, 근본적인 해석 문제를 없애지는 못한다.

개발자는 모든 웹페이지, 이메일, 업로드된 문서, 검색해 가져온 노트를 신뢰할 수 없는 입력으로 취급해야 한다. 주력 모델은 결국 그중 일부를 잘못 분류하게 될 것이라고 가정해야 한다. 이후 어떤 일이 일어날지는 해당 모델 바깥의 통제 장치가 결정해야 한다.

완벽한 해결책은 없다는 결론이 불편한 이유는 배포에 관한 질문 자체를 바꾸기 때문이다. 팀은 브라우저 에이전트가 프롬프트 인젝션에 면역인지 묻는 데서 멈춰야 한다. 대신 한 번의 성공적인 인젝션이 중요한 대상에 도달할 수 있는지 물어야 한다.

다음 자율 기능을 활성화하기 전에, 허용된 최악의 행동을 파악하고 그 이점이 그러한 노출을 정당화하는지 판단해야 한다. 답이 불분명하다면 에이전트를 읽기 전용으로 유지하거나 사람의 승인을 요구해야 한다. Amazon과 Google의 경쟁은 더 나은 방어책을 만들어 내겠지만, 책임 있는 도입은 여전히 격리에 달려 있다.