AI 에이전트 차단, 은행·쇼핑몰이 막은 건 비밀번호 대리 로그인

Q: 도구에 readOnlyHint 를 달면 읽기 전용이 보장되나?

아니오. 주석은 힌트이고 기본값도 readOnlyHint: false 다. 쓰기를 막는 일은 scope 별 도구 목록과 서버의 권한 검사가 맡아야 한다.

미국 은행과 대형 쇼핑몰이 2026년 9~10월 잇따라 막은 것은 AI 에이전트 전체가 아니다. 고객 비밀번호를 넘겨받아 사람처럼 로그인한 뒤 결제하거나 돈을 옮기는 방식을 막았다. 같은 은행들이 Plaid 같은 승인된 연결이나 자체 MCP 서버로 잔고를 보는 길은 열어 두거나 열겠다고 했지만, 송금은 어느 경로로도 허용하지 않았다. 그래서 에이전트를 만드는 쪽은 '대신 로그인' 을 버리고 서비스가 정한 문으로 들어가야 하고, 받는 쪽은 조회와 이동을 서로 다른 권한으로 나눠야 한다.

01 Muse 출시 6주 만에 쇼핑몰과 은행이 차례로 문을 닫았다

메타가 개인용 에이전트 Muse 를 미국에 내놓은 날은 2026년 9월 8일이다. Muse 는 클라우드 가상 머신 안에 자체 브라우저를 띄워 쇼핑과 예약을 대신 처리하고, 결제나 메일 발송 앞에서는 사용자 확인을 받는다. 동작 구조는 앞서 쓴 메타 Muse 와 OpenAI dots, 창을 닫아도 일하는 에이전트 에 정리해 두었다.

첫 충돌은 출시 12일 만에 Amazon 에서 났다. 9월 20일부터 Muse 에 Amazon 구매를 맡기면 안내 창이 뜨는데, 허가받지 않은 AI 에이전트의 접근은 고객이 동의한 이용 약관 위반이라는 내용이다. Amazon 은 그 전에 Muse 의 대상에서 자사 사이트를 빼 달라고 메타에 요청했다가 거절당했다.

은행은 10월 중순에 한꺼번에 입장을 냈다. JP모건 CEO 는 10월 13일 실적 발표에서 외부 에이전트를 아무나 들이지 않겠다고 했다. Schwab CEO 는 16일 Bloomberg TV 인터뷰에서 Muse 를 포함한 무단 에이전트의 이체 시도를 실제로 막고 있다고 밝혔고, 같은 날 Citi 는 FT 에 제3자 에이전트의 계좌 로그인도, 직접 거래도 받지 않겠다고 했다. Bank of America 는 AI 가 실행한 거래의 책임 절차를 만드는 동안 에이전트의 예금 접근을 묶어 두었다.

곳	막은 것	열어 둔 길
Amazon	Muse 의 구매(9월 20일부터)	없음
JP모건	고객 로그인 정보로 들어온 에이전트의 송금·납부	Plaid 등 승인된 연결로 일부 계좌 조회
Citi	외부 에이전트의 로그인과 직접 거래	보도에 언급 없음
Schwab	승인받지 않은 에이전트의 이체	자체 MCP 서버로 조회·리서치(예정), 자체 비서 Charley
Bank of America	책임 절차 마련 전까지 예금 접근	사람 승인을 넣는 방식으로 업체와 협의
Yelp	유료 데이터 라이선스 밖 에이전트	라이선스에 참여한 에이전트
Delta	에이전트의 항공권 대리 예약	보도에 언급 없음

GeekNews 가 정리한 해외 보도를 보면 Cars.com 과 Amtrak 에서도 전에 되던 작업이 막혔다. Amazon 에서는 xAI Grok·OpenAI Dots·Instinct 사용자도 차단을 겪었다는 보고가 있고, 메타와 제휴한 Walmart 에서조차 Muse 결제가 걸린다는 이용자 글이 올라왔다.

