샌드박스는 OpenClaw로부터 당신을 구해주지 않는다
Source: Hacker News
위에 제공된 소스 링크 외에 번역할 텍스트가 보이지 않습니다. 번역을 원하는 본문을 알려주시면 한국어로 번역해 드리겠습니다.
OpenClaw 사건 (2026)
2026년 현재, 지금까지, OpenClaw는 다음을 했습니다:
…그리고 이는 2개월 운영 후에 일어난 일입니다.
반응
(기술에 인접한) 세계가 반응하고 있습니다. 정렬되지 않은 AI에 대한 편집증이 반주류로 떠오르고 있습니다.
- X와 LinkedIn은 프롬프트 인젝션 사례와 경고를 가장한 눈에 띄지 않는 기업 광고로 가득합니다.
- 악성 인공지능에 대한 논쟁이 더 이상 눈을 굴리며 일축되지 않습니다.
- 사람들은 에이전트가 암호화폐를 소각하고, 인박스를 삭제하는 것을 보고 해결책을 찾기 시작합니다.
계속해서 떠오르는 해결책 하나: 샌드박스.
Source: …
샌드박스 – 간단한 입문
샌드박스는 새로운 개념이 아닙니다. 이는 가상화의 한 형태로, 1960년대 후반 IBM 메인프레임으로 거슬러 올라갑니다. 핵심 목표는 변함없이 다음과 같습니다:
샌드박스는 워크로드를 서로 격리하면서 각 워크로드에 전체 머신 추상화를 제공합니다.
현재 트렌드
오늘날 트렌드인 “워크로드”는 AI 에이전트입니다. 논리는 다음과 같습니다:
- 에이전트를 샌드박스에서 실행한다.
- 샌드박스가 “누출”되지 않으면, 에이전트는 파일을 삭제하거나, 암호화 지갑을 읽거나, 받은 편지함을 비울 수 없다.
- 결과: 나는 안전하다.
현실 점검
당신은 안전하지 않습니다.
- 위 사건들은 모두 직접적인 파일 시스템 접근과는 무관했습니다.
- 모든 주요 문제는 사용자가 명시적으로 에이전트에 접근 권한을 부여한 제3자 서비스와 관련되었습니다.
- 에이전트는 프롬프트 주입되었거나 자신의 지시를 오해하여 원하지 않는 행동을 수행했습니다.
- 어떤 샌드박스도 이를 방지할 수 없습니다.
샌드박스는 워크로드 격리에 뛰어나지만, 에이전트는 주로 당신으로부터 격리되어야 합니다. 여기서 샌드박스가 제공할 수 있는 보호는 다음에 한정됩니다:
- 파일 시스템 보호 –
rm -rf /같은 명령을 차단. - 네트워크 보호 – 에이전트가 접근할 수 있는 웹사이트를 제한.
두 가지 모두 유용하지만, 안전성을 보장하기에는 충분하지 않습니다.
핵심 긴장
본질적인 긴장이 존재합니다:
- 범용 에이전트의 유용성 (예: OpenClaw).
- 보안 배포가 요구하는 제한사항.
| 원하는 기능 | 보안 충돌 |
|---|---|
| 계정 접근 (예: 캘린더, 이메일) | 에이전트에게 계정 접근 권한을 부여하면 악용 가능성이 열립니다. |
| 금액 접근 (예: 식료품 주문) | 신용카드 사용을 허용하면 무단 구매가 가능해집니다. |
사람들은 OpenClaw를 초기 실제 Jarvis—아이언맨에서 토니 스타크의 삶을 대부분 관리하는 개인 비서—로 상상합니다. 그들은 OpenClaw가 다음을 수행하기를 원합니다:
- 항공편 예약.
- 임대료 협상.
- 자동차 보험 청구 처리.
기능은 존재합니다. 하이재킹 방지는 존재하지 않습니다.
What the Market Actually Needs: Agentic Permissions
우리가 필요한 것은 또 다른 샌드박스가 아니라, 에이전트를 위한 세분화된 권한 프레임워크입니다.
Goal: 에이전트에게 계정당 제한된 범위의 권한을 부여합니다.
예시:
- 신용카드를 연결하되 **…**을 허용합니다.
- 이메일을 연결하되 몇 개의 사전 승인된 주소에만 보내기/답장하기를 허용하고, 각 메시지마다 사용자 승인을 받습니다.
Current State: OAuth
OAuth는 인간 사용자를 위해 설계되었습니다. 권한의 세분화 정도가 너무 거칩니다:
- Gmail: “이메일 보내기”(단일 권한).
- GitHub: “풀 리퀘스트 만들기”(단일 권한).
- Payments: 사실상 아무것도 없음 — 전자상거래 플랫폼의 호의(및 법적 위험)에 의존하고 있습니다.
에이전트는 훨씬 더 세밀한 제어가 필요합니다.
구체적인 권한 설계
Gmail 통합
- 연락처 수준 사전 승인: 사용자는 연락처를 하나씩 검토하며 주소별로 권한을 설정합니다:
- 승인 없이 전송
- 승인 필요
- 대기열 시스템: 승인이 필요한 메시지는 대기열에 보관됩니다. 사용자가 직접 승인하면 에이전트에 콜백이 트리거됩니다.
신용카드 한도
- 실제 카드 번호를 에이전트에 절대 노출하지 않음.
- 구매당 토큰: 에이전트는 각 거래마다 일회용 신용카드 번호를 요청합니다.
- 정책 적용: 토큰은 특정 금액 및 특정 가맹점에서의 거래만을 승인합니다.
- 사용자 중재: 모든 토큰 요청은 사용자가 승인해야 하며, 이를 통해 에이전트가 실제 카드 번호를 보거나 이전 승인을 재사용할 수 없게 합니다.
이 패턴은 에이전트와 연결하고자 하는 모든 제품에 적용할 수 있습니다. 핵심 요점: 에이전트는 근본적으로 새로운 유형의 행위자이며, 새로운 인터페이스가 필요합니다.
Why This Doesn’t Exist Yet
- 다양한 권한 모델이 이메일, 금융, 소셜 미디어 등 여러 영역에 걸쳐 존재함.
- 통합 모델을 강제하는 미들웨어를 구축하기 어려움.
- 산업 전반의 표준 또는 컨소시엄 주도 API가 필요함.
The Plaid Analogy
시장이 필요로 하는 것은 차세대 Plaid—다양한 운영자를 하나의 일관된 권한 레이어로 묶는 통합 API이다.
- 금융이 논리적인 첫 전장이며, 걸린 금액이 방대하기 때문에 초기 도입에 가장 적합한 후보이다.
요약
We do not need another agent sandbox.
우리는 다른 에이전트 샌드박스가 필요하지 않습니다.
What we need is a robust, fine‑grained permission system—something akin to a “Seatbelt” for AI agents, ensuring they can act usefully while staying safely constrained.
우리가 필요한 것은 견고하고 세밀한 권한 시스템입니다—AI 에이전트를 위한 “Seatbelt”(시트벨트)와 같은 것으로, 에이전트가 유용하게 작동하면서도 안전하게 제한될 수 있도록 보장합니다.
[Seatbelt](https://eapplewiki.com/wiki/Dev:Seatbelt), [bubblewrap](https://github.com/containers/bubblewrap), or [landlock](https://docs.kernel.org/userspace-api/landlock.html), and move on. It's not enough, but neither is anything else.:::note
If you’re building an agent in today’s guardrail‑free world, then reach out to us at Tachyon to audit it for vulnerabilities.
오늘날 가드레일이 없는 세상에서 에이전트를 구축하고 있다면, Tachyon에 연락해 취약점 감사를 받아보세요.
:::