OpenClaw의 '항상 허용' 기능 보안 취약점과 더 안전한 대안

OpenClaw 승인 시스템 취약점

OpenClaw의 승인 시스템은 명령어를 실행하기 전에 사용자에게 "이 작업을 수행해도 될까요?"라고 묻고, 한 번 승인하거나 항상 승인하는 옵션을 제공합니다. '항상 허용' 기능은 최근 두 건의 CVE를 통해 보안 위험으로 확인되었습니다.

구체적인 보안 문제

CVE-2026-29607: '항상 허용' 승인은 내부 명령어가 아닌 래퍼 명령어에 바인딩됩니다. time npm test를 '항상' 승인하면 시스템은 '항상 time 허용'을 기억합니다. 나중에 에이전트(또는 프롬프트 인젝션을 통해)가 time rm -rf /를 실행하면, 래퍼 명령어를 승인했기 때문에 재프롬프트 없이 실행됩니다.

CVE-2026-28460: 이 취약점은 쉘 줄 연속 문자를 사용하여 허용 목록을 완전히 우회합니다. 다른 기술이지만 결과는 동일합니다: 사용자가 자신을 보호한다고 생각했던 승인 검사 없이 명령어가 실행됩니다.

두 취약점 모두 OpenClaw 3.12+에서 패치되었지만, 더 깊은 문제는 남아 있습니다.

행동적 보안 문제

패치 후에도 '항상 허용'이라는 정신적 모델은 사용자들이 주의를 기울이지 않도록 훈련시킵니다. 처음에는 사용자들이 모든 승인 프롬프트를 주의 깊게 읽습니다. 3주차가 되면, 프롬프트가 성가시게 느껴지고 에이전트에 대한 신뢰가 쌓이면서 모든 것에 '항상'을 클릭하게 됩니다. 6주차가 되면, 사용자들은 물어보더라도 열거할 수 없는 20개 이상의 '항상' 규칙을 축적하게 됩니다.

권장 대안 접근법

원문 저자는 다음과 같이 권장합니다: 파일을 수정하거나 메시지를 보내거나 쉘 명령어를 실행하는 어떤 작업에도 '항상 허용'을 사용하지 마십시오. 대신, SOUL.md 파일에 명시적인 가드레일을 추가하세요:

"파일을 수정하거나 통신을 보내거나 쉘 명령어를 실행하는 모든 작업에 대해: 당신이 계획하는 작업을 정확히 보여주고 내 명시적인 확인을 기다리세요. 이전 승인은 이월되지 않습니다. 매번 물어보세요. 이것은 절대 타협할 수 없습니다."

이 접근법은 Telegram과 같은 인터페이스에서 '확인'을 더 많이 탭해야 함을 의미하지만, 에이전트가 프롬프트 인젝션이나 자체 환각을 통해 오래된 승인 하에 파괴적인 작업을 실행하도록 속이는 것을 방지합니다.

핵심 요점

승인 시스템은 편의 기능으로, 보안 경계로 설계된 적이 없습니다. 그에 맞게 취급하십시오.