Amazon 이 소송 대신 약관을 앞세운 데는 앞선 다툼의 결과가 깔려 있다. Amazon 은 Perplexity 의 브라우저 에이전트 Comet 을 상대로 2026년 3월 예비 금지명령을 얻었지만, 미 연방 제9순회 항소법원이 8월 4일 이를 뒤집었다. 반해킹법으로 보면 Amazon 컴퓨터에 들어온 주체는 AI 회사가 아니라 사용자라는 판단이었다. 다만 법원은 Amazon 이 이용 약관으로 접근을 규율하는 길까지 닫지는 않았고, Muse 앞에 뜬 안내 창이 바로 그 길이다.

02 은행과 쇼핑몰은 왜 에이전트를 막나

막는 쪽이 내놓은 이유는 책임, 식별, 수익 세 갈래로 나뉜다. 겉으로는 보안을 말하지만 셋이 서로 얽혀 있다.

사고가 나면 책임질 주체가 정해져 있지 않다

은행이 가장 먼저 꺼낸 말은 책임이다. Schwab CEO 는 "우리도 고객도 통제할 수 없는데, 일이 틀어지면 누가 책임지나"라고 되물었다. 미국에서는 에이전트가 실수했을 때 누가 물어낼지를 아직 의회가 논의하는 단계다. JP모건 CFO 는 고객 로그인 정보를 받아 돌아가는 서비스에 은행이 오래전부터 반대해 왔다고 했는데, 자율 에이전트에도 같은 잣대를 댄 셈이다. Bank of America CEO 는 출금에는 사람의 승인이 있어야 한다고 선을 그었다.

로그인한 고객 세션 안의 에이전트는 가려내기 어렵다

Amazon 의 불만은 식별에 몰려 있다. Muse 가 사이트를 돌 때 에이전트라고 밝히지 않고, 고객 자격 증명을 받아 저장하는 것으로 보인다는 것이다. 메타는 Muse 가 비밀번호나 결제 수단을 볼 수 없다고 반박했다. 한쪽은 저장을, 다른 쪽은 열람을 말하니 두 주장이 정면으로 부딪히지는 않는다.

식별이 어려운 데는 구조적인 까닭이 있다. robots.txt 는 크롤러가 스스로 밝힌 이름에 규칙을 거는 자발적 약속인데, Muse 는 메타의 크롤러 목록에 이름이 없고 로그인한 고객의 세션 안에서 움직인다. 사이트 눈에는 평범한 고객처럼 보이니 봇 방어가 거칠게 반응하기도 한다. Google 이 Muse 를 쓰는 일부 계정을 '의심스러운 활동' 으로 막았다는 보고가 그런 예이고, 차단이 세질수록 사람 사용자도 사람임을 증명하는 절차를 더 거치게 된다는 걱정이 GeekNews 토론에서 나왔다.

예금과 광고 수입이 빠져나간다

보안만으로는 설명이 다 되지 않는다. 은행은 금리가 낮은 예금을 대출 재원으로 쓰는데, 에이전트가 상품을 비교해 놀고 있는 돈을 더 나은 곳으로 옮기기 시작하면 조달 비용이 오른다. FT 는 Muse 출시 뒤 이 문제가 은행권의 관심사로 떠올랐다고 전했다. Amazon 에는 에이전트가 광고와 추천 상품을 건너뛴다는 문제가, Yelp 에는 유료 데이터 라이선스 모델이 걸려 있다.

반면 지금 당장의 규모는 작다. Schwab CEO 가 받는 주간 보고서에서 큰 에이전트들이 막히는 건수는 매주 수십 건 수준이다. Wells Fargo CEO 는 고객이 곧 AI 에 금융 통제권을 넓게 넘길 것이라는 전망이 부풀려졌다고 평했다.

03 은행이 그은 선은 '조회'와 '이동' 사이다

차단 소식만 보면 은행이 AI 를 거부하는 것처럼 읽힌다. 실제로 갈린 것은 접근 경로다. 누가 자격 증명을 쥐고 있는지, 누가 할 수 있는 동작의 목록을 정하는지가 기준이 됐다.

경로	에이전트가 쥔 것	은행의 판단
비밀번호 공유 + 브라우저 자동화	고객 아이디·비밀번호, 화면 조작	차단(Schwab·JP모건·Citi)
오픈뱅킹 중계(Plaid 등)	승인된 연결의 읽기 권한	일부 조회 허용(JP모건)
은행이 운영하는 MCP 서버	은행 인증을 거친 도구 목록	조회·리서치 허용 예정, 송금 불가(Schwab)
은행 자체 비서	은행 내부 시스템	조회와 몇 가지 계정 관리 동작(Schwab Charley)

