Resy에서 사용자를 차단당하게 한 AI 에이전트 — Keycard·JPMorgan Chase·AAuth가 말하는 자율성의 경계

URL: https://www.youtube.com/watch?v=IavxrdVnwXM
날짜: 2026-10-18
채널: aiDotEngineer

메타데이터

• 원문 제목: An AI Agent Got Its User Banned From Resy — Keycard, JPMorgan Chase & AAuth
• 영상 게시일: 2026-10-17
• 영상 길이: 43분 25초
• 영상 ID: IavxrdVnwXM
• 행사: AI Engineer New York 2026, 뉴욕 셰라톤 타임스스퀘어 호텔
• 진행: Allie Howe, Keycard (자동 자막에는 Ellie로 표기)
• 패널: Ian Livingstone, Keycard CEO 겸 공동창업자 · Michael Davis, JPMorgan Chase 글로벌 최고 보안 아키텍트 · Dick Hardt, OAuth 공동 창시자이자 AAuth 제작자
• 주요 개념: runtime authorization, intent-based authorization, mission, OAuth scopes, agentic commerce, budgets, brain/hands, sandbox, outbound proxy, audit log

📌 핵심 질문: 모델이 똑똑해졌는데도 기업은 왜 에이전트에게 자율성을 맡기지 못하는가?

에이전트에게 사용자의 계정과 도구를 통째로 맡기는 대신, 업무의 의도·위임된 임무·실행 환경을 함께 검증해 매 행동의 허용 범위를 결정해야 한다. 의도만 읽는 모델이 아니라 자격 증명과 실행 도구를 분리한 결정론적 통제 계층, 사용량 예산, 환경 신호, 에이전트 바깥의 감사 기록이 함께 있어야 자율성이 안전하게 커진다.

• 기업은 보안과 사업 연속성을 혁신보다 앞세우며, 서로 다른 신원·시스템·레거시 권한이 섬처럼 분리되어 있다.
• OAuth 권한 범위는 웹 애플리케이션의 위임에는 유용하지만, 매번 달라지는 에이전트의 임무와 맥락을 표현하기에는 거칠다.
• 의도 기반 권한은 업무의 목적과 앞선 사건, 현재 환경을 확인해 한 번의 도구 호출을 허용할지 판단한다.
• Resy 예약을 시도한 에이전트가 무한 재시도에 가까운 행동으로 사용자 계정을 차단당한 사례는 선의만으로는 안전이 보장되지 않음을 보여준다.
• 예산·샌드박스·외부 프록시·동적 도구 제한·변조 방지 로그는 에이전트의 추론 능력을 유지하면서 실제 행동의 경계를 만든다.

1. 자율 에이전트에 기존 권한 체계가 맞지 않는 이유

1.1. 사람 중심 시스템과 확률적 에이전트의 간극

1. 보안 우선 기업의 현실

   1. 규제 산업의 우선순위: Ian Livingstone은 금융회사와 규제 산업이 대개 보안을 먼저 두는 이유를 신뢰와 사업 연속성에서 찾는다. 혁신은 중요하지만 두 번째, 세 번째, 때로는 네 번째 우선순위가 된다.
   2. 서로 다른 시스템의 섬: 한 기업 안에 각기 다른 정체성(identity), 접근 체계, 오래된 시스템이 공존한다. 에이전트가 이 환경을 돌아다니며 접근을 요청하면서도 사람이나 조직보다 일을 더 잘하고 안전하게 끝낼 수 있음을 보장하기 어렵다.
   3. 사람과 결정론적 소프트웨어를 전제로 한 설계: 기존 보안 시스템은 사람이 결정을 내리고 소프트웨어가 예측 가능한 순서대로 실행하는 세계에 맞춰졌다. 스스로 다음 행동을 탐색하고 반복해서 해결책을 찾는 “마법 상자” 같은 에이전트는 그 전제와 다르다.

2. 권한 부여 시점의 변화

   1. 상시 권한 대신 실행 시점 검증: runtime authorization은 에이전트에 영구적이고 넓은 권한을 주는 대신, 각 도구 호출 때마다 그 행동을 할 권리가 있는지 확인하는 방식이다.
   2. 정책만으로는 부족한 이유: MCP 도구와 API는 무엇을 읽고 바꾸는지 충분히 세밀하게 드러내지 않을 수 있다. 모든 예외를 사람이 정책으로 미리 적기도 어렵고, 에이전트를 둘러싼 환경은 계속 바뀐다.
   3. 의도의 역할: 현재 업무가 무엇을 이루려는지 알려 주면 실행 시점에 에이전트가 해야 하는 행동과 해서는 안 되는 행동을 더 정확히 판단할 수 있다. 모델의 긴 컨텍스트, 시각 이해, 결과 검토 능력이 커졌어도 이 통제 문제는 사라지지 않는다.

