MoltBook에 보안 이슈가 있었네요.
바이브 코딩으로 시작한 프로젝트의 약점을 보여준 부분인 것 같습니다.
문제가 발견되기 전에 다른 해킹 시도가 있었을지는 모르겠으나 누군가가 먼저 보고를 해주었고 빠르게 MoltBook 팀이 1월 31일, 2월 1일 사이에 보완한 것 같습니다.
인간의 개입으로 충분히 방지 할 수 있었던 굉장히 초보적인 보안 실수로 보여집니다.
그런데 이게 스타트업 업계에서는 사실 좀 흔해 보이긴 합니다.
스타트업에서는 제품 개발 속도와 보안을 트레이드오프하는 결정을 많이 하지요.
다만 이번 MoltBook 케이스는 폭발적인 관심사로 인해 보안 이슈로 인한 임팩트가 몇십배로 불어났다는 점이 달랐던 것 같습니다.
보안을 강화하는 것은 어찌되었든 시간과 비용을 발생시키고 제품 개발 프로세스의 단계와 복잡성을 증가시키기도 하기 때문에, 제품을 시장에서 한시라도 빨리 테스트 해야하는 스타트업 입장에서는 보안에 너무 많은 리소스를 투입하는 것은 오히려 사업 리스크로 여겨질 수 있기 때문입니다.
이 부분은 보안의 책임을 서비스 개발쪽에만 전가하기 보단 서비스 개발에 광범위하게 사용되고 있는 데이터베이스, API, SDK 등(보통 단체가 운영하는)의 기본 보안 설정이 강화될 필요는 있어 보입니다.
요즘 추세가 점점 "인간은 실수하기 때문에 개입하면 할 수록 비효율이다"라는 철학이 널리 퍼지는 부분도 조금 걱정이 됩니다.
뭔가 인간을 기계처럼 갈아 넣었던 초기 산업혁명 시기과 비슷한 냄새가 나는 것 같습니다.
결과적으로 해당 이슈는 인공지능 자체의 이슈라기 보단 안전불감을 가진 사람이 AI를 만나 더 큰 문제를 야기 할 수 있다는 사례인 것 같습니다.
다만 많은 이들이 우려하던 OpenClaw(MoltBot) 자체의 보안 이슈와는 별개 사안인걸로 보입니다.
OpenClaw는 사용자가 수동적인 설정 과정을 통해 권한을 부여하지 않는 이상 타사용자 입력을 함부로 받지는 못합니다 (에이전트한테 권한을 위임해서 "알아서 설정해!"라는 시나리오가 가능할 것 같긴 합니다만;;)
그러나 이런저러한 이유로 해당 에이전트를 퍼블릭으로 열게 된다면 (타사용자 입력 허용) 프롬프트 인젝션으로 인한 피해는 불가피 할 것 같습니다.
아무리 가드레일을 철저하게 설정한다 하더라도 어떤 연구 결과에서는 최대 98%의 성공률로 우회가 가능하다고 하니까요. 퍼블릭 서비스를 생각하고 계신다면 애초에 민감 정보를 에이전트가 직접 접촉할 수 있는 구조 자체를 피하는게 좋을 것 같습니다.
출처: Lenny's Podcast