Schwab 의 구상은 이렇다. 고객이 고른 LLM 이 Schwab 이 운영하는 MCP 서버에 붙어 잔고를 보고 리서치하는 것은 허용하되, 인증 화면과 허용 동작은 Schwab 이 정한다. 돈을 옮기는 도구는 내주지 않는다. 매매는 보도마다 다르다. TNW 는 조회와 리서치만 언급했고, BERI 는 Claude 로 시작한 일부 트레이더 대상 매매 시범이 있다고 전했다. 10월 18일까지 나온 보도에 엔드포인트나 도구 목록은 없으니, 당장 붙어 볼 수 있는 단계는 아니다.

9월 30일 발표한 Charley 는 10월부터 미국 개인 고객에게 단계적으로 열린다. BERI 에 따르면 잔고·보유 종목·명세서·세금 서류를 읽고, 수익자 추가나 연락처 변경, 배당 재투자 신청, 알림 관리 정도를 처리한다. 은행이 직접 책임지는 범위 안에서만 '쓰기' 를 허용한 모양새다.

04 읽기 전용 MCP 는 도구 목록과 토큰 범위로 만든다

MCP(Model Context Protocol, LLM 앱이 외부 도구와 데이터를 부르는 개방 프로토콜)의 2026-07-28 판 명세에는 Schwab 식 설계를 받칠 장치가 이미 들어 있다. 비밀번호 공유와 갈리는 지점은 하나다. 사용자가 은행 화면에서 직접 로그인하고, 에이전트에게는 범위가 정해진 토큰만 건너간다.

text

1. 에이전트 → MCP 서버: 토큰 없이 호출
2. MCP 서버 → 401, 헤더에 보호 자원 메타데이터 주소와 필요한 scope(예: accounts:read)
3. 에이전트 → 은행 인가 서버: 사용자를 은행 로그인·동의 화면으로 보냄(PKCE, resource=MCP 서버 주소)
4. 인가 서버 → 에이전트: accounts:read 만 담긴, 이 MCP 서버 전용 액세스 토큰
5. 에이전트 → tools/list: 토큰 범위에 맞는 조회 도구만 돌아옴
6. 범위 밖 작업 → 403 insufficient_scope 와 필요한 scope → 다시 인가(step-up)

명세에서 이 흐름을 받치는 규칙은 넷이다.

MCP 서버는 OAuth 2.1 자원 서버로서, 클라이언트가 RFC 8707 resource 매개변수로 자기에게 묶어 발급받은 토큰만 받고 그 토큰을 뒤쪽 API 로 넘기지 않는다.
tools/list 응답은 요청에 실린 권한에 따라 달라도 되며, 명세는 부여된 scope 가 허용하는 도구만 돌려주는 경우를 직접 예로 든다.
실행 중 권한이 모자라면 서버는 403 과 함께 WWW-Authenticate 헤더에 error="insufficient_scope" 와 필요한 scope 를 싣고, 사용자를 대리하는 클라이언트는 권한을 넓히는 재인가를 시도한다.
서버는 입력 검증·접근 통제·호출 횟수 제한을 반드시 하고, 클라이언트에는 민감한 작업 전 사용자 확인과 감사용 호출 기록이 권장된다.

도구 정의에는 readOnlyHint 같은 주석(annotations)을 달 수 있다. 다만 이름 그대로 힌트일 뿐이다. 기본값은 readOnlyHint: false, destructiveHint: true 이고, 명세는 믿을 수 없는 서버가 준 주석으로 도구 사용을 판단하지 말라고 적는다. 그러니 읽기 전용은 주석이 아니라 서버가 보장해야 한다. 가장 단단한 방법은 조회 scope 로 들어온 요청에 쓰기 도구를 아예 목록에 올리지 않는 것이다. 없는 도구는 부를 수 없다.

json

{
  "tools": [
    {
      "name": "get_balances",
      "description": "연결된 계좌의 잔고를 조회한다",
      "inputSchema": { "type": "object", "additionalProperties": false },
      "annotations": { "readOnlyHint": true, "openWorldHint": false }
    },
    {
      "name": "list_transactions",
      "description": "기간을 정해 거래 내역을 조회한다",
      "inputSchema": {
        "type": "object",
        "properties": { "from": { "type": "string" }, "to": { "type": "string" } },
        "required": ["from", "to"]
      },
      "annotations": { "readOnlyHint": true, "openWorldHint": false }
    }
  ]
}

