메타 Muse 아마존 차단, AI 에이전트는 이름을 밝혀야 한다

9월 20일 밤에서 21일 사이, 아마존이 메타의 AI 에이전트 Muse 를 차단했다. Muse 에게 아마존에서 뭘 사오라고 시키면 이제 팝업이 뜬다. "승인되지 않은 AI 에이전트의 계속된 접근은 고객이 동의한 아마존 이용약관을 위반합니다." Muse 는 9월 8일에 나왔고 열흘 만에 미국 앱스토어 무료 앱 1위에 올랐다. 그 기세가 2주 만에 최대 쇼핑몰에서 막힌 것이다. 이 글은 아마존이 내건 이유를 뜯어보고, 에이전트를 만드는 쪽에서 무엇을 해야 하는지 정리한다. 아마존이 막은 것은 AI 에이전트가 아니라, 자기 이름을 밝히지 않는 에이전트다.

아마존이 내건 이유는 세 가지였다

첫째, 메타가 Muse 로 아마존 스토어에 접근하겠다고 알리지도, 승인을 받지도 않았다. 둘째, Muse 는 브라우징하는 동안 자신이 AI 에이전트라고 밝히지 않는다. 셋째, 고객 계정에 접근하면서 주문 내역을 읽고 "자격증명을 캡처해 저장하는 것으로 보인다".

메타는 세 번째를 정면으로 반박했다. Muse 모델은 사용자의 비밀번호나 결제 수단을 볼 수 없고, 자격증명은 별도의 보안 저장소에 들어가 모델에 노출되지 않은 채 인증에만 쓰인다는 설명이다. 구매 같은 민감한 행동은 사용자 승인을 거치고, Sentinel 이라는 별도 에이전트가 행동을 검토한다고도 했다.

기술적으로 둘 다 맞는 말일 수 있다. 다툼의 핵심은 두 번째다. Muse 는 공개 API 가 없는 서비스에서는 사람이 하듯 브라우저를 직접 조작한다. 서버 입장에서 사람과 구분할 방법이 없다는 뜻이다.

아마존 자신의 에이전트는 이름을 밝힌다

이 대목에서 아마존을 이중잣대로 몰기 쉽다. 아마존도 쇼핑 에이전트를 만든다. 5월에 내놓은 Alexa for Shopping 이 상품을 조사하고 추천하고, Buy for Me 는 다른 브랜드 사이트에 들어가 대신 구매까지 한다.

그런데 Buy for Me 는 방문한 사이트에 자신이 아마존의 에이전트임을 밝히고, 사이트가 거부할 수 있는 통로를 열어둔다. 아마존이 내건 원칙도 그 문장 그대로다. "고객을 대신해 다른 사업자에게서 구매하는 서드파티 애플리케이션은 공개적으로 동작해야 하고 서비스 제공자의 결정을 존중해야 한다."

기준 자체는 일관된다. 밝히고 들어오면 협상이 되고, 숨기고 들어오면 차단이다.

보안이라는 명분 뒤에 680억 달러가 있다

여기서 아마존 편만 들면 글이 절반만 맞는다. 아마존의 작년 광고 매출은 680억 달러다. 이 돈은 고객이 무엇을 검색하고 어떤 추천을 보는지, 그 여정을 아마존이 쥐고 있기 때문에 들어온다. 에이전트가 대신 검색하고 대신 고르면 광고를 볼 사람이 사라진다. 차단의 동기가 보안만은 아니라고 보는 게 상식적이다.

전력도 있다. 아마존은 퍼플렉시티의 Comet 브라우저를 법정까지 끌고 갔고, 구글과 오픈AI 의 쇼핑 에이전트도 막았다. 그런데 법정 싸움은 잘 풀리지 않았다. 3월에 받아낸 가처분은 8월 4일 제9연방항소법원에서 뒤집혔고, 9월 10일에는 재심 요청마저 기각됐다. 법으로 막는 길이 좁아진 직후에 기술적 차단이 나왔다는 순서를 그냥 지나치기는 어렵다.

