AI 에이전트의 '하니스'가 새로운 공격 표면으로 떠오르다

보안 책임자에게 AI 에이전트의 위험이 어디에 있는지 물으면, 대답은 거의 항상 모델 자체에서 시작된다. 탈옥으로 우회할 수 있는지, 가중치를 신뢰할 수 있는지 같은 질문이다. 하지만 이런 반응은 점점 시대에 뒤떨어지고 있다. 늘어나는 익스플로잇 시연과 독립적인 레드팀 테스트, 연구자들의 평가는 오히려 모델과 외부 세계 사이에 있는 코드를 가리킨다. 이 코드는 '하니스(harness)'라고 불리며, 모델에 도구를 부여하고 텍스트 출력을 셸 명령, 파일 쓰기, API 호출 같은 실제 행동으로 바꾼다. 많은 기업에서 이 계층은 제대로 목록화되지도, 테스트되지도, 명확한 담당 팀도 없는 상태로 남아 있다.

AI 하니스란 구체적으로 무엇인가

실무자들에게 정의를 물으면 서로 다른 방향에서 같은 개념으로 수렴한다. AI 보안 기업 제니티(Zenity)의 공동창업자 겸 최고기술책임자 마이클 바구리는 이를 모델의 '손과 다리, 눈'이라고 부른다. 모델 자체는 텍스트 토큰만 생성할 뿐이고, 이를 셸 명령이나 파일 쓰기, API 호출로 바꾸는 것이 하니스라는 것이다. SANS 인스티튜트의 최고 AI 책임자 겸 연구 책임자 롭 T. 리는 모델을 엔진에, 하니스를 섀시에 비유한다. 라쏘 시큐리티의 시니어 머신러닝 엔지니어 마이클 스로민은 이를 에이전트 애플리케이션의 전체 루프를 구동하며 모델과 도구, 사용자를 연결하는 운영체제라고 설명한다. 시스코의 디스팅귀시드 엔지니어 오마르 산토스는 가장 공식적인 정의를 제시한다. 하니스는 모델을 감싸 실제로 쓸모 있게 만드는 계층으로, 오케스트레이션, 도구 사용, 프롬프트, 맥락, 역할, 평가, 가드레일을 포함한다는 것이다. 네 가지 설명 모두 같은 문제를 가리킨다. 에이전트의 권한이 실제로 행사되는 곳이 바로 하니스다. 하니스는 모델의 추론 결과와 실제 파일 시스템, API 키, 프로덕션 데이터베이스 사이에 위치한다. 아무리 정렬이 완벽한 모델이라도, 임의의 셸 패턴을 신뢰하거나 신뢰할 수 없는 콘텐츠가 담긴 작업공간을 여러 차례 재사용하는 하니스 위에서 돌아간다면 큰 의미가 없다.

하니스가 뚫리는 세 가지 방식

노비 시큐리티(Novee Security)의 창립 엔지니어 겸 보안 연구원 엘라드 메게드는 블랙햇 USA에서 깃허브 이슈만으로 앤트로픽, 구글, 오픈AI의 공식 자동화 저장소에 침투한 과정을 공개했다. 구체적인 취약점은 업체마다 달랐다. 코드 실행, 노출된 인증정보, 그리고 하류의 더 강력한 구성요소가 재검증 없이 신뢰해버리는 주입된 명령 등이었다. 그러나 그 밑바탕에 있는 아키텍처상의 오류는 세 업체 모두에서 놀랍도록 동일했다. 한 구성요소가 보안 판단을 내리고, 체인 아래쪽의 더 강력한 구성요소가 이를 다시 검증하지 않고 그대로 신뢰해버리는 구조다. 메게드는 '이것은 모델의 실패가 아니라 신뢰 경계의 실패'라고 정리했다.

