누가 승인 버튼을 누르는가: AI 에이전트 도구는 실행 전에 정말 묻고 있나
작성자 ReviewRamble editors ·
거의 모든 에이전트 도구가 되돌릴 수 없는 일을 하기 전에 확인하겠다고 말합니다. 물어야 할 것은 그 확인이 어디에 있느냐입니다. 에이전트의 지시문 안, 에이전트를 실행하는 클라이언트 안, 에이전트와 그것이 조작하는 대상 사이의 게이트웨이 안, 아니면 아무 데도 없을 수 있습니다. 묻지 않기로 한 에이전트를 멈출 수 있는 것은 이 중 하나뿐이며, 그것에도 뒷문이 있습니다.
이 글은 이번 주에 발행한 리뷰를 하나의 질문으로 다시 읽습니다. 누가 승인 버튼을 누르는가. 안전성 모델과 프롬프트 인젝션 필터는 AI 앱과 에이전트를 위한 가드레일 가이드에서, 코딩 에이전트용 샌드박스는 5계층 가이드에서 다루므로 여기서는 반복하지 않습니다. 아래의 모든 사실은 리뷰와 리뷰가 인용한 프로젝트 문서에서 나온 것이며, 저희가 이 도구들을 직접 실행해 보지는 않았습니다.
승인이 자리할 수 있는 네 곳
- 프롬프트 안. 스킬이나 시스템 프롬프트에 먼저 물어보라고 적힌 한 줄입니다. 모델은 이를 조언으로 읽습니다.
- 클라이언트 안. Claude Code, Codex, Cursor 등은 도구를 실행하기 전에 승인 요청을 띄웁니다. 누군가 끄기 전까지는 작동하며, 대부분의 클라이언트는 끌 수 있게 해 줍니다.
- 게이트웨이 안. 에이전트와 그것이 조작하는 휴대폰, 계정, 집 사이에 놓인 프로그램으로, 사람이 답할 때까지 동작을 보류합니다. 모델이 말로 빠져나갈 수 없는 유일한 종류입니다.
- 아무 데도 없음. 도구는 시키는 대로 하고, 확인은 그때 클라이언트에 켜져 있는 것뿐입니다.
프롬프트: 자물쇠가 아니라 부탁
Agent Autoloop(3.8)은 이 점에서 드물게 솔직합니다. cron 작업과 웹훅으로 Claude Code나 Codex를 무인으로 실행하며, 각 규칙에는 위험한 단계 전에 확인하라는 지시인 askFirst를 붙일 수 있습니다. 프로젝트의 보안 노트는 askFirst가 프롬프트에 적힌 부탁일 뿐이어서 에이전트가 무시할 수 있고 허브는 막을 수 없다고 직접 밝힙니다. 실행을 실제로 제한하는 것은 접근 수준이며, 이는 클라이언트의 권한 모드에 대응합니다. full 수준은 Claude Code의 bypassPermissions, Codex의 danger-full-access에 대응하므로, 어떤 일에도 승인이 없다는 뜻입니다.
Google Agent Skills(4.2)는 같은 빈틈을 반대편에서 보여 줍니다. gcloud 스킬은 IAM 변경, API 활성화, 삭제에는 명시적 승인이 필요하다고 하면서, 같은 파일에서 에이전트에게 모든 명령에 --quiet를 붙여 gcloud가 자체 확인 프롬프트에서 멈추지 않게 하라고 지시합니다. cloud-run-basics 스킬은 API를 활성화하고 IAM 역할을 부여하며 --allow-unauthenticated로 공개 서비스를 배포하는데, 모든 단계에 --quiet가 붙습니다. 프로그램이 강제하던 유일한 확인은 제거되었고, 남은 것은 모델이 따를 수도 있고 따르지 않을 수도 있는 한 문장입니다.
클라이언트: 끌 수 있는 확인
대부분의 MCP 서버에서는 클라이언트의 도구 승인 요청이 안전 대책의 전부입니다. X의 공식 서버인 X MCP(3.8)는 게시물이 올라가기 전에 묻는 장치가 X 쪽에 없습니다. 읽기 전용 스위치가 없으면 확인은 클라이언트의 승인 요청뿐이며, 대부분의 클라이언트에서는 이를 끌 수 있습니다. 게시물 하나는 $0.015, 링크가 있는 게시물은 $0.200이므로, 방치된 에이전트는 평판뿐 아니라 돈도 씁니다.
이번 주에 리뷰한 여러 도구는 설정 하나만 바꾸면 이 승인 요청이 사라지는 위치에 있습니다. Autoloop의 full 수준이 그중 하나입니다. llama-modchip(3.6)은 로컬 모델을 대상으로 Claude Code를 시작할 수 있으며, 그 스크립트는 MODCHIP_CLAUDE_SKIP_PERMS=1이 설정된 경우에만 --dangerously-skip-permissions를 붙입니다. 올바른 기본값이지만 쉽게 바뀔 수 있는 값입니다. 클라이언트 승인은 실제 통제 수단이지만 설정을 편집하는 사람의 것이며, 무인 구성은 보통 이것을 끄는 방식으로 만들어집니다.
클라이언트 승인은 누가 답했는지도 증명하지 않습니다. Call Me(3.6)는 에이전트가 질문에서 멈추면 휴대폰으로 전화를 걸고, 말로 한 대답을 녹취록으로 돌려줍니다. "네, 배포하세요"는 당신이 말했다는 증거 없이 일반 텍스트로 도착하고, 호스팅 엔드포인트에는 10자리 번호 외에 인증이 없습니다. 리뷰는 두 번째 확인이 에이전트 자체의 권한 설정에서 와야 한다고 분명히 말합니다.
게이트웨이: 버티는 쪽
Pinky(3.6)는 저희가 읽어 본 것 중 가장 명확한 게이트웨이입니다. 에이전트가 휴대폰에서 하는 모든 탭이 이곳을 거칩니다. 결제나 보내기 버튼을 누르면 에이전트에게 approval_pending이 돌아가고, 당신이 Allow를 클릭할 때까지 휴대폰에서는 아무 일도 일어나지 않으며, 60초 안에 답이 없으면 거절로 처리됩니다. 은행 앱과 비밀번호 관리 앱은 에이전트에게 보이지 않고, 일회용 코드는 점으로 가려져 전달됩니다. 중요한 한계가 두 가지 있습니다. 기본 상태에서는 결제, 거래, 송금만 승인을 기다리며, 보내기, 삭제, 통화, 설치는 Settings에서 켜야 합니다. 또 위험한 버튼은 10개 언어의 레이블로 찾기 때문에 특이한 레이블은 빠져나갈 수 있고, 그래서 모든 단계 전에 묻는 모드를 제공합니다.
Codex Security(4.1)는 경계를 사람이 아니라 샌드박스에 둡니다. 검증은 읽기 전용에 네트워크 없이 실행되고, 쓰기를 하는 패치 단계는 샌드박스가 시작되는지 확인한 뒤 시작되지 않으면 SANDBOX_UNAVAILABLE로 거부합니다. --external-sandbox 옵션은 이 강제를 끄고 격리를 당신의 컨테이너에 맡기며, Deep scan 워커는 읽기 전용이지만 OpenAI의 표현으로는 격리된 오프라인 환경이 아닙니다.
Stroq(3.8)는 에이전트의 훅에 자리 잡고, 에이전트가 방금 페이지, 이슈, 파일에서 읽은 텍스트를 되풀이하는 명령에 대해 당신에게 묻고, curl | sh는 바로 거부합니다. README 스스로 이것이 샌드박스가 아니라 필터라고 말합니다. 비교는 텍스트 단위라서 모델이 처음부터 작성한 명령은 출처를 추적할 수 없고, Codex와 Windsurf에서는 훅이 거부는 할 수 있어도 질문은 할 수 없습니다.
아무 데도 없음: 그냥 실행하는 도구
HomeMCPBridge(2.8)는 에이전트를 Apple HomeKit에 연결합니다. control_device 도구는 기기 이름과 동작을 받으며, 그 동작에는 도어록 해제와 차고 문 열기가 포함됩니다. 저희가 소스를 읽은 바로는 확인 단계도, 허용 목록도, 잠금장치를 읽기 전용으로 만드는 방법도 없습니다. iPhone MCP(3.2)는 Apple의 미러링 앱을 통해 실제 iPhone을 조작하며, 확인 단계도 앱 허용 목록도 읽기 전용 모드도 없습니다. 자체 면책 문구는 의도하지 않은 메시지, 삭제된 데이터, 구매를 언급합니다.
이 그룹에서 가장 강한 설계는 존재하지 않는 도구입니다. WhatsApp MCP (finereli)(3.8)에는 의도적으로 보내기 도구가 없어서, 메시징 에이전트의 최악의 실패가 일어날 수 없습니다. X MCP의 read_only=true는 서버에서 같은 일을 합니다. 게시, 메시지 전송, 변경을 하는 도구는 목록에서 빠지고, 토큰에 쓰기 권한이 있어도 서버는 그런 호출을 거부합니다. 없는 도구는 누가 무엇을 누를 필요가 없습니다.
모든 게이트웨이에는 뒷문이 있다
게이트웨이는 유일한 입구일 때만 버팁니다. Pinky의 FAQ는 이를 분명히 적습니다. 당신 권한으로 명령을 실행할 수 있는 에이전트는 adb를 통해 Android 휴대폰에 닿아 모든 규칙을 건너뛸 수 있습니다. 조언은 그런 에이전트를 휴대폰에 접근할 수 없는 샌드박스에서 실행하거나, 휴대폰을 다른 컴퓨터에 연결하고 그곳의 Pinky에 HTTP로 접속하라는 것입니다. 이는 일반적인 구성의 Claude Code와 Codex에 해당하므로, 대부분의 독자에게 게이트웨이는 이 추가 단계를 거친 뒤에야 휴대폰을 보호합니다.
같은 논리는 반대로도 작동합니다. 경로 위의 프록시는 지나가는 모든 것을 봅니다. billion-context(3.4)는 오래된 컨텍스트를 접기 위해 코딩 에이전트와 모델 API 사이에 놓이므로, 모든 프롬프트와 API 키가 인증 없이 이곳을 지나며, 기본 설정에서는 3분마다 npm에서 자신의 새 버전을 확인합니다. 게이트웨이에 동작 보류를 맡기기 전에 그것이 무엇을 읽을 수 있고 누가 그 코드를 바꿀 수 있는지 물어보십시오.
승인은 어디에 있는가: 도구별
| 도구 | 되돌릴 수 없는 일 | 확인의 위치 | 강화하는 방법 |
|---|---|---|---|
| Pinky | 휴대폰에서 결제, 보내기, 삭제 | 게이트웨이. 기본값은 결제만 | 보내기와 삭제를 켜고, 셸이 있는 에이전트를 adb에서 떼어 놓기 |
| Agent Autoloop | 에이전트 CLI가 할 수 있는 모든 것 | 클라이언트 권한 모드. askFirst는 프롬프트 | edit 유지, 무인 실행을 받아들일 수 있는 곳에만 full |
| Codex Security | 패치 작성 | 샌드박스. --external-sandbox 사용 시 제외 | 내장 샌드박스 유지, 모든 패치 검토 |
| Google Agent Skills | 배포, IAM 역할 부여, API 활성화 | 프롬프트뿐. --quiet가 gcloud의 확인을 제거 | 제한된 프로젝트 역할, 결제 예산, 클라이언트 승인 켜기 |
| X MCP | 게시물과 Articles 공개 | 클라이언트뿐, 또는 read_only=true | 읽기 전용으로 시작, 지출 한도 설정 |
| HomeMCPBridge | 잠금장치와 차고 문 열기 | 아무 데도 없음 | 혼자 실행되는 에이전트에는 연결하지 않기 |
| Call Me | 말로 한 승인을 전달 | 에이전트의 권한 설정 | 음성 "네"는 미확인으로 취급 |
| Stroq | 명령에 대해 묻거나 거부 | 에이전트 훅, 텍스트 비교 | 컨테이너나 별도 계정과 함께 사용 |
이번 주에 적용할 수 있는 규칙
- 되돌릴 수 없는 동작마다 승인의 위치를 찾으십시오. 결제, 보내기, 삭제, 배포, 물리적 동작 각각에 대해 어떤 프로그램이 그것을 보류하는지 적어 두십시오. 답이 "프롬프트에 물어보라고 적혀 있다"라면 확인이 없는 것으로 간주합니다.
- 확인이 붙은 도구보다 없는 도구를 택하십시오. 읽기 전용 스위치나 쓰기 도구가 없는 서버가 어떤 프롬프트보다 낫습니다. X MCP는 read_only=true로 시작하고, 읽기만 하는 일이라면 보내기와 삭제가 빠진 서버를 고르십시오.
- 게이트웨이가 꺼 둔 것을 켜십시오. 기본값은 범위가 좁습니다. Pinky는 보내기, 삭제, 통화, 설치를 추가하기 전까지 결제 전에만 묻습니다.
- 앞문을 믿기 전에 뒷문을 닫으십시오. 셸이 있는 에이전트는 adb를 포함해 당신의 사용자 계정이 닿는 모든 것에 닿습니다. 게이트웨이가 지키는 기기와 자격 증명을 볼 수 없는 샌드박스나 별도 사용자로 실행하십시오.
- 설정 파일에서 스위치를 찾으십시오. bypassPermissions, danger-full-access, --dangerously-skip-permissions, --quiet, --external-sandbox는 각각 확인 하나를 없앱니다. 각각이 어디에, 왜 설정되어 있는지 파악하십시오.
- 모델이 반박할 수 없는 한도로 프롬프트를 뒷받침하십시오. 좁은 클라우드 역할, 결제 예산, 유료 API의 지출 한도는 에이전트가 단계를 건너뛰어도 계속 작동합니다.
- 원격의 "네"는 미확인으로 취급하십시오. 전화나 채팅 답장은 누가 답했는지 증명하지 않습니다. 배포와 결제는 본인 로그인에 묶인 승인 뒤에 두십시오.
주의할 점: 가장 잘 버티는 게이트웨이일수록 가장 새롭습니다. Pinky는 1주, Autoloop은 10일, Stroq는 약 10주 된 프로젝트이며, 이들의 보안 설명은 외부 검토가 아니라 메인테이너가 쓴 것입니다. 성숙한 통제 수단인 클라이언트 승인과 클라우드 권한은 사람들이 에이전트를 무인으로 돌리려고 끄는 바로 그것입니다. 여기 있는 어떤 도구도 당신의 돈이나 현관문을 에이전트에게 맡겨 두어도 안전하게 만들어 주지는 않습니다.
결론: 모든 에이전트 구성에 법인 카드를 받은 신입 직원에게 할 질문을 던져 보십시오. 누가 결재하는가, 그리고 그 사람이 당신 없이 결재할 수 있는가. 정직한 답이 직원 본인이라면 결재는 없는 것입니다. 승인은 에이전트가 편집할 수 없는 프로그램에 두고, 일에 필요 없는 도구는 빼고, 주의는 정말 중요한 몇 번의 클릭을 위해 아껴 두십시오.