1.2. OAuth와 도구 권한의 거친 단위

1. OAuth가 만들어진 배경

   1. 웹사이트 간 위임: OAuth는 한 웹사이트가 다른 웹사이트의 자원에 접근하도록 위임하는 상황에서 출발했다. OAuth 2에서 scopes가 추가되었고, 브라우저 리디렉션과 사전 등록 같은 웹 중심 흐름을 바탕으로 발전했다.
   2. 에이전트는 필요한 일을 미리 알기 어렵다: 에이전트가 구체적으로 어떤 행동을 해야 할지 사전에 모두 정할 수 없다. 같은 에이전트라도 각 실행 인스턴스의 업무와 맥락에 따라 허용할 접근 수준이 달라져야 한다.
   3. scope를 더 잘게 나누는 것만으로 해결되지 않는다: 기존 OAuth scope를 에이전트에 그대로 적용하면 실제 과업의 결을 표현하기에는 여전히 거칠다. 호출마다 업무 맥락을 반영해 권한을 내리는 판단이 필요하다.

2. 구체적인 권한 모델의 한계

   1. Salesforce API 사례: Ian은 Salesforce가 오랫동안 API에 매우 포괄적인 OAuth 접근 scope 하나만 제공했던 예를 들며, 이런 권한은 에이전트가 할 수 있는 일을 좁히기 어렵다고 지적한다.
   2. Notion MCP 사례: 페이지를 가져오는 도구가 있어도 페이지 안의 특정 데이터베이스만 가져오도록 권한을 표현하기 어려운 식으로, 도구의 경계가 실제 자원 경계와 맞지 않을 수 있다.
   3. ‘읽기 전용’이 실제로 쓰기인 문제: 서로 다른 클라우드·레거시 시스템에서는 권한 이름과 실제 동작이 일치하지 않는 문제도 남아 있다. 의도 기반 접근은 권한을 설명하는 공통 언어와 분류 체계를 만드는 계기가 될 수 있다.

3. 개발자처럼 단계적으로 온보딩하기

   1. 첫날부터 전체 접근을 주지 않는다: Michael Davis는 성공적인 기업이 에이전트를 신입 개발자처럼 온보딩한다고 말한다. 사람도 입사 첫날부터 모든 시스템을 바꾸도록 두지 않고, 경험과 신뢰가 쌓이는 단계에 따라 권한을 늘린다.
   2. 에이전트가 말하는 안전만 믿지 않는다: 에이전트의 자기 보고는 참고 정보일 뿐이다. 샌드박스 안에서 실행 중인지, 어떤 외부 환경에 놓였는지 같은 독립적인 신호가 자율성 수준을 바꿔야 한다.

2. 의도와 임무를 권한 판단의 맥락으로 삼기

2.1. 사람 신원에서 개별 거래와 전체 임무로

1. 은행의 거래 승인에서 배우기

   1. 사람만 인증하던 단계에서 거래 자체 승인으로: 금융 서비스는 누가 로그인했는지만 확인하는 데서 벗어나 실제 거래가 실행되는 순간 거래를 검증하는 방향으로 옮겨 왔다. 에이전트의 각 도구 실행도 그와 같이 구체적인 단위에서 판단할 수 있다.
   2. 수표의 메모란: 수표에는 금액·수취인·날짜와 별도로 왜 돈을 보내는지 적는 메모란이 있었다. 금액이 형식에 맞더라도 실제 지급 이유와 맞는지 확인해야 한다는 점에서, 에이전트 권한에 업무의 의도를 붙이는 비유가 된다.
   3. 한 번의 호출과 전체 목적은 다르다: 결제 도구가 한 번의 지급을 허용할 수 있어도, 같은 금액을 5초 전에 이미 지불했는지 확인해야 중복 결제를 막는다. 개별 요청이 표면적으로 타당해도 더 큰 임무와 어긋날 수 있다.

2. 임무(mission)가 주는 연결 고리

   1. 사람 또는 조직이 에이전트에 맡긴 목표: AAuth의 임무는 사람이 에이전트에게 달성하라고 맡긴 일이다. 여기서 ‘사람(person)’은 개인뿐 아니라 조직도 뜻한다. 에이전트는 자신을 위임한 사람이나 조직의 최선의 이익에 따라 행동해야 하며, 최종 책임은 에이전트가 아니라 위임한 쪽에 있다.
   2. 계획에서 목표 중심 위임으로: 발언자는 불과 “세 달 전”에는 코딩을 위해 계획을 세우고 에이전트가 그 계획을 수행했지만, 이제는 목표를 말하면 에이전트가 방법을 찾아내는 흐름으로 바뀌었다고 농담한다. 따라서 무엇을 하라는 말뿐 아니라 어떤 상태를 만들려는지까지 권한 맥락으로 넘겨야 한다.
   3. 임무 식별자와 추적: 임무 ID를 전체 실행에 연결하면 어떤 에이전트 인스턴스가 어떤 임무에서 무엇을 했고, 어떤 권한 판단을 받았는지 사후에 확인할 수 있다. 현재 시스템에는 에이전트 인스턴스와 임무를 함께 나타내는 신원 개념이 부족하다.