이체 같은 쓰기 도구를 언젠가 열더라도 조회 scope 에 섞지 않는 편이 낫다. 별도 scope 와 재인가를 요구하고, 최종 승인은 에이전트 대화창이 아니라 은행 앱 같은 자기 채널에서 받으면 Bank of America 가 말한 '사람 승인' 을 구조로 옮길 수 있다. 이 대목은 명세가 정한 절차가 아니라 위 장치를 조합한 설계 제안이다.

05 에이전트를 만드는 쪽은 서명으로 이름을 밝힌다

Amazon 이 문제 삼은 '자신을 밝히지 않는다' 는 대목에는 이미 표준 쪽 답이 있다. Web Bot Auth 는 봇이나 에이전트가 HTTP 메시지 서명으로 신원을 증명하는 방식이고, Cloudflare 가 검증된 봇과 에이전트를 가리는 수단으로 쓴다. 키 디렉터리와 서명 프로토콜, 두 IETF 초안이 바탕이다.

절차는 단순하다. 운영자가 Ed25519 키를 만들고, 공개 키를 JWK 집합으로 바꿔 /.well-known/http-message-signatures-directory 에 HTTPS 로 올린다. 그다음 요청마다 아래 세 헤더를 붙인다.

text

Signature-Agent: "https://agent.example.com"
Signature-Input: sig1=("@authority" "signature-agent");created=1760000000;expires=1760000060;keyid="<공개 키 JWK 지문>";alg="ed25519";tag="web-bot-auth"
Signature: sig1=:<서명 값>:

tag 는 web-bot-auth, keyid 는 공개 키의 JWK 지문이다. expires 는 재전송 위험을 줄이려고 짧게 잡는데, Cloudflare 문서는 1분이면 대개 충분하다고 본다. 서명 대상에는 적어도 목적지 도메인인 @authority 가 들어가야 하고, 형식은 Cloudflare 의 crawltest.com 테스트 엔드포인트로 확인할 수 있다.

Cloudflare 는 서명한 에이전트를 검증된 봇으로 다루고, 2026년 7월 1일부터는 누가 조작하는지를 Direct 와 Intermediary 라는 표시로 나눈다. Muse 처럼 운영사는 하나인데 동작마다 시작한 최종 사용자가 다른 서비스가 Intermediary 다. 이 경우 책임질 최종 사용자를 밝히려고 Forwarded 헤더(RFC 7239)를 시험하는 중이다. 사이트 운영자는 모든 요금제에서 AI 봇 정책을 정할 수 있고, Search·Agent·Training 묶음 설정이 준비돼 있다.

그래도 서명이 푸는 문제는 좁다. 서명은 '누구인지' 를 증명할 뿐, '들어와도 되는지' 는 여전히 사이트가 정한다. 고객 비밀번호를 쥐는 문제도 서명으로는 풀리지 않는데, 은행이 막은 대목이 바로 그쪽이다.

06 국내 금융은 이미 API 와 정해진 대리 쪽으로 가 있다

한국 개발자에게 이번 일은 낯선 규칙이 아니다. 금융 마이데이터는 2022년 1월 5일부터 사업자의 스크래핑을 전면 금지하고 API 로만 서비스하게 했다. 미국 은행이 지금 그은 선, 승인된 조회는 열고 비밀번호 대리 로그인은 막는 선과 방향이 같다.

에이전트 대리도 제도 안으로 들어오는 중이다. 금융위원회는 2026년 8월 25일 마이데이터 발전방안에서 'My AI 에이전트' 를 내놓았다. AI 가 대신 행사할 권리 후보로는 금리인하요구권, 채무조정요구권, 보이스피싱 피해구제 신청, 정책자금·대환대출 신청, 숨은 보험금 탐색·청구가 올라 있다. 사업자의 설명·기록 의무와 AI 에이전트 보안성 검증도 함께 신설하고, 신용정보법 개정 전에는 혁신금융서비스 지정으로 시범 운영을 검토한다.