그래서 아마존의 동기는 의심할 만하다. 다만 동기가 불순하다는 것과 요구가 틀렸다는 것은 다른 얘기다.

자격증명을 쥔 에이전트는 표적이 된다

같은 주에 Muse 에서 취약점이 하나 터졌다. 보안 연구자 패트릭 워들이 공개한 내용인데, macOS 앱에 문서화되지 않은 설정 하나가 있었다. 받아쓰기 음성을 어디로 보낼지 지정하는 값인데, 권한 없는 로컬 프로세스가 이 값을 사용자에게 묻지 않고 바꿀 수 있었다. 공격자 서버로 음성과 인증 토큰이 흘러가게 만들 수 있다는 뜻이다. 메타는 핫픽스로 이 설정을 제품 빌드에서 아예 들어냈고, 원격 공격이 아니라 로컬 권한 상승이라고 선을 그었다.

메타 말이 맞다. 이 공격은 이미 악성코드가 돌고 있는 맥에서만 성립한다. 하지만 진짜 문제는 심각도 등급이 아니다. 에이전트 하나를 잡으면 메일과 메신저와 일정과 쇼핑 계정이 한꺼번에 딸려온다는 구조다. 사람의 자격증명을 그대로 물려받아 사람처럼 행동하는 프로그램은, 그 자체로 값이 비싼 표적이다.

아마존이 "자격증명을 저장하는 것으로 보인다"고 쓴 문장은 이 지점을 가리킨다. 사이트 입장에서는 지금 로그인한 것이 사람인지, 사람의 토큰을 들고 있는 프로그램인지, 그 프로그램을 탈취한 제3자인지 구분할 방법이 없다.

에이전트를 만든다면 서명부터 붙여라

해법의 표준은 이미 나와 있다. Web Bot Auth 는 클라우드플레어의 티보 뫼니에와 구글의 산도르 메이저가 IETF 에 올린 초안으로, RFC 9421 HTTP 메시지 서명을 그대로 쓴다. 에이전트가 개인키로 요청에 서명하고 Signature-Agent 헤더로 공개키 위치를 알려주면, 서버는 키 디렉터리에서 키를 받아 검증한다. IP 허용목록이나 공용 API 키를 돌려쓰는 방식보다 훨씬 확장성이 있다.

서명이 만능은 아니다. 이 방식을 다룬 분석 중에 정확한 문장이 있다. "서명은 누구인지를 알려준다. 무엇을 하려는지는 알려주지 않는다." 서명된 에이전트도 카탈로그를 과도하게 긁을 수 있고, 악의적인 사용자가 몰 수도 있고, 훔친 자격증명으로 돌 수도 있다. 신원은 신뢰 판단의 입력값이지 판단 자체가 아니다.

그래도 순서는 분명하다. 신원 없이는 정책을 걸 자리조차 없다. 사이트가 "이 에이전트는 초당 2회까지, 구매는 불가" 같은 규칙을 만들려면 먼저 그게 누구인지 알아야 한다. 사람인 척하는 에이전트는 사이트에 선택지를 주지 않고, 선택지가 없으면 남는 답은 전면 차단뿐이다. 아마존이 지금 한 일이 정확히 그것이다.

에이전트를 만드는 쪽에 주는 실무적 결론은 짧다. 사용자 에이전트 문자열을 크롬으로 위장하지 말고, 요청에 서명하고, 막히면 우회하지 말고 협상하라. 사람인 척 브라우징하는 시대는 끝나가는 중이다.

참고 자료

• Amazon shows Meta's Muse AI shopping agent the door — The Register (2026-09-21)
• Amazon blocks Meta's Muse AI assistant in new standoff over agentic shopping — GeekWire
• Meta's Muse AI assistant has a zero-day that can turn it into a Mac backdoor — Malwarebytes
• draft-meunier-web-bot-auth-architecture-05 — IETF
• Web Bot Auth: signed agents solve identity, not intent — Prosopo