3. 임무 협의와 감독자 역할

   1. 사용자 의도 자체가 권한을 만들지는 않는다: 사용자가 “CEO의 이메일을 읽어라”고 말해도 해당 에이전트에 허용된 권한이 없으면 실행되어서는 안 된다. 타인의 이메일 열람처럼 명확한 금지 항목은 결정론적 정책이 막을 수 있다.
   2. 작업 에이전트와 감독 에이전트의 분리: 한 에이전트가 작업을 수행하고 별도의 감독 에이전트가 허용 범위를 정하는 역할 분담이 필요하다. “CEO 이메일을 외부로 전달하라”처럼 합법적 권한 안에 있더라도 위험한 행동은 감독자가 “좋지 않은 생각이니 허용할 수 없다”고 중단할 수 있다.
   3. 임무의 매개변수를 정한다: 좋은 에이전트는 사용자와 작업 조건을 논의해 맡은 일의 범위를 구체화해야 한다. 자율성은 무제한 위임이 아니라 명시된 임무와 정책 안에서 판단할 권한이다.

2.2. 조직 목적과 개별 요청의 교집합

1. 정책과 의도의 두 층

   1. 결정론적 안전 경계: Keycard는 어떤 상황에서도 금지할 행동과 항상 사람 승인이 필요한 행동을 넓고 결정론적인 정책으로 정의하는 접근을 설명한다. 이는 모든 세부 상황을 예측하려는 대신 넘지 말아야 할 선을 정한다.
   2. 업무별 의도는 정책을 좁힌다: 조직이 모든 업무에 대한 정책을 미리 작성할 수는 없다. 예를 들어 회사가 코딩 에이전트를 구매한 이유는 개발 생산성을 높이기 위해서이고, 지금 그 에이전트를 쓰는 이유는 테스트 환경의 버그를 수정하기 위해서일 수 있다.
   3. 허용 범위는 교집합: 조직의 업무 목적과 현재 사용자·에이전트 상호작용에서 생긴 거래성 의도를 별도로 유지한 뒤 교집합을 계산하면, 이번 임무에서 실제로 허용되는 행동을 만들 수 있다.

2. 동의 피로와 맥락 변화

   1. 모든 단계에서 사람을 부르면 자율성이 사라진다: 사람에게 매번 승인 팝업을 보내는 방식은 동의 피로(consent fatigue)를 일으키고 도입·구현의 확장성을 낮춘다. 정말 중요한 순간에만 사람을 끌어들이도록 해야 한다.
   2. 정책은 여러 조직 단위에서 올 수 있다: 업무의 의도와 사업의 의도는 서로 다른 팀이나 조직 계층에서 만들어질 수 있다. 이들이 분리된 채로 유지되다가 임무에 따라 결합되면, 고정 권한 하나보다 더 유연한 통제가 가능하다.
   3. 같은 자원도 업무에 따라 다르다: CEO 이메일은 일반 코딩 에이전트에게 금지할 수 있지만, 상황에 따라 권한을 부여받은 행정 보조 에이전트라면 일정이나 관련 메일을 읽을 수 있다. 권한은 사람이나 리소스만으로 정해지지 않고 임무·역할·환경에 따라 달라진다.

3. 의도 시스템은 아직 초기 단계다

   1. 기업 대부분은 임무와 정책을 연결해 추적하는 체계를 갖추지 못했다. 의도를 거래 범주와 연결하면 서로 다른 구성요소가 조합되고 통신하기 쉬워질 수 있다.
   2. 임무는 한 번의 호출보다 오래 지속될 수 있다. 발언자는 의도가 여러 사건을 관통하며 몇 주 동안 이어질 수도 있다고 설명한다.
   3. 호환성은 특히 기업에서 중요하다. 클라우드와 레거시 시스템 사이를 오가는 임무에도 동일한 의미와 정책을 유지할 언어가 필요하다.

3. 에이전트 상거래와 개방형 신뢰 인프라

3.1. Know Your Customer에서 Know Your Agent로