선례도 있다. 2025년 12월 18개 마이데이터 사업자의 금리인하요구권 대리실행 서비스가 혁신금융서비스로 지정됐다. 2026년 7월까지 약 407만 명이 신청했고, 이 가운데 약 16만 2천 명이 받은 금리 인하 혜택은 모두 1,003억 원이다. 아무 일이나 맡기는 범용 에이전트가 아니라, 정해진 권리를 정해진 통로로 대리하는 모델이다.

금융 밖도 같은 쪽으로 움직인다. 개인정보보호위원회는 협의 없는 스크래핑을 정보를 가진 쪽과 미리 맞춘 전송 방식으로 바꾸게 하는 제도를 2026년 8월 20일 공공기관부터 시작했고, 민간 대형 사업자에는 2027년 2월 20일부터 적용한다.

07 대리 로그인부터 걷어 내고, 조회와 쓰기를 나눈다

브라우저 자동화로 결제·예약 에이전트를 만든다면 사용자 비밀번호를 받아 저장하는 설계부터 걷어 내는 편이 낫다. 미국 대형 사이트에서는 이미 막히고 있고, 국내도 협의 없는 스크래핑을 줄이는 쪽으로 제도가 움직인다. 공식 API 나 제휴가 있는 곳은 그 경로로 붙고, 직접 요청을 보내야 하는 곳에서는 서명으로 이름을 밝히며, 결제 직전에는 사람 확인을 둔다.

금융·커머스 서비스의 백엔드를 맡고 있다면 에이전트를 막을지보다 어떤 문을 열지를 먼저 정하는 게 맞다. 조회 전용 MCP 서버나 API 를 따로 두고 쓰기는 별도 scope·재인가·자체 채널 승인으로 나누면, 전면 차단과 전면 허용 사이에 선택지가 생긴다. My AI 에이전트가 제도화되면 설명·기록 의무가 붙으니 에이전트 호출 로그를 사람 사용자 로그와 구분해 남겨 두는 작업은 미리 해 둘 만하다.

에이전트도 금융·커머스 서비스도 만들지 않는다면 지금 바꿀 것은 없다. 다만 봇 방어를 운영 중이라면 에이전트를 사람으로, 사람을 봇으로 잘못 보는 경우가 함께 늘 수 있으니 Cloudflare 의 Agent 묶음을 허용할지 정해 두면 된다.

확인하고 바꿀 것을 순서대로 적으면 이렇다.

에이전트가 사용자 자격 증명을 저장하거나 화면 자동화로 로그인하는 경로가 있는지 코드에서 찾는다.
연동 대상의 공식 API·MCP·제휴 경로를 먼저 확인하고, 이용 약관의 자동화·에이전트 조항을 읽는다.
직접 요청을 보내는 에이전트라면 Web Bot Auth 서명을 붙이고 테스트 엔드포인트로 형식을 검사한다.
MCP 서버를 운영한다면 scope 별로 tools/list 를 나누고, 주석이 아니라 서버의 권한 검사로 쓰기를 막는다.
Schwab MCP 서버의 명세 공개, 금융위의 신용정보법 개정안, Amazon 과 Perplexity 소송의 다음 단계를 지켜본다.

08 자주 묻는 질문

Schwab 의 MCP 서버에 지금 연결해 볼 수 있나?

아니오. 10월 18일까지 나온 보도에는 엔드포인트나 도구 목록이 없고, 조회·리서치를 열겠다는 계획과 일부 트레이더 매매 시범 소식만 있다.

도구에 readOnlyHint 를 달면 읽기 전용이 보장되나?

아니오. 주석은 힌트이고 기본값도 readOnlyHint: false 다. 쓰기를 막는 일은 scope 별 도구 목록과 서버의 권한 검사가 맡아야 한다.

Web Bot Auth 로 서명하면 Amazon 같은 곳이 들여보내 주나?

보장되지 않는다. 서명은 신원을 증명할 뿐이고, 들일지는 사이트의 정책과 약관이 정한다.

메타는 Muse 가 비밀번호를 본다고 인정했나?

아니오. 메타는 Muse 가 비밀번호나 결제 수단을 볼 수 없다고 했고, Amazon 은 자격 증명을 받아 저장하는 것으로 보인다고 했다. 두 말은 각각 열람과 저장을 가리킨다.