개발 노트

에이전트가 내 컴퓨터를 빌려 달라고 한다. 권한을 얼마나 줘야 할까?

OpenAB Connect · 2026년 9월 30일

지난 글 〈터미널 신뢰 스펙트럼〉은 이렇게 끝났습니다. 에이전트가 정말로 풀려나는 날, 모두가 가장 먼저 묻는 것은 — 그것이 무엇에 닿을 수 있는가? 이번 글은 같은 질문의 반대편에 답합니다. 에이전트가 당신의 컴퓨터를 빌려 달라고 할 때, 권한을 얼마나 줘야 할까요?

OpenAB Connect의 에이전트는 원격 샌드박스에서 돌아가며, 원래는 당신의 컴퓨터에 닿을 수 없습니다. 그래도 닿게 하고 싶을 때가 있습니다. 화면을 보고 어디가 잘못됐는지 알려 달라, 브라우저에서 양식을 채워 달라, Mac에서 Xcode 빌드를 한 번 돌려 달라. 그럴 때 Connect나 Remote에서 컴퓨터를 빌려줍니다. 기간을 고르고, 프로필을 고릅니다. 프로필이 에이전트가 받는 것을 정합니다.

직관적인 답은 틀렸다

가장 먼저 떠오르는 생각은 “명령만 실행하지 못하게 하면 안전하다”입니다. 보고, 클릭하고, 입력하는 것까지는 허용하되 셸은 주지 않는 것이죠.

문제는 데스크톱을 조작할 수 있으면 셸이 있는 것과 같다는 점입니다.

• osascript는 do shell script를 실행할 수 있습니다.
• key는 터미널에 입력할 수 있습니다.
• mouse는 터미널을 열 수 있습니다.

AppleScript 내용을 필터링해도 막히지 않습니다. JXA의 doShellScript, ObjC.import로 부르는 NSTask, Terminal의 do script, System Events의 키 입력. 들어갈 길이 너무 많습니다. “명령 실행 금지”는 편리한 입구 하나를 줄일 뿐, 권한은 하나도 줄이지 않습니다.

우리도 직접 그 함정에 빠졌다

최근까지, 본인이 쓰는 owner 외의 선택지는 sandbox라는 이름이었습니다. owner에서 exec만 뺀 것이었죠.