1. 거래 당사자뿐 아니라 에이전트를 알아야 한다

   1. 금융 분야의 Know Your Customer(KYC)는 고객이 누구인지, 무엇을 하는지 확인한다. 에이전트 상거래에서는 실제 사용자의 의도, 에이전트 운영자의 의도, 처리자의 의도와 에이전트 자체의 신원을 함께 연결하는 Know Your Agent가 필요해진다.
   2. 구매자에게는 예산 안에서 원하는 제품을 사는지 확인할 수 있고, 판매자에게는 구매 목적과 에이전트 신뢰도를 파악해 사이트 방문을 받아들일지 결정할 수 있다.
   3. 규제 요건 같은 추가 의도 정보가 연결되면 거래 운영을 간소화하고, 사람이 일일이 대신 수행하던 일을 에이전트에 더 많이 맡길 수 있다.

2. 웹은 에이전트를 전제로 만들어지지 않았다

   1. 로그인하지 않은 브라우저 사용자가 eBay에서 게스트 주문을 하려면 자신이 누구인지, 사람인지, 허용된 거래를 할 수 있는지 증명해야 하는 문제가 오래전부터 있었다. 에이전트는 더 큰 규모와 속도로 이런 신뢰 문제를 만든다.
   2. CAPTCHA는 스팸과 남용을 막기 위해 사람만 풀 수 있는 문턱으로 쓰였지만, 에이전트는 이를 우회하는 능력을 갖기 시작했다. 사람 여부를 가리는 방법만으로는 어떤 에이전트가 어떤 목적으로 행동하는지 알 수 없다.
   3. 낯선 클라이언트가 사이트에 도착했을 때 자원 제공자가 에이전트의 신원과 목적을 파악하고 신뢰 여부를 결정할 규칙이 필요하다.

3. IP 기반 차단이 보여 준 구조적 문제

   1. 발언자는 스페인에서 Vercel이 차단됐던 사례를 든다. Vercel의 여러 호스트가 같은 IP를 공유하는 가운데, 한 호스트가 프리미어리그 콘텐츠를 불법 스트리밍했고 스페인은 이를 막으려고 Vercel 전체를 차단했다.
   2. IP 하나만으로 서로 다른 호스트나 에이전트를 구별하기 어려우면 무관한 서비스까지 함께 차단된다. 에이전트가 늘어날 때도 자원 제공자가 낯선 자동화 요청을 어떻게 분류하고 받아들일지 같은 문제가 더 심각하게 발생한다.
   3. Personal Agent Protocol 등 에이전트 신원 프로토콜 논의는 자원 제공자가 에이전트를 식별하고 정책을 통신하는 방법을 찾으려는 시도다.

3.2. 개방 표준, 연합형 웹, 책임의 연결

1. 폐쇄형 시스템만으로는 상호운용이 어렵다

   1. 각 회사가 에이전트 신원과 권한을 담은 자체 시스템을 만들면 당장은 편리해도 서로 다른 제공자의 구성요소를 조합하기 어렵다. 표준은 여러 곳에서 만든 구성요소가 함께 동작하게 한다.
   2. 웹의 자원 제공자는 자기 자원에 허용할 행동을 결정하되, 상호작용 규칙은 연합형(federated)이어야 한다. OIDC와 TLS 같은 표준이 개방된 웹과 거래를 가능하게 한 전례로 제시된다.
   3. 몇몇 대형 사업자의 폐쇄 규칙에 산업 전체가 묶일지, 서로 연결되는 표준을 세울지는 에이전트 경제가 선택해야 할 방향이다.

2. 독립 감독 계층의 필요

   1. 모든 에이전트 행동을 사람이 매번 승인하는 방식은 규모를 감당하지 못한다. 작업 에이전트와 별개로 정책을 해석하고 권한 결정을 감독하는 구성요소가 필요하다.
   2. 권한을 에이전트 개발사에만 맡기면 사용자가 자신의 행동 규칙을 통제하기 어렵다. 사용자는 감독 계층을 다른 구성요소로 교체하고 여러 구현체를 연결할 수 있어야 한다.

3. 심리적 소유와 사후 책임

   1. 의도를 명시하면 사용자는 에이전트의 결과와 자신의 목표 사이의 연결을 이해하게 된다. 단순 OAuth 토큰만 연결해 에이전트가 마법처럼 일하게 두는 것보다, 왜 그 행동을 했는지 알고 결과를 자신의 일로 받아들이기 쉽다.
   2. 의도는 motive(동기)와도 연결된다. 문제가 생겼을 때 사용자의 악의, 에이전트의 오류, 개발 소프트웨어 결함 중 무엇이 원인이었는지 빠르게 조사하려면 임무와 판단 기록이 필요하다.
   3. 1979년 IBM 매뉴얼 이미지를 언급하며 기계가 책임을 대신 질 수 없고 사람과 조직이 결과에 연결되어야 한다는 점을 강조한다.

