하네스는 지키는 곳이자 뚫리는 곳이다
안녕하세요! 재니미입니다.
지난 글 「하네스 안에는 뭐가 들어있나」에서 하네스를 11개 구성요소로 쪼개 보면서, 이 조각들이 조직이 통제할 수 있는 지점인 동시에 공격이 들어올 수 있는 지점이기도 하다는 이야기로 마무리했습니다. 이번 글에서는 그 지점들이 구체적으로 어떤 보안 리스크로 이어지는지, ASD·ACSC 가이드가 정리한 다섯 가지 범주를 봤습니다.
프롬프트 인젝션이 특별한 이유
가이드는 이 다섯 가지를 다루기 전에, 왜 하네스 레벨에서 막아야 하는지부터 짚습니다.
“LLMs are provided instructions and information together as context when queried. As a result, a model may have difficulty distinguishing authorised instructions from information contained within external content, creating opportunities for prompt injection and other manipulation techniques. […] This weakness underpins prompt injection attacks, for which no fully reliable technical mitigation currently exists.”
모델은 “지시”와 “그냥 처리해야 할 정보”를 같은 컨텍스트로 받습니다. 웹페이지, 문서, 이메일, 코드 주석 속에 심어진 문장도 모델 입장에서는 지시로 읽힐 수 있습니다. 이게 프롬프트 인젝션이 통하는 근본 원인인데, 가이드는 이걸 모델 안에서 완전히 막을 기술적 방법이 지금 없다고 명시합니다. 그래서 대책은 모델이 아니라 하네스 쪽, 즉 에이전트가 뭘 접근할 수 있고 뭘 실행할 수 있는지를 통제하는 쪽에서 나와야 한다는 겁니다.
다섯 가지 리스크 범주
| 범주 | 정의 |
|---|---|
| 권한 리스크 | 에이전트에 필요 이상의 접근·권한이 주어져, 한 번의 침해가 넓게 번짐 |
| 설계·구성 리스크 | 아키텍처·통합·설정이 허술해서 운영 전부터 약점이 생김 |
| 행동 리스크 | 에이전트가 의도치 않은 방식으로 목표를 추구하거나, 프롬프트 인젝션·데이터 포이즈닝 같은 방식으로 조작당함 |
| 구조 리스크 | 여러 컴포넌트·다단계 작업에 걸쳐 실패가 연쇄적으로 번져서, 원인이 어디서 시작됐는지 알기 어려워짐 |
| 책임소재 리스크 | 에이전트 시스템의 복잡성과 불투명성 때문에 결정을 추적하거나 행동을 감사하거나 책임을 물을 대상을 가리기 어려워짐 |
하나씩 지난 글의 구성요소에 대응시켜보면 이렇습니다.
- 권한 리스크는 권한 시스템이 느슨할 때 생깁니다. “명령 실행은 매번 승인받는다” 같은 규칙 없이 도구를 다 열어두면, 그 도구 하나가 뚫렸을 때 피해 범위가 그대로 전체로 번집니다.
- 설계·구성 리스크는 도구 레지스트리·실행 환경을 처음 짤 때부터 생깁니다. 도구 설명이 애매하거나 실행 환경이 프로덕션과 분리돼 있지 않으면, 운영을 시작하기도 전에 이미 약점이 박혀 있는 셈입니다.
- 행동 리스크는 컨텍스트 매니저와 맞닿아 있습니다. 검색 결과나 외부 문서를 그대로 모델에 넣어주는 게 컨텍스트 매니저가 하는 일인데, 그 내용에 악의적인 지시가 심어져 있으면 모델이 그걸 진짜 지시로 착각하는 게 프롬프트 인젝션입니다. 데이터 포이즈닝은 방향이 조금 다른데, 지금 당장의 응답을 조작하는 게 아니라 에이전트가 참고하는 문서나 메모리·세션 저장소에 미리 오염된 내용을 심어두고, 나중에 그걸 참고할 때 잘못된 판단을 하도록 유도하는 방식입니다.
- 구조 리스크는 여러 컴포넌트가 얽혀 있다는 것 자체에서 나옵니다. 2편의 예시로 치면, 모델이 파일을 검색하고(도구 레지스트리) 그 결과를 넘겨받고(컨텍스트 매니저) 코드를 고쳐 실행하는(실행 환경) 과정이 한 줄로 이어져 있는데, 이 중간 어딘가에서 결과가 살짝 잘못 전달되면 최종 실패만 보고는 정확히 어느 단계에서 틀어졌는지 가려내기 어렵습니다.
- 책임소재 리스크는 감사·관측이 부실할 때 커집니다. 활동 기록이 부족하면 “누가, 언제, 왜 이 행동을 승인했는가”를 나중에 되짚을 방법이 없습니다. 예를 들어 에이전트가 실수로 중요한 파일을 지웠을 때, 그 실행을 누가 승인했는지, 애초에 그 도구를 왜 쓸 수 있게 열어뒀는지가 로그에 안 남아 있으면 원인 규명도 재발 방지도 못 합니다.
멀티 에이전트는 한 몸으로 봐야 한다
가이드에는 경고문 하나가 따로 붙어 있습니다.
“For security purposes, a multi-agent system should be treated as a single agent, because a compromise in one component can propagate through shared context and trust relationships.”
여러 에이전트를 조합해서 쓰는 구조라도, 보안 관점에서는 “에이전트 여러 개”가 아니라 “에이전트 하나”로 취급해야 한다는 뜻입니다. 예를 들어 서브 에이전트 하나가 오염된 웹페이지를 읽고 그 내용을 요약해서 메인 에이전트에게 넘긴다면, 메인 에이전트는 그 요약이 오염됐는지 알 방법이 없이 그대로 받아들입니다. 컨텍스트와 신뢰 관계를 공유하는 이상, 하나가 뚫리면 나머지도 같이 뚫린 것으로 봐야 합니다.
다음 편에서는 이 다섯 가지 리스크에 대해 가이드가 제시한 실제 대응책과, 경영진이 물어야 할 거버넌스 질문들을 다루겠습니다.
감사합니다.