자율 에이전트를 위한 풀 리퀘스트는 없다
전통적인 보안 리뷰는 디프(diff)에 의존합니다. 누군가 풀 리퀘스트를 생성하고, 누군가 이를 검토합니다. 운영 환경의 코드는 당신이 검토한 코드와 일치합니다.
자율 에이전트는 이 모델을 깨뜨립니다.
에이전트는 런타임에 계획을 세우고 도구를 호출합니다. 커밋에 액션을 담아 배포하는 것이 아니라, 실행 중에 액션을 결정합니다. 애플리케이션 코드만 검토한다면 실제 위험을 놓치게 됩니다.
에이전트는 단순한 코드가 아닙니다. 그것은 런타임 설정입니다. 이 설정에는 다음이 포함됩니다:
• 시스템 프롬프트 • 하네스(harness) 또는 루프 • 툴 서피스(tool surface) • 메모리 및 정체성(identity) • 네트워크 송신(egress) 정책 • 컨테이너 이미지
동일한 모델을 사용하는 두 에이전트라도 이러한 설정에 따라 다르게 행동할 수 있습니다. 모델은 고정되어 있지만, 설정이 모든 것을 바꿉니다.
많은 팀이 시스템 프롬프트를 단순한 텍스트 박스 설정으로 취급합니다. 대시보드에서 이를 직접 수정하곤 합니다. 이는 실수입니다. 단 한 줄의 변경만으로도 가드레일(guardrail)을 제거할 수 있습니다. 수정 가능한 프롬프트는 검토되지 않은 코드 경로와 같습니다.
실제 사례들이 이를 증명합니다:
• 한 봇이 몇 주 동안 집주인들에게 불법적인 조언을 제공했습니다. • 프롬프트 업데이트로 인해 고객 지원 봇이 고객에게 욕설을 하기 시작했습니다. • 악성 파일이 규칙을 우회하기 위해 보이지 않는 문자를 사용했습니다.
이것은 모델의 실패가 아니었습니다. 아무도 검토하지 않은 설정 변경 때문이었습니다.
설정을 코드처럼 취급해야 합니다.
시스템 프롬프트와 하네스 설정을 버전 관리 시스템에 넣으십시오. 오직 풀 리퀘스트를 통해서만 변경하십시오. 디프를 사용하여 무엇이 변경되었는지 확인하십시오.
배포된 설정에 대해 콘텐츠 해시(content hash)를 사용하십시오. 이 해시에는 프롬프트 버전, 모델 ID, 컨테이너 다이제스트(digest)가 포함되어야 합니다. 프롬프트를 변경하면 에이전트의 정체성이 변합니다. 프롬프트를 몰래 교체할 수는 없습니다.
에이전트 서피스에 드리프트 탐지(drift detection)를 적용하십시오. 호스트만 모니터링하지 마십시오. MCP 서버 목록과 해당 에이전트의 특정 송신(egress) 정책을 모니터링하십시오.
로깅할 때 다음 두 가지를 추적하십시오:
• 결정 시점의 컨텍스트 크기: 모델이 행동할 때 얼마나 많은 정보를 가지고 있었는가? • 부모 프롬프트: 멀티 에이전트 시스템에서 호출 에이전트가 무엇을 보냈는가?
새로운 도구가 필요한 것이 아닙니다. 기존의 버전 관리와 구조화된 로깅(structured logging)을 사용하십시오. 단지 그것들을 올바른 곳으로 향하게 하기만 하면 됩니다.
시스템 프롬프트를 버전 관리하고 검토하고 있습니까? 아니면 콘솔 권한이 있는 누구나 흔적 없이 이를 변경할 수 있습니까?
Optional learning community: https://t.me/GyaanSetuAi