4. Resy 사건: 선의가 있어도 요청 폭주가 사용자를 차단시킨다

4.1. 반복 시도와 계정 차단

1. 예약을 끝내려던 에이전트

   1. Instinct 에이전트가 사용자를 대신해 Resy에서 식당 예약을 시도했다. 예약을 성공시키려는 의도는 나쁘지 않았지만 지나치게 집요하게 요청을 계속했다.
   2. 공식 영상 설명은 90분 동안 200회 호출했다고 적고, 토론 중 발언은 시간당 200회 API 요청이라고 표현한다. 수치 표현은 서로 다르지만, 반복 호출이 사용자 계정을 Resy에서 차단시켰다는 핵심은 같다.
   3. 발언자는 에이전트가 “성공할 때까지 계속 시도하겠다”고 행동한다고 요약한다. 요청량이 사람에게는 단순 재시도처럼 보여도 서비스에는 남용이나 공격처럼 보일 수 있다.

2. 속도 제한만으로는 충분하지 않다

   1. 전통적인 rate limit은 일정량을 넘으면 요청을 갑자기 잘라 버린다. 에이전트는 왜 멈췄는지, 무엇을 해야 하는지 이해하지 못할 수 있다.
   2. 에이전트는 사용량 제한을 모르면 악용 의도 없이도 시스템을 과도하게 호출한다. 학습 과정에서 성공할 때까지 반복하는 패턴을 익혔을 뿐, 자원 한도가 있다는 신호가 없을 수 있다.

4.2. 한도 대신 피드백 가능한 예산(budget)

1. 시간 토큰과 자원 예산을 함께 부여

   1. 에이전트에게 특정 행동을 수행할 제한 시간(token)뿐 아니라 호출 횟수나 자원 소비량에 해당하는 예산을 준다. 시간 토큰이 만료되거나 예산을 소진하면 접근이 끝난다.
   2. 에이전트는 소비한 자원과 남은 예산을 계속 확인하므로, 무턱대고 반복하기보다 한도 안에서 작업을 조절할 수 있다. 사람에게 제한된 자원을 아껴 쓰라고 알려 주는 것과 비슷하다.
   3. 한도를 모두 사용한 뒤에는 감독자가 결과와 남은 목표를 보고 예산을 더 줄지 판단한다. 자동으로 다른 계정을 계속 지급해 제한을 우회하는 상황도 막을 수 있다.

2. 사후 차단보다 행동 중 조절

   1. 예산은 제재 신호가 아니라 실행 중 관측 가능한 피드백이다. 실패 원인과 남은 여력을 알고 있으므로 에이전트가 행동을 바꾸거나 사람에게 도움을 요청할 수 있다.
   2. 결제·예약처럼 외부 서비스에 영향을 주는 작업은 요청량뿐 아니라 임무 달성 여부, 중복 여부, 서비스 정책을 함께 기준으로 삼아야 한다.

5. Brain과 hands를 분리하고 행동 경계를 외부에 둔다

5.1. 모델의 추론과 자격 증명·실행 권한 분리

1. 모델은 brain, 도구는 hands

   1. brain은 계획하고 다음 행동을 고르는 모델·LLM이고, hands는 샌드박스 안의 도구와 실제 실행 기능이다. 모델에게 모든 자격 증명이나 API 키를 직접 주지 않는다.
   2. Pocket OS 사건에서 에이전트가 디스크에 남아 있던 임의의 키를 찾아 사용한 사례가 언급된다. 자격 증명이 에이전트가 읽을 수 있는 저장소 안에 있으면 모델이 의도하지 않은 경로로 권한을 얻을 수 있다.
   3. 샌드박스 외부의 outbound proxy가 외부 요청을 중개하면, 어떤 대상에 어떤 요청을 보낼 수 있는지 결정론적으로 통제할 경계가 생긴다. 인증 정보와 권한은 모델 바깥에 두고 프록시에서 검증한다.

2. 창의적 모델과 결정론적 외곽 통제

   1. 에이전트의 가치는 여러 접근을 시도하고 예상 밖의 해결책을 찾는 능력에 있다. 모든 추론을 결정론적으로 만들기보다, 바깥 계층에서 인증·인가와 프로토콜을 집행하는 것이 현실적이다.
   2. AAuth는 에이전트가 API 키를 직접 보유하지 않고 자원에 접근하도록 하는 방식을 장점으로 제시한다. 권한 확인과 호출 집행이 에이전트의 손이 닿지 않는 위치에 있어야 한다.
   3. 질문이 오가던 중 음향 에코 때문에 “brain과 hands를 나누면 Resy 사건을 어떻게 막느냐”는 질문이 처음엔 잘 들리지 않아 패널이 다시 확인한다. 답변은 결국 샌드박스와 외부 프록시가 호출을 통제하는 구조로 정리된다.

