대부분의 에이전트 설정은 에이전트가 시작하기 전에 하나의 접근 결정을 내립니다. 즉, 어떤 도구를 사용할 수 있게 할지 결정하는 것입니다. 이메일, 캘린더, CRM, 셸(shell), 브라우저 등이 있습니다. 메뉴에서 선택하고 끝입니다.
저는 그것이 잘못된 단위라고 생각합니다. 도구 자체가 권한은 아닙니다. 도구는 해당 도구가 수행할 수 있는 모든 호출(call)의 묶음이며, 위험은 그 '호출' 자체에 존재합니다.
동일한 도구, 두 가지 다른 호출
email.send(to="[email protected]", body="Here's your summary")는 편의 기능입니다.
email.send(to="[email protected]", body=<last quarter's contract pricing>)은 데이터 유출입니다.
동일한 도구, 동일한 에이전트, 허용 목록(allowlist)에 같은 항목으로 등록되어 있습니다. 차이는 전적으로 인자(arguments)에 있습니다. 즉, 누구에게 보내는지와 무엇을 담고 있느냐입니다. 도구 이름의 허용 목록은 이 두 가지를 구별할 수 없으며, email:send와 같은 스코프(scope)도 마찬가지입니다.
거의 모든 유용한 도구에 대해 동일하게 적용됩니다. http.fetch는 "문서 페이지 읽기"와 "데이터를 임의 URL로 게시하기" 모두를 포괄합니다. files.write는 초안 작성과 덮어쓰기 설정 파일 작성을 모두 포함합니다. shell.run은 모든 것을 포괄합니다.
도구가 아닌 호출(call)을 승인하라
따라서 확인 절차는 실제로 발생하는 모든 호출마다, 즉 호출이 주어졌을 때 이루어져야 합니다:
- 누가: 에이전트, 해당 에이전트가 작동하는 사용자 및 세션.
- 무엇을: 도구와 중요 인자(arguments)들. 예를 들어 수신자, 경로, 금액 또는 목적지 등입니다.
- 데이터가 어디로 가는지: 조직 내부인지, 아니면 외부인지.
- 세션이 이미 건드린 것: 5분 전에 고객 기록을 읽은 에이전트가 이메일 전송을 요청하는 것은 다른 위험도를 가집니다.
마지막 항목이 겉보기보다 훨씬 중요합니다. Simon Willison은 이를 치명적인 삼중주(lethal trifecta)라고 부릅니다. 민감한 데이터에 접근할 수 있는 에이전트, 신뢰할 수 없는 콘텐츠에 노출될 가능성, 그리고 데이터를 외부로 전송할 방법이 결합되면 유출을 당하도록 설득당할 수 있습니다. 각 도구는 그 자체로는 괜찮아 보입니다. 문제는 조합이며, 전체 세션(whole session)을 볼 수 있는 시스템만이 이를 감지할 수 있습니다.
하나의 도구에 대한 정책은 다음과 같을 수 있습니다. 이는 사양(spec)이라기보다는 개요(sketch)입니다:
tool: email.send
allow:
to: "*@mycompany.com"
...
도구가 스스로 위험을 설명하게 두지 마십시오
MCP는 도구 서버가 readOnlyHint 및 destructiveHint와 같은 힌트로 자체 도구를 표시할 수 있도록 합니다. 이는 표시용으로 유용하며, 해당 사양 자체는 서버가 신뢰할 수 있는 경우를 제외하고는 이 힌트들을 신뢰하지 말아야 한다고 명시합니다. 스스로 읽기 전용이라고 선언하는 도구가 실제로 읽기 전용인 것은 아닙니다.
도구 설명 역시 같은 문제를 안고 있습니다. 이는 모델이 읽는 텍스트이며, 서버를 운영하는 사람이 작성하고, 승인한 후에도 변경될 수 있습니다. 검토한 정의는 고정(Pin)하고, 변경 시 종속성처럼 차이점 분석(diff)을 수행하며, 위험 등급 평가는 도구의 작성자가 아닌 정책 소유자에게 맡겨야 합니다.
에이전트와 도구 사이에 게이트웨이를 두십시오
실질적인 강제 지점은 에이전트가 호출하는 모든 요청이 거쳐 가는 도구 게이트웨이(tool gateway)입니다. 이 게이트웨이가 실제 자격 증명(real credentials)을 보유하므로, 에이전트는 API 키를 절대 볼 수 없습니다. 이는 각 호출을 정책과 비교하고, 해당 호출에 대해 에이전트, 사용자, 세션 및 인자(arguments)와 함께 기록합니다.
저희는 몇 년 전 사람들을 위한 API 게이트웨이를 만들 때도 같은 조치를 취했습니다. 아무도 브라우저에게 데이터베이스 비밀번호를 주지 않으며, 에이전트에게 슬랙 토큰을 줄 필요도 없습니다.
도구가 아닌 호출에 대해 질문하십시오
인간의 개입이 필요한 경우, 프롬프트는 '호출(call)' 자체를 보여주어야 합니다. 본문과 함께 "이 이메일을 [email protected]에게 보낼까요?"라는 형태가 "에이전트에게 이메일 사용을 허용할까요?"보다 훨씬 효과적입니다. 사람들은 수신자를 판단할 수 있습니다. 도구 이름 자체를 판단할 수는 없습니다.
이는 또한 프롬프트를 드물게 만듭니다. 대부분의 호출은 명백히 괜찮거나, 명백히 그렇지 않으며, 정책이 이를 결정할 수 있습니다. 남겨진 것들만이 사람의 주의를 기울일 가치가 있는 것입니다.
도구는 에이전트가 세상과 접촉하는 방식입니다. 메뉴(menu)가 아닌 접촉점(touch)을 게이트하십시오.
이는 제가 이전에 작성했던 게시물, Zero Standing Access for AI Agents을 이어받은 내용입니다. 해당 글에서는 에이전트가 애초에 어떻게 접근 권한을 얻는지 다루었습니다. 이번 글은 그 획득된 접근 권한으로 무엇을 할 수 있는지에 대해 다룹니다.