An AI Agent Got Its User Banned From Resy — Keycard, JPMorgan Chase & AAuth

한 줄 핵심

에이전트의 진짜 자율성을 막는 핵심 문제는 모델 성능이 아니라 실행 중 권한·의도·감사 체계를 어떻게 설계하느냐이며, 이를 해결하려면 OAuth식 정적 권한이 아니라 미션·정책·예산·외부 감사 로그를 결합한 런타임 인증이 필요하다.

시간별 요약

1. 0:00
   에이전트가 아직 자율성을 얻지 못하는 이유 에이전트는 도구 호출마다 권한을 다시 판단해야 하지만, 현실의 시스템은 거친 권한 단위와 변하는 환경 때문에 이를 안정적으로 처리하지 못한다. 성능이 좋아졌어도 모델이 언제 무엇을 해야 하는지에 대한 런타임 판단이 없으면 실제 자율성은 생기지 않는다.
2. 3:19
   에이전트에 맞지 않는 OAuth OAuth는 웹사이트 간 연동과 브라우저 리다이렉트, 사전 등록을 전제로 설계되어 에이전트의 미리 알 수 없는 작업 흐름과 맞지 않는다. 기존 scope를 그대로 에이전트에 매핑하면 너무 거칠어서 실제 위험과 의도를 반영하지 못한다.
3. 4:33
   신입 개발자처럼 에이전트 온보딩하기 성숙한 조직은 에이전트를 처음부터 전권으로 두지 않고, 신입 개발자처럼 능력을 단계적으로 부여한다. 에이전트의 안전성은 말뿐인 자기 진술이 아니라 샌드박스 위치, 주변 환경, 추가 맥락 같은 외부 신호로 판단해야 한다.
4. 5:40
   은행이 이미 알고 있는 거래 권한 부여 은행은 인간 자체를 승인하던 방식에서 오래전에 거래 단위로 권한을 판단하는 방식으로 이동했다. 체크의 memo field처럼 의도를 함께 기록하고, 동일한 결제라도 맥락에 따라 중복 결제인지 정상 결제인지 구분해야 한다.
5. 9:05
   에이전트에 미션 부여하기 미션은 사용자나 조직이 에이전트에게 맡기는 목표이며, 에이전트는 그 목표를 바탕으로 세부 결정을 내려야 한다. 미션 식별자가 전체 흐름을 관통해야 감사와 추적이 가능하고, 작업자 에이전트와 감독자 에이전트를 분리해야 위험한 요청을 거를 수 있다.
6. 16:45
   에이전틱 커머스와 "내 에이전트 알기" 커머스에서는 고객을 아는 것처럼 에이전트도 알아야 하며, 사용자·운영자·처리자의 의도를 함께 묶어 이해해야 한다. 그래야 결제 승인과 규제 대응을 더 정교하게 처리하고, 신뢰할 수 있는 에이전트만 사이트에 접근하게 할 수 있다.
7. 17:54
   웹은 에이전트를 위해 만들어지지 않았다 웹은 원래 미등록 클라이언트와 스팸, 남용을 막기 위해 CAPTCHA와 IP 차단 같은 방식으로 설계되어 에이전트 친화적이지 않다. 에이전트가 웹에 등장한 지금은 방문 주체를 신뢰할 수 있게 식별하고, 서비스가 누구를 받아들일지 스스로 결정할 수 있어야 한다.
8. 19:56
   개방형 프로토콜과 폐쇄형 생태계 에이전트가 여러 서비스와 섞여 동작하려면 특정 벤더가 아닌 상호운용 가능한 프로토콜이 필요하다. 감독 권한과 실행 권한을 분리하지 않으면, 에이전트가 무엇을 할지 결국 벤더가 정하는 구조가 되어 확장성과 통제권이 함께 무너진다.
9. 25:02
   Resy에서 차단된 에이전트 의도는 좋았지만 에이전트가 너무 공격적으로 200 API calls an hour를 날리며 Resy 계정을 차단당한 사례는, 선의만으로는 충분하지 않음을 보여준다. 에이전트에는 시간 제한과 자원 한도를 함께 둔 budget이 필요하고, 차단 대신 소비량을 학습시키는 피드백이 중요하다.
10. 27:00
    두뇌와 손 분리하기 모델을 두뇌로, 도구와 자격 증명을 손으로 분리하면 에이전트가 직접 API key를 쥐지 않아도 된다. 샌드박스와 egress proxy 바깥의 정책 집행 지점을 두면 권한 경계를 강하게 만들 수 있고, 상황에 따라 도구를 동적으로 빼거나 다시 넣을 수도 있다.
11. 31:29
    지금 생산용 에이전트에 통하는 것 실전에서는 인증보다 동적 권한 부여, 입력·출력 검증, 적절한 human-in-the-loop 타이밍이 더 중요해지고 있다. 권한을 줄일수록 에이전트의 오류율과 공격면이 줄고, 보안팀과 애플리케이션팀이 같은 언어로 이야기할 수 있게 된다.
12. 33:34
    안전한 소프트웨어 공장 agentbaseline.org의 reference architecture는 human-driven, workflow-driven, agentic-driven의 세 단계 공장을 제시한다. 여기서 runtime authorization은 누가 언제 개입할지, 어떤 에이전트가 어떤 작업을 이어받을지, production system에 어떻게 안전하게 접근할지를 결정하는 핵심 구성요소다.
13. 35:11
    로보틱스에서 배우는 교훈 로봇이 팔을 움직일 때처럼 에이전트의 권한 결정도 의도뿐 아니라 주변 객체, 온도, 시간대, 시스템 상태 같은 다양한 센서 신호를 함께 봐야 한다. 단일 이분법 승인보다 맥락이 풍부한 판단이 있어야 진짜 운영 환경에서 짧은 수명의 권한 결정을 내릴 수 있다.
14. 37:32
    감사 로그는 에이전트 바깥에 있어야 한다 감사 로그와 집행 지점은 에이전트가 건드릴 수 없는 바깥에 있어야 조작과 은폐를 막을 수 있다. 결국 핵심은 누가 어떤 목적을 위해 에이전트를 썼는지 남기는 것이며, 책임은 에이전트가 아니라 그것을 고용한 사람이나 조직에 귀속된다.
15. 39:01
    P(doom)은 실제인가 패널은 극단적 종말론보다 책임 있는 통제, 빠른 실험, 그리고 실패에서 학습하는 사회적 피드백이 현실적인 대응이라고 본다. 에이전트가 세상을 끝낼 확률보다, 잘못된 사용을 조기에 발견하고 책임 소재를 분명히 하는 체계를 만드는 일이 더 중요하다.

실무 인사이트

• 에이전트 권한 설계는 "누가 로그인했는가"가 아니라 "지금 이 미션에서 무엇을 해도 되는가"를 기준으로 다시 짜야 한다.
• 실무에서는 정책을 한 번에 완벽하게 쓰려 하지 말고, 절대 금지·인간 승인 필요·예산 한도라는 3층 구조로 먼저 나누는 것이 효과적이다.
• 에이전트 사고 대응은 모델 디버깅보다 책임 추적 문제에 가깝기 때문에, 감사 로그·미션 ID·외부 집행 지점을 초기에 넣어야 한다.