이 이름은 틀렸습니다. 샌드박스가 아니라 셸과 동등했습니다. sandbox라고 부르면서 셸을 넘기는 선택지는 선택지가 없는 것보다 나쁩니다. 안심하고 빌려줘도 된다고 믿게 만들기 때문입니다. 그래서 버렸습니다. sandbox는 실제로 할 수 있는 일에 맞춰 desktop으로 이름을 바꾸고, 진짜 경계로 observe를 추가했습니다(#45).

세 가지 선택지, 각각 넘기는 것

desktop은 macOS에서는 exec가 없지만 마우스, 키보드, AppleScript는 있습니다. Linux에서는 bash를 그대로 남겨 둡니다. mouse와 key로 어차피 터미널을 열 수 있으니, bash를 숨겨도 에이전트가 불편해질 뿐 권한은 줄지 않습니다. 그래서 줄어든 척하지 않습니다. 전체 도구 목록은 tool-profiles.md에 있습니다.

왜 “보기”만 경계인가

observe의 도구는 sys_info와 screenshot 두 개뿐입니다. 입력도, 클릭도, 명령 실행도, 상태 변경도 할 수 없습니다. 경계가 되는 이유는 세 가지입니다.

• denylist가 아니라 allowlist입니다. 앞으로 추가되는 도구는 로컬이든 브라우저든, 누군가 명시적으로 넣기 전까지 observe에서 거부됩니다.
• 이름이 능력을 말합니다. observe는 “보기”, desktop은 “데스크톱 조작”입니다. 무엇을 뺐는지로 이름 짓지 않습니다.
• 규칙이 문서가 아니라 테스트에 있습니다. ProfileBoundaryTests가 모든 프로필을 검사해, 셸보다 좁다고 하면서 셸에 닿는 도구를 하나라도 허용하면 CI가 실패합니다.

한계도 분명히 적어 둡니다. 스크린샷은 화면에 보이는 것을 드러냅니다. observe가 보장하는 것은 “손을 댈 수 없다”이지 “아무것도 보지 못한다”가 아닙니다. 빌려주기 전에 보여 주고 싶지 않은 창은 닫아 두세요.

하나 더. observe가 지키는 것은 당신의 컴퓨터이지 에이전트가 아닙니다. 스크린샷은 에이전트의 컨텍스트로 들어가므로, 화면에 악의적인 페이지나 메시지가 있으면 그 글이 프롬프트 인젝션이 될 수 있습니다. 에이전트는 컴퓨터에 손을 댈 수 없어도, pod 안의 자기 셸, 기본으로 열린 외부 인터넷, 그 세션이 가진 자격 증명(예: git)을 그대로 가지고 있어, 읽은 것을 어느 호스트로든 보낼 수 있습니다.

브라우저는 따로 생각해야 한다

owner에는 브라우저 도구 32개가 모두 보이고, desktop에는 15개만 보입니다. 이동, 읽기, 클릭, 양식 입력입니다. 뺀 것에는 임의의 JavaScript를 실행하는 browser_evaluate와 browser_run_code_unsafe, 파일 업로드와 PDF, 네트워크 관찰, 좌표로 움직이는 원시 마우스 이벤트가 있습니다.

하지만 좁힌 것은 도구이지 브라우저 자체가 아닙니다. 그 브라우저는 이 컴퓨터의 영구 프로필을 씁니다. 로그인한 사이트의 cookie가 모두 있고, 이 컴퓨터가 닿는 네트워크, localhost와 tailnet까지 닿습니다.

그래서 무엇을 골라야 할까

• 기본은 보기만. “잠깐 봐 줘” 류의 요청은 대부분 observe로 충분합니다. 다음 Connect 버전에서는 observe가 기본 선택지가 됩니다(아직 출시 전).
• 손을 쓰게 하려면 전용 컴퓨터를 빌려주세요. Linux hands node, 쓰고 버릴 머신이나 VM이지, 지금 작업 중인 컴퓨터가 아닙니다. desktop을 고르면 대여 기간 내내 그 컴퓨터의 데스크톱 사용자 셸을 넘기는 것입니다.
• owner는 본인을 위해 남겨 두세요. 본인의 CLI에서 본인의 컴퓨터로 연결할 때 쓰는 것입니다.

업그레이드 전에

이번 변경은 호환성을 깨뜨립니다. instance-mcp v0.7.0부터:

• sandbox는 거부됩니다(HTTP 400). 조용히 다른 단계로 바꾸지 않습니다.
• Connect와 빌려줄 컴퓨터는 함께 업데이트하세요. 구 버전 Connect가 보내는 sandbox는 새 컴퓨터가 거부하고, 새 Connect가 보내는 desktop이나 observe는 구 버전 컴퓨터가 거부합니다. Connect가 아직 구 버전이라면 컴퓨터를 v0.7.0으로 올리는 것은 미루세요.
• 구 빌드가 저장한 sandbox 대여는 새 빌드가 불러올 때 버려집니다. 다시 빌려주세요.

이 모든 것 뒤에는 원칙 하나가 있습니다. 모르는 프로필을 만나면 대여를 끝낸다. 절대 owner로 넓히지 않는다.

덧붙여 v0.6.7부터, 빌려준 컴퓨터는 데몬이 재시작해도 스스로 다시 연결합니다(macOS와 Linux). 배포나 크래시 때마다 다시 빌려줄 필요가 없습니다.

다음 단계(개발 중)

• browser 단계: 브라우저 도구만 있고, 대여마다 일회용 브라우저 프로필을 씁니다. 경계는 브라우저 자체가 맡습니다.
• 타입이 있는 앱 제어: 범용 osascript 대신 bundle ID allowlist를 쓰고, Terminal, Script Editor, System Settings는 제외합니다.
• 사용자 정의 정책: 대여 시 allow / deny 목록을 함께 넘깁니다. 이것도 “셸과 동등한가” 검사를 거칩니다.
• 일회용 macOS VM 대여: 호스트 자체가 아니라.

이름은 인터페이스의 일부다

지난 글에서, 가장 먼저 나올 질문은 “무엇에 닿을 수 있는가”라고 했습니다. 에이전트가 컴퓨터를 빌려 달라고 할 때, 그 답은 당신이 고르는 프로필의 이름에 적혀 있습니다. 그러니 이름은 사실을 말해야 합니다. sandbox는 지킬 수 없는 약속을 했습니다. 우리는 그것을 desktop으로 바꾸고, 정말로 보기만 하는 선택지를 하나 더 드렸습니다.