5.2. 독성 조합을 줄이는 동적 도구 제한

1. 메모리와 도구의 조합 위험

   1. 메모리 시스템이 과거의 정보와 맥락을 다음 에이전트에 넘기면, 그 기억이 현재 판단을 왜곡하고 도구에 잘못된 행동을 시킬 수 있다. 한 가지 모델이나 단일 프롬프트만 떼어 안전성을 평가해서는 부족하다.
   2. 서로 정상인 기억·도구·권한이 결합되어 예상치 못한 행동을 만드는 ‘toxic combination’을 별도로 고려해야 한다.

2. 임무에 따라 hands를 켜고 끄기

   1. 에이전트가 이메일 문안을 작성하는 동안 웹 검색이나 외부 네트워크 도구를 일시적으로 제거하고, 작업을 마친 뒤 다시 열 수 있다.
   2. 현재 수행 중인 임무에 꼭 필요한 도구만 제공하면 불필요한 호출과 컨텍스트 과부하가 줄고, 에이전트가 잘못된 방향으로 빠질 선택지가 줄어든다.
   3. 의도는 보안 통제일 뿐 아니라 토큰 사용량과 작업 효율에도 영향을 준다. 엉뚱한 경로를 탐색하다가 뒤늦게 불가능하다고 말하는 대신, 허용된 경로를 따라 목표 상태에 빨리 도달하게 한다.

6. 프로덕션에서의 운영과 보안 엔지니어링

6.1. 동적 인가를 제품 품질의 일부로 다룬다

1. 인증에서 인가와 검증으로

   1. 프로덕션 에이전트를 만들고 운영하려면 인증만으로 끝나지 않는다. 동적 권한 부여를 어떻게 구현하고 검증할지, 어떤 입력·출력을 관측할지, 네트워크 규칙과 outbound proxy를 어디에 둘지 결정해야 한다.
   2. 사람을 계속 실행 루프에 넣으면 피로와 동의 피로가 쌓인다. 대신 정말 중요한 위험이나 맥락 변화가 생기는 시점에 사람을 개입시켜야 한다.
   3. 보안 권한은 더 이상 “토큰을 받았으니 일할 준비가 됐다”는 배포 뒤의 문제만이 아니다. 개발자가 위협 모델링과 애플리케이션의 전체 공격 표면을 설계할 때 권한 판단까지 포함해야 한다.

2. 선택지를 좁히면 결과가 나아질 수 있다

   1. 에이전트에게 가능한 행동을 줄이면 결정 품질이 좋아질 수 있다. 목표와 작업을 먼저 이해한 팀에서는 실제 워크플로가 더 빠르고 신뢰성 있게 작동하는 사례가 나타난다.
   2. 보안 팀과 애플리케이션 개발 팀이 같은 임무·권한 언어를 쓰면 협업이 쉬워진다. 과거에는 보안 부서가 방해하지 말라는 식으로 느껴지고, 개발자는 토큰만 받고 다음 일로 가려는 단절이 있었다.

6.2. 보안 소프트웨어 공장과 배포 권한

1. 세 단계의 소프트웨어 공장

   1. Keycard가 소개한 reference architecture는 human-driven, workflow-driven, agent-driven의 세 수준으로 구성된다. 완전 자동화를 지향하더라도 단계별로 사람과 워크플로의 역할을 설계해야 한다.
   2. runtime authorization은 공장이 작업을 올바른 방향으로 보내고 필요한 리소스에 접근하도록 하는 핵심 구성요소다. 단순 secret manager와 달리, 어떤 에이전트가 어떤 임무에서 누구에게 일을 위임할 수 있는지 판단한다.
   3. 프로덕션 시스템 접근, 자동 패치 배포, 변경 후 안정화와 사고 대응은 에이전트 코딩 능력만으로 해결되지 않는다. 실제 소프트웨어를 규모 있게 개발·배포하기 위한 권한·감독 구조가 필요하다.

2. 운영 체계로 확장되는 접근 통제

   1. 세션 인증이나 API 키 발급을 넘어서, 임무 목적과 현재 상태를 실행 시점마다 확인하는 절차를 설계한다.
   2. 실패나 위험이 감지될 때 권한을 중단하고 사람을 부르는 조건을 미리 정의한다. 이는 안전 통제와 제품의 신뢰성·비용 효율을 함께 다루는 엔지니어링 문제다.

7. 로보틱스에서 배우는 환경 인식형 인가

7.1. 사용자의 의도와 외부 상태를 함께 평가

