AI 에이전트 보안은 모델의 답변만 검토해서는 부족하다. 에이전트는 외부 도구를 호출하고, 도구 응답을 다시 읽고, 다음 행동을 결정한다. 따라서 보안의 핵심은 메시지의 흐름을 보는 데 있다.
Deep Message Inspection은 에이전트와 도구 사이를 오가는 메시지를 검사하는 접근이다. 프롬프트, 도구 입력, 도구 응답, 후속 요청을 함께 봐야 위험한 실행을 줄일 수 있다.
어떤 메시지를 봐야 하나
검사 대상은 단순한 사용자 프롬프트가 아니다. 실제로는 사용자가 에이전트에게 보낸 요청, 에이전트가 MCP 도구에 전달한 입력, MCP 도구가 반환한 응답, 응답을 바탕으로 에이전트가 만든 다음 행동이 모두 중요하다.
예를 들어 사용자는 “최근 배포 오류를 고쳐줘”라고 말할 수 있다. 에이전트는 배포 로그를 읽고, 환경 변수 목록을 조회하고, GitHub 파일을 수정하려 할 수 있다. 이때 어느 단계까지 허용할지 검사해야 한다.
검사해야 할 위험 신호
가장 먼저 볼 것은 민감정보다. API 키, 토큰, 개인정보, 고객 데이터가 프롬프트나 도구 응답에 포함되면 외부 모델이나 로그 저장소로 흘러갈 수 있다.
두 번째는 권한 상승이다. 읽기 전용 작업으로 시작했는데 쓰기 작업이나 배포 실행으로 넘어가려 한다면 중간에서 멈춰야 한다.
세 번째는 반복 실패다. 에이전트가 같은 오류를 계속 재시도하면 비용과 장애가 생긴다. 일정 횟수 이상 실패하면 사람에게 넘기는 조건이 필요하다.
개인 자동화에서의 적용
개인 블로그 자동화에서도 작은 메시지 검사가 가능하다. Slack 메시지는 웹훅 URL을 포함하지 않은 JSON payload만 outbox에 남긴다. GitHub 발행 job도 토큰을 포함하지 않고, 파일 경로와 Markdown 내용, PR 제목만 가진다.
이렇게 하면 큐 파일이 노출되더라도 비밀값이 직접 드러나지 않는다. 또한 실패 파일을 보면 어떤 작업이 어디서 막혔는지 추적할 수 있다.
실무 체크리스트
- 큐와 로그에 비밀값을 저장하지 않는다.
- 도구 호출 전 권한 범위를 확인한다.
- 읽기 작업과 쓰기 작업을 분리한다.
- 반복 실패는 자동 재시도보다 사람 확인으로 넘긴다.
- 에이전트가 실행한 입력과 결과를 최소한의 형태로 남긴다.
Deep Message Inspection의 목적은 AI를 못 쓰게 막는 것이 아니다. 에이전트가 실제 업무 도구를 다룰 수 있게 하되, 어떤 메시지가 어떤 행동으로 이어졌는지 추적 가능하게 만드는 것이다.