AI 에이전트는 LLM이랑 위험 구조가 다르다, 실행 중 평가까지 필요하다는 경고

• AI 에이전트 위험은 기존 대규모 언어 모델과 다르다는 진단이 나옴

  • 김명주 인공지능안전연구소 소장이 2026 AI 세이프티 컴패스 컨퍼런스에서 발표함
  • 단순히 프롬프트에 답하는 LLM과 달리, 에이전트는 목표를 세우고 계획하고 도구를 쓰고 행동함
  • 그래서 사전 평가만으로는 부족하고 실행 단계 평가와 국제 공조가 필요하다는 주장임

• AISI는 에이전트 보안 평가 플랫폼을 직접 만들고 공격 실험을 진행함

  • 오픈소스 기반 에이전트 환경 오픈클로를 대상으로 평가함
  • 에이전트 전용 사회관계망서비스 몰트북도 실험 대상에 포함됨
  • 글로벌 주요 AI 모델을 상대로 실제 공격 시나리오를 적용함

• 오픈클로 실험에서는 모델별 방어율 차이가 꽤 크게 벌어짐

  • 공격 시나리오는 악성 명령 포함 입력, 내부 저장정보 조작, 도구 설명 조작 3가지였음
  • 모델별 평균 공격 방어율은 최고 93.9%에서 최저 53.3%까지 차이남
  • 같은 에이전트 구조라도 어떤 모델을 붙이느냐에 따라 위험 수준이 완전히 달라질 수 있다는 뜻임

• 몰트북 실험에서는 집단 선동보다 정보 유출과 자원 낭비 쪽 위험이 확인됨

  • 에이전트끼리 위험한 수준의 집단 행동이나 선동은 나타나지 않았음
  • 대신 민감정보 유출이 확인됨
  • 연산자원 낭비를 유도하는 행위도 관찰됨

• AISI는 에이전트 위험 관리 10원칙도 정리함

  • 설계·개발, 테스팅·배포, 운영·모니터링 3단계로 나눔
  • 최소 권한 부여, 추적 가능한 신원 관리, 검증된 배포가 포함됨
  • 공급망 위험 대응과 다중 에이전트 안전성도 핵심 원칙으로 들어감

• 김 소장이 강조한 포인트는 실행 중 평가임

  • 개발 단계에서 테스트를 통과해도 실제 실행 환경의 문맥이 바뀌면 행동이 달라질 수 있음
  • 에이전트는 도구, API, 메모리를 두루 쓰기 때문에 기존 코드 종속성 이상의 공급망 위험이 생김
  • 결국 국제 표준 중심의 검증 체계가 필요해질 것이라는 전망도 나옴

sequenceDiagram
    participant 사용자
    participant 에이전트
    participant 도구와API
    participant 평가시스템
    사용자->>에이전트: 목표와 작업 요청
    에이전트->>도구와API: 도구 호출과 데이터 접근
    도구와API-->>에이전트: 실행 결과와 외부 문맥 반환
    에이전트->>평가시스템: 행동 로그와 위험 신호 전달
    평가시스템-->>에이전트: 차단, 제한, 추가 검증 지시
    에이전트-->>사용자: 검증된 결과 반환

• 현장에서는 앤트로픽의 고성능 AI 모델 미토스와 프로젝트 글래스윙 관련 질문도 나옴

  • 김 소장은 미토스 대응은 과학기술정보통신부가 말하는 게 맞다고 선을 그음
  • 프로젝트 글래스윙 참여 확대에 대해서는 쉽지 않을 것 같다고 봄
  • 악용 세력에게 먼저 들어가면 혼란이 커질 수 있어서, 사회 전반 보안 역량이 올라간 뒤 공개하는 방향을 예상함

• 신속 대응책으로는 하위 버전 모델을 통한 보안 패치가 언급됨

  • 고성능 모델 전체 공개가 어렵다면 낮은 버전 AI 모델을 활용해서라도 빠르게 보안 패치를 해야 한다는 얘기임
  • 에이전트가 똑똑한지보다 안전하고 신뢰할 수 있는지가 가치 판단의 기준이 될 것이라는 발언도 나옴

기술 맥락

• 에이전트 보안에서 중요한 선택은 배포 전에 한 번 테스트하고 끝낼지, 실행 중에도 계속 평가할지예요. 에이전트는 같은 모델이라도 어떤 도구를 붙였는지, 어떤 메모리를 읽는지, 어떤 입력 문맥을 받는지에 따라 행동이 달라지거든요.

• 오픈클로 실험의 공격 시나리오가 흥미로운 이유는 전부 에이전트의 연결 지점을 찌르기 때문이에요. 악성 입력은 프롬프트 경로를, 내부 저장정보 조작은 메모리 경로를, 도구 설명 조작은 도구 호출 경로를 건드려요.

• 최소 권한 원칙이 여기서 특히 중요해요. 에이전트에게 처음부터 넓은 API 권한과 데이터 접근 권한을 주면, 작은 조작이 실제 업무 실행이나 정보 유출로 이어질 수 있거든요.

• 공급망 위험도 기존 라이브러리 의존성보다 넓게 봐야 해요. 에이전트는 코드뿐 아니라 도구 설명, 외부 API 응답, 저장된 메모리까지 근거로 삼기 때문에, 어느 레이어가 오염돼도 이상 행동으로 이어질 수 있어요.

• 그래서 사내 에이전트를 붙이는 팀은 모델 벤치마크만 보면 부족해요. 도구별 권한, 호출 로그, 실행 중 차단 정책, 배포 후 평가 체계를 같이 설계해야 실제 운영 리스크를 줄일 수 있어요.