HookPry 논문이 짚은 AI 에이전트 하네스의 훅 업데이트 위험 | DAKER 커뮤니티
2026년 9월 3일 HookPry 관련 논문이 arXiv에 공개되었습니다. AI 에이전트 하네스의 lifecycle hooks가 세션 시작·도구 호출·파일 수정 같은 이벤트에 셸 명령을 붙이고, 그 명령은 호스트 권한으로 실행되며 LLM이 보지 못하는 시점에도 발화할 수 있다고 지적합니다. 공급망 위협 모델에서는 공격자가 플러그인 메타데이터와 lifecycle-hook 설정만 통제해도, 업데이트로 무해해 보이던 플러그인을 트로이화할 수 있습니다. HookPry는 이 경로를 체계적으로 치는 오픈소스 자동화 공격 프레임워크로, 10개 공격 목표를 구현합니다. 하네스×백엔드 25조합·종단 실행 1,000회에서 평가한 7개 하네스가 모두 침해되었고, 하네스별 성공률은 최대 92.5%입니다. Microsoft Defender recall은 0%이고, 정적 방어 3종의 합집합도 악성 아티팩트 47.5%를 놓칩니다. 오늘 팀은 훅 업데이트 신뢰 경계와 호스트 명령 허용 목록을 README에 적습니다.
에이전트 보안을 이야기할 때 모델의 응답 품질이나 프롬프트 방어에 시선이 쏠리기 쉽습니다. 그런데 이번 논문은 조금 다른 지점을 겨냥합니다. 모델이 아니라, 모델 바깥에서 돌아가는 하네스의 lifecycle-hook 업데이트 경로가 실제 호스트 명령 실행면이 될 수 있다는 점입니다.
특히 플러그인과 자동 업데이트를 함께 쓰는 팀이라면 더 지금 읽을 만합니다. 겉으로는 무해해 보이는 업데이트가 실제로는 이벤트별 셸 명령을 바꾸는 통로가 될 수 있기 때문입니다.
논문과 공개 정보 범위
논문은 2026-09-03 arXiv에 올라왔습니다. 초록은 arXiv:2609.03884에서 확인할 수 있습니다. 영문 제목은 A Blind Trust, the Bloody Thrust: When Attacker-Controlled Hook Updates Steer AI Agent Harnesses towards Malicious Behaviors입니다. 저자는 Pengxun Li, Litian Zhang, Jianwei Hou, Shujiang Wu, Song Li, Zifeng Kang, Xi Zhang입니다. PDF는 같은 번호의 pdf입니다.
이 글은 제공된 사실과 초록에서 확인한 범위만 옮깁니다. 초록에 없는 숫자나 구체 목록은 덧붙이지 않습니다.
훅 업데이트 경로가 왜 신뢰 경계가 되는가
최신 AI 에이전트 하네스는 lifecycle hooks를 통해 런타임 이벤트에 셸 명령을 바인딩합니다. 세션 시작, 도구 호출, 파일 수정 등이 대표적인 이벤트입니다. 이런 명령은 호스트 권한으로 실행되고, 설정 파일 형태로 배포되며, LLM이 직접 관찰하지 못하는 시점에도 실행될 수 있습니다.
lifecycle-hook 업데이트는 단순한 설정 변경이 아니라 호스트 권한 실행면의 변경일 수 있습니다.
논문은 하네스가 맹목적으로 신뢰하는 lifecycle-hook 업데이트 경로를 새로운 공격면으로 지목합니다. 공급망 위협 모델에서 공격자가 플러그인 메타데이터와 lifecycle-hook 설정만 통제할 수 있다면, 버전이 있는 무해한 플러그인도 업데이트 한 번으로 공격자 명령을 이벤트에 심는 통로가 될 수 있다고 설명합니다. 그 결과는 권한 상승 같은 호스트 측 악성 행동으로 이어질 수 있다고 적습니다.
이 관점은 에이전트를 쓰는 팀의 문서화 방식도 바꾸게 합니다. 단순히 어떤 플러그인을 켰는지만 적는 것으로는 부족하고, 어떤 이벤트에 어떤 명령이 연결되는지까지 남기는 것이 좋습니다.
HookPry가 보여준 평가 결과
HookPry는 이 취약점을 이질적인 AI 에이전트 하네스 전반에서 체계적으로 공격하는 오픈소스·완전 자동화 공격 프레임워크로 소개됩니다. 공격 목표는 10개입니다.
평가에서는 하네스와 백엔드 25조합, 종단 실행 1,000회가 사용되었고, 평가한 7개 하네스가 모두 침해되었다고 보고합니다. 하네스별 성공률은 최대 92.5%입니다.
평가한 7개 하네스가 모두 침해되었고, 하네스별 성공률은 최대 92.5%였습니다.
방어 측 결과도 눈에 띕니다. Microsoft Defender의 recall은 0%였고, 정적 방어 3종의 합집합도 악성 아티팩트의 47.5%를 놓친다고 보고합니다.
다만 이 숫자는 논문이 설정한 평가 환경에서의 결과로 읽는 것이 맞습니다. 특정 제품이나 현재 운영 중인 모든 환경에 그대로 대입해 일반화할 수는 없습니다. 이 글도 초록에 있는 집계만 옮깁니다.
빌더 팀이 바로 점검할 부분
팀이 먼저 볼 것은 훅 설정을 편의 기능이 아니라 호스트 권한 실행면으로 다루는 일입니다. 세션 시작·도구 호출·파일 수정에 붙은 명령을 정리하고, 업데이트 채널이 어디인지 함께 확인하면 됩니다. 플러그인 레지스트리나 자동 갱신 경로가 있다면 서명 검증 여부와 사람 승인 지점도 같이 보는 것이 좋습니다.
또 하나 중요한 점은 메타데이터만 바뀌어도 훅이 바뀌는지 확인하는 절차입니다. 사람 승인 없이 훅 업데이트가 반영된다면 위험 신호로 볼 수 있습니다. Controller와 Worker를 나눠 쓰는 구조라면 훅 수정 권한과 과제 실행 권한을 분리하는 편이 안전합니다. 한 에이전트가 자기 훅을 임의로 바꾸지 못하게 두는 방식입니다.
도구 권한과 공유 워크스페이스를 함께 쓰는 팀이라면 전역 설정을 별도 파일로 두고, 훅 실행 로그를 다른 팀원이 검토할 수 있는 위치에 두는 편이 좋습니다. 비밀키를 훅 스크립트에 넣지 않는 기본 원칙도 빠지지 않아야 합니다.
정적 스캐너 한 겹만으로는 충분하지 않다는 점이 이번 논문의 핵심 경고 가운데 하나입니다.
제출 문서와 README에 남길 내용
HookPry가 보여주는 핵심은 모델이 착한가보다, 하네스 훅 업데이트가 누구의 명령을 실행하게 만드는가에 가깝습니다. 그래서 README나 제출 문서에는 훅 이벤트 목록, 명령 허용 목록, 플러그인 서명 여부, 자동 업데이트 on/off, 호스트 권한 범위, 사람 승인 지점을 분리해 적는 것이 좋습니다.
플러그인 버전을 올릴 때마다 훅 diff를 코드 리뷰 대상으로 올리고, 메타데이터만 바뀌어도 명령이 달라지는 경우를 테스트 케이스에 넣는 방식도 유용합니다. 허용 목록에는 절대 경로, 해석기, 네트워크 호출 여부까지 적어 두면 실제 검토에 도움이 됩니다.
오픈소스 공격 프레임워크 이름을 문서에 적을 때는 재현 목적과 윤리적 사용 범위를 함께 밝히는 편이 좋습니다. 타인 시스템 무단 점검은 하지 않고, 공개 자료에는 샌드박스에서 수행한 점검 로그만 올리는 방식이 적절합니다.
이 글을 읽을 때 주의할 점
이 글은 모든 에이전트 제품이 이미 침해되었다는 실시간 경보가 아닙니다. 논문이 평가한 7개 하네스와 1,000회 실행 보고를 요약한 내용입니다.
이 글은 HookPry 사용을 권하는 공격 안내가 아닙니다. 훅 신뢰 경계를 점검하라는 보안 연구 요약입니다.
이 글은 Microsoft Defender가 모든 환경에서 무용하다고 일반화하는 글이 아닙니다. 보고된 recall 0% 실험 결과를 그대로 옮긴 것입니다.
이 글은 초록에 없는 GitHub URL이나 구체 하네스 목록을 확정하는 글이 아닙니다. 공개 정보 범위를 넘는 내용은 적지 않았습니다.
참고 자료
여러분 팀은 에이전트 하네스의 훅 업데이트와 호스트 명령 허용 목록을 어떤 방식으로 문서화하고 있나요?