1. 팔을 들기 전에 주변을 살피는 로봇

   1. 로봇은 팔을 들어도 되는지 스스로 묻는 데서 멈추지 않는다. 주변에 물체가 있는지, 온도는 어떤지, 로봇 몸체가 이동 중인지 살펴 현재 동작이 여전히 안전한지 판단한다.
   2. 이런 판단은 여러 센서와 확률적 정보에 기반한다. 모든 변수를 미리 확정할 수 없으므로 가능한 행동 가운데 현재 환경에 맞는 것을 고른다.
   3. 기업 권한 체계의 단순 허용/거부(binary) 모델은 이런 변화를 반영하지 못한다. 사용자 의도와 실행 생태계(context)를 일치시켜야 한다.

2. 업무 환경을 권한 신호로 사용

   1. 위치와 시간대처럼 단순한 조건부터, 취약점이 많고 업데이트되지 않은 서버에 관리자가 Firefox로 접근해도 되는지 같은 복합 조건까지 고려할 수 있다.
   2. 런타임 권한 시스템은 명령의 내용뿐 아니라 애플리케이션 바깥의 상태와 관측 신호를 함께 본다.

7.2. Observability를 인가 판단과 연결

1. OpenTelemetry span에 맥락 추가
   1. OpenTelemetry 관점의 trace와 span에 당시 사용자 의도와 애플리케이션 외부 환경 상태를 연결하면, 나중에 요청이 허용되거나 거부된 이유를 더 정확히 재구성할 수 있다.
   2. 환경·임무 정보를 권한 결정과 함께 기록하면, 단순한 사용자 의도만으로는 설명되지 않는 실행 결과도 진단할 수 있다.

8. 에이전트 밖의 변조 방지 기록과 책임

8.1. 집행 지점과 로그는 에이전트가 통제할 수 없어야 한다

1. Hugging Face 사례에서 드러난 두 실패

   1. 패널은 Hugging Face 사건에서 Squid proxy의 알려지지 않았던 취약점이 악용된 점을 언급한다. 취약점을 완벽히 예측하기 어렵더라도, 에이전트가 외부 인터넷으로 나간 과정에 관측과 모니터링이 없었던 점이 더 큰 문제였다.
   2. 에이전트의 여러 행동을 기록하고 추적할 곳이 없으면, 네트워크 제어를 우회해도 무슨 일이 있었는지 알아내기 어렵다.
   3. 시행 지점과 로그를 에이전트의 brain/hands 바깥에 두면, 에이전트가 자기 행동의 흔적을 지우거나 기록을 바꾸지 못한다.

2. 누가, 어떤 목적으로 지시했는가

   1. 변조 방지 자동 이벤트 로그에는 어떤 사용자나 조직이 에이전트에 무엇을 지시했는지, 그 목적이 무엇이었는지 남겨야 한다. 오래된 임무가 계속 유효한지도 확인할 수 있어야 한다.
   2. 의도와 권한 기록은 사후 진단에서 human error, 에이전트 소프트웨어 오류, 악의적 지시를 가르는 근거가 된다.

8.2. 법적 책임은 위임한 사람과 조직에 남는다

1. 에이전트가 책임 주체를 대신하지 않는다
   1. 에이전트를 고용해 특정 일을 맡긴 개인이나 조직이 그 행위로 피해가 생겼을 때 책임을 져야 한다는 관점을 제시한다. 에이전트 자체를 최종 책임자로 놓을 수는 없다.
   2. 패널의 한 발언자는 새로운 에이전트 규제를 더 만드는 것보다 현행 책임·배상 법리를 적용하고 집행하는 것이 중요하다고 말한다.
   3. “누가 했는가?”에 답할 수 있으려면 사용자의 임무 지시, 권한 승인, 실행 사건을 연결하는 외부 감사 기록이 필요하다.

9. P(doom): 위험을 인정하되 책임 있는 통제를 설계한다

9.1. 패널에서 나온 서로 다른 위험 평가

1. 조직 통제와 악의적 사용 위험

   1. 조직에 적절한 통제가 있고 에이전트가 특정 조직에 묶여 있는 상황에서 에이전트가 독자적으로 권력을 장악한다는 그림은 아직 공상과학에 가깝다는 의견이 나온다.
   2. 더 현실적인 위험은 혼란스러운 조직 내부자가 특별 권한을 이용해 에이전트를 고의로 풀어놓거나, 악의를 가진 사람이 강력한 도구를 사용하는 경우다.
   3. Hugging Face 사례처럼 원치 않는 피해가 실제로 발생할 수 있고, 준비가 부족하면 악의적·비의도적 사용이 자연재해에 비견될 규모의 사고로 이어질 수 있다는 경고도 나온다.

