Zhuhai 출신의 한 위협 행위자(threat actor)가 DeepSeek을 오픈 소스 Hermes Agent 프레임워크에 연결하고, 이를 Telegram을 통해 원격 제어 장치처럼 사용했습니다. 이 에이전트는 스스로 타겟을 찾아내고, 공개된 익스플로잇(exploit)을 가져와 인터넷에 노출된 460개 이상의 시스템을 공격했습니다. 확인된 침해 사례에는 Citrix NetScaler 시스템이 포함되었습니다.

이것은 가설이 아닙니다. 이번 주에 실제로 일어난 일입니다.

고객 유치, 리드 팔로업(lead follow-up), 또는 내부 자동화 등 AI 에이전트를 활용해 무언가를 구축하고 있다면, 이 사례를 깊이 숙고해야 합니다. 에이전트 프레임워크(Agentic frameworks)가 강력한 이유는 사용자가 모든 단계를 승인하기를 기다리지 않고 스스로 행동하기 때문입니다. 하지만 바로 그 기능이 위험 요소이기도 합니다. 과도한 권한을 가지면서 가드레일(guardrails)이 부족한 에이전트는 해킹당하지 않더라도 피해를 줄 수 있습니다. 단지 잘못된 지시만 있으면 충분합니다.

제가 현재 모든 에이전트 시스템을 구축할 때 적용하는 몇 가지 원칙은 다음과 같습니다:

권한 범위를 엄격하게 제한하십시오. 고객 유치 팔로업을 수행하는 에이전트가 귀하의 CRM 전체에 접근할 필요는 없습니다. 작업에 정확히 필요한 것만 부여하고 그 외에는 허용하지 마십시오.

에이전트가 접촉하는 모든 것을 로그(log)로 남기십시오. 에이전트가 어떤 행동을 왜 취했는지 확인할 수 없다면, 문제가 발생하기 전까지는 상황이 잘못 돌아가고 있다는 것을 알아차릴 수 없습니다.

되돌릴 수 없는 모든 작업에는 인간의 체크포인트(human checkpoint)를 유지하십시오. 검토를 위해 이메일 초안을 보내는 것은 엔드 투 엔드(end to end)로 자동화해도 괜찮습니다. 하지만 레코드를 삭제하거나 외부 시스템 호출을 하는 작업에는 일시 정지 지점이 있어야 합니다.

트리거 계층(trigger layer)을 단순한 워크플로(workflow) 단계가 아닌 보안 경계로 취급하십시오. 에이전트를 실행시키는 요소(양식 제출, 캘린더 이벤트, Telegram 메시지 등)는 제대로 잠그지 않으면 누군가가 걸어 들어올 수 있는 문이기도 합니다.

AI 시스템은 귀하의 비즈니스를 맡길 수 있는 다른 인프라와 동일한 규율을 가지고 구축될 때 제대로 작동합니다. 통제 없는 속도는 시스템이 아닙니다. 그것은 더 나은 브랜딩을 입은 노출(exposure)일 뿐입니다.

현재 에이전트 워크플로를 구축하고 있다면, 귀하의 권한 모델(permission model)은 어떤 모습입니까?