두 번째 실패 유형은 코딩 실수가 전혀 없어도 발생하는, 하니스 자체의 설계에서 비롯된다. 라쏘 시큐리티 연구진은 동일한 오픈웨이트 모델에서 하니스만 교체하고 모델과 프롬프트, 도구는 그대로 두었다. 그 결과 공격 성공률은 1%에서 24%로 상승했고, 테스트한 100개의 모델·작업 조합 중 43개에서 결과가 완전히 뒤집혔다. 스로민은 '하니스를 바꾸면 사실상 완전히 다른 에이전트를 얻게 되는 것'이라며, 기본 설정을 검증 없이 채택하는 대신 하니스와 모델을 함께 벤치마크해야 한다고 권고했다.

세 번째 취약점은 하니스의 공급망을 관통한다. 제니티의 마이클 바구리 팀은 에이전트에게 새로운 작업을 가르치는 파일인 '스킬'을 조사했고, 앤트로픽과 시스코 자체 스캐너를 포함해 시장의 모든 검사를 통과한 스킬 안에 인증정보를 훔치는 악성코드가 숨어 있는 사례를 발견했다. 악성 스킬 하나는 에이전트가 재시작할 때마다 다시 불러오는 메모리 파일에 스스로를 기록해 두었다. 스킬을 삭제해도 재설치 명령은 남아 있어, 에이전트가 다음번 실행될 때 악성코드가 다시 돌아왔다. 다른 스킬은 앤트로픽의 정식 도구로 위장해, 실행된 뒤 진짜 도구를 삭제하고 공격자의 버전으로 교체했는데, 사용자에게는 눈에 띄는 변화가 전혀 없었다. 가장 두드러진 사례는 인기 있는 오픈소스 도구를 복제해 몰래 인증정보 탈취 기능을 심은 캠페인으로, 발견되어 중단되기 전까지 약 170만 회 다운로드된 것으로 집계됐다.

• 목록화: '코파일럿', '워크플로 어시스턴트', '플러그인' 등 사내에서 다르게 불리는 것까지 포함해 프로덕션에서 돌아가는 모든 하니스를 파악한다
• 접근권 매핑: 각 하니스가 어떤 도구와 데이터에 접근할 수 있는지 확인하고, 그 권한을 필요한 최소한으로 줄인다
• 독립 테스트: 기본 설정을 검증 없이 신뢰하지 말고 하니스와 모델을 함께 평가한다

팀들은 앱, 서비스, 파이프라인, 봇이라는 단위로 사고하는 경향이 있다. 하니스는 코드 저장소와 SaaS 제품, 공급업체 설정 화면 속으로 사라져버려, 보안 자산 목록에 독립된 자산으로 나타나지 않는다.

사내에 AI 에이전트를 도입하는 기업에는 무엇이 달라지는가

코파일럿류 도구의 확장이든, 자체 개발한 자동화든, 에이전트 프레임워크든, 사내에 AI 에이전트를 배치한 기업에서 하니스는 오늘날에도 보안 자산 목록에 독립된 항목으로 거의 기록되지 않는다. 산토스는 완전한 가시성을 기다릴 필요가 없다고 조언한다. 프로덕션 시스템부터 시작하면 비교적 빠르게 60~70%의 커버리지를 확보할 수 있고, 프로토타입과 섀도 AI는 두 번째 단계로 미뤄도 된다는 것이다. 이는 고위험 자동화 시스템에 대한 문서화를 요구하는 각국 규제 흐름과도 맞닿아 있다. 에이전트의 행동을 실제로 실행하는 도구는 모델과 같은 자산 목록에 포함되어야 한다는 것이다. 구체적으로는 보안팀이 조달과 감사 과정에서 하니스를 별도의 구성요소로 취급해야 한다는 의미다. 뒤에서 어떤 모델이 돌아가든, 하니스마다 별도의 위험 평가와 별도의 패치 주기를 두고, 최소 권한 원칙에 따라 접근 권한을 설정해야 한다.