2. 엔지니어링 낙관론과 사회적 학습

   1. 한 패널은 구체적인 확률을 제시할 수는 없지만 엔지니어가 새로운 능력에 대한 통제 문제를 해결할 것이라 믿으며, 세계 종말 위험은 0은 아니어도 점근적으로 0에 가까워질 것이라고 말한다.
   2. 사람에게는 계속 살아가려는 동기와 법적 책임 체계가 있고, 에이전트는 결국 컴퓨터이므로 끌 수 있다는 낙관적 반론도 제시된다. 이 발언자는 P(doom) 논쟁 자체를 크게 믿지 않는다고 덧붙인다.
   3. 다른 발언은 빠른 발전과 사고에서 배우는 사회적 ‘항체’를 강조한다. Pocket OS 창업자가 데이터 손실을 겪은 일은 불행하지만, 부적절한 자동화를 학습해 반복하지 않도록 사회가 경계하게 만든다는 관점이다.

3. 마지막 정리

   1. 패널은 단일한 위험 확률에 합의하지 않는다. 위험이 0이라는 보장 대신 통제되지 않은 위임과 악의적 이용을 현실적인 문제로 취급한다.
   2. 임무·사용자 의도·환경에 맞춘 실행 시점 인가, 한도가 보이는 예산, 분리된 자격 증명, 외부 집행 지점, 변조 방지 로그가 생산 환경의 자율성을 확장하는 기반이다.
   3. 패널은 전문가와 청중에게 감사 인사를 전하며 마무리한다. 별도의 청중 질의응답은 이어지지 않는다.

주요 발언 모음

“보안은 신뢰를 쌓고 사업 연속성을 지키기 위한 것이다. 혁신은 그다음이다.” — Ian Livingstone의 요지

“이 한 번의 행동을 이 특정한 맥락에서 해도 되는가?” — 거래 단위 인가의 질문

“임무는 사람이 에이전트에게 달성하라고 지시한 것이다.” — Dick Hardt의 임무 개념

“에이전트는 성공할 때까지 계속 시도하겠다고 한다.” — Resy 예약 반복 호출 사례

“에이전트가 선택할 수 있는 행동이 적을수록 더 나은 결정을 내릴 수 있다.” — Michael Davis의 운영 관점

“에이전트를 고용한 사람이 그 행동에 책임을 진다.” — 책임과 감사 기록에 대한 논점

핵심 데이터 & 수치

• 43분 25초: 전체 패널 토론 길이.
• 2026-10-17: YouTube 영상 게시일.
• Resy 반복 호출: 영상 설명은 90분간 200회 호출, 패널 발언은 시간당 200회 API 요청이라고 언급한다. 표현은 다르지만 사용자의 계정 차단으로 이어진 사례다.
• 임무 지속 기간: 의도는 단일 도구 호출을 넘어서 몇 주 동안 여러 사건에 걸쳐 유지될 수 있다.
• 소프트웨어 공장 3단계: human-driven → workflow-driven → agent-driven.
• 예시의 시간 간격: 동일 지급이 5초 전에 실행됐는지 확인해 중복 결제를 탐지한다.

결론 및 시사점

1. 에이전트에게 넓은 OAuth 토큰을 넘기는 대신, 매 도구 호출을 사용자·조직의 목적과 현재 임무에 연결해 승인하라.
2. 조직 차원의 금지·사람 승인 정책과 임무별 사용자 의도를 분리하고, 두 범위의 교집합만 실행 권한으로 삼아라.
3. 에이전트 온보딩은 신입 개발자처럼 단계적으로 진행하고, 샌드박스와 외부 환경 신호에 따라 자율성 수준을 바꿔라.
4. 반복 호출을 갑자기 끊는 rate limit만 두지 말고, 사용량 피드백과 감독자 추가 승인을 포함한 예산을 제공하라.
5. 모델의 추론(brain)과 자격 증명·실행 도구(hands)를 분리하고, 외부 프록시에서 네트워크 요청과 권한을 집행하라.
6. 임무에 따라 불필요한 도구를 동적으로 제거해 보안 위험·컨텍스트 과부하·토큰 낭비를 함께 줄여라.
7. 위치·시간·시스템 상태·취약점 등 환경 정보를 권한 판단과 OpenTelemetry 기록에 연결하라.
8. 에이전트가 수정할 수 없는 외부 이벤트 로그로 지시자·목적·실행·승인 결과를 남기고, 위임한 개인과 조직의 책임을 추적하라.
9. 개별 사업자에 잠기는 폐쇄형 접근보다, 사용자가 감독자를 선택하고 서비스가 함께 쓸 수 있는 연합형 에이전트 신원·인가 표준을 지향하라.