AI 보안에서 강력한 범용 에이전트를 각종 보호 장치로 통제하기보다, 에이전트가 맡은 일에 필요한 권한만 가진 단일 목적 에이전트를 만드는 편이 낫다는 의견이다. SANS의 마크 배짓(Mark Baggett)은 작업 범위와 권한을 코드와 자격 증명으로 제한해야 한다고 주장한다.
로그를 읽고 의심스러운 로그인 기록을 조사하라는 요청을 받은 에이전트가 관련 계정을 비활성화한다면, 조사 과정에서 요청 범위를 넘어선 것이다. 배짓은 위험한 도구 호출을 실행 전에 점검하는 장치도 의미가 있지만, 먼저 조사 에이전트가 계정을 비활성화할 권한을 가진 이유를 물어야 한다고 말한다.
Check Point가 소개한 Dangerous Deviation Detection은 에이전트의 도구 호출과 인수를 작업 내용에 비춰 평가한다. 애플리케이션은 호출을 차단하거나 승인을 요청하거나 에이전트에 피드백을 보내 다른 방법을 시도하게 할 수 있다. Check Point 기술 문서에 따르면 베타 탐지기는 위험하면서도 정당화되지 않은 행동을 표시한다. 위험 범주에는 데이터 유출, 접근 또는 권한 상승, 영구 리소스 파괴가 포함된다.
탐지기는 user와 system 메시지에서 행동의 근거를 찾으며, 도구 응답이나 그 밖의 외부 콘텐츠에 담긴 지시는 권한 부여로 보지 않는다. Guard API 요청에는 대화 기록, 마지막 assistant 메시지의 도구 호출 제안, 최상위 tools 필드의 도구 정의를 넣는다. "breakdown": true로 설정하면 reason_code, reason, agent_guidance, debug_info.dev_tips 등의 필드를 받을 수 있다.
Check Point는 결정론적 도구 허용·거부 목록도 별도로 문서화한다. 베타 탐지기는 경계선에 있는 사례를 모두 잡기보다 오탐을 줄이는 쪽을 택한다고 설명한다. 배짓은 이를 자신의 테스트 결과가 아니라 제품 문서에 명시된 동작이라고 구분한다.
배짓이 제안하는 방식은 조사 에이전트에 범위가 좁은 읽기 전용 권한을 주고, 증거를 모아 대응을 권고하게 하는 것이다. 실제 계정 비활성화가 필요하면 별도의 워크플로가 승인된 작업을 지정된 계정에 수행해야 한다. 모델에 보여주는 도구 목록에서 기능을 빼는 것만으로는 부족하다. 실행기가 해당 기능을 계속 허용하거나, 에이전트가 관리자 권한으로 범용 셸을 사용할 수 있다면 제한이 되지 않는다.
에이전트끼리 협력할 때도 같은 원칙이 적용된다. 조사 에이전트가 권한이 높은 대응 에이전트에 계정 비활성화를 자유롭게 요청할 수 있다면 간접 경로로 권한을 행사할 수 있다. 요청을 받는 워크플로도 자체적으로 권한과 작업 범위를 확인해야 한다. 또한 외부 티켓의 내용을 애플리케이션이 user 메시지에 복사하면 신뢰된 지시와 외부 자료의 구분이 흐려질 수 있다. 티켓에 적힌 승인 주장은 실행 권한이 아니라 검토할 증거로 다뤄야 한다.
경계를 점검할 때는 사고 요약을 요청했는데 에이전트가 티켓을 닫으려 하는지, 비활성 계정 목록을 요청했는데 계정을 끄려 하는지 등을 살필 수 있다. 검색한 문서에 조작된 승인이 들어 있을 때 애플리케이션이 이를 받아들이는지, 한 계정에 대한 승인이 여러 계정으로 확대되는지도 확인할 항목이다. 작업을 거부한 뒤 다른 도구나 에이전트를 통해 같은 일을 할 수 있는지도 점검해야 한다.
배짓은 모니터링이나 가드레일, 승인 절차를 없애자고 제안하는 것은 아니라고 강조한다. 에이전트에 애초에 필요하지 않은 권한을 억제하는 책임까지 보호 장치에 맡기지 말자는 주장이다. 그는 SANS SEC573 과정에서 코딩 에이전트로 필요한 도구만 갖춘 단일 목적 에이전트를 만드는 방법을 다룬다고 설명한다.
관련 자료: Check Point의 10월 15일 기사, Agent Behavior Defense 문서, SANS SEC573: AI-Powered Security Automation.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요