AI 에이전트, 인증만으로는 지킬 수 없는 이유

AI 에이전트의 보안 대책으로 많은 기업이 먼저 '게이트웨이'라고 불리는 통신 입구를 관리하는 도구를 도입한다. 하지만 이 게이트웨이는 보안 대책의 출발점으로 선택되기 쉬운 한편, 실제 운영에는 가장 부적합한 제어이기도 하다. 근본적인 이유는 게이트웨이가 전제해야 할 '누가 접근하고 있는가'를 식별하는 메커니즘이 많은 현장에서 아직 마련되어 있지 않기 때문이다.

이 문제가 단순한 이론이 아님은 실제 보안 사건이 보여주고 있다. 2025년 6월, 미국 사이버보안 기관 CISA는 AI 게이트웨이 소프트웨어 LiteLLM의 취약점을 '알려진 악용된 취약점' 목록에 추가했다. 이 취약점은 게이트웨이를 통해 호스트 OS 위의 명령을 실행할 수 있는 것으로, 다른 취약점과 결합하면 인증 없이 악용 가능했다. 더욱이 LiteLLM에서는 1개월 동안 총 7건의 CVE(공통 취약점 식별자)가 공개되었으며, 많은 기업이 AI 에이전트 보호의 '첫 번째 방어선'으로 선택하는 게이트웨이 자체가 심각한 공격 대상이 될 수 있음이 드러났다.

그렇다면 보안 대책은 어떤 순서로 쌓아올려야 할까. 게이트웨이에 의한 제어는 '첫 번째 수'가 아니라 '다섯 번째 제어'로 위치 지어야 한다는 견해가 있다. AI 에이전트의 보안은 의존성의 연쇄로 구성되며, 각 제어는 상류에서 생성된 문맥(컨텍스트)에 의존한다. 제어의 기반이 되어야 할 '어느 에이전트가 작동하는가' '누가 작업을 위임했는가' '어느 작업을 실행하는가' '어느 인증 정보가 사용되는가'라는 정보가 갖춰져 있지 않으면, 게이트웨이는 명백한 정책 위반만 차단할 수 있으며, 기술적으로는 허가되어 있으나 업무상으로는 부적절한 조작을 놓친다.

구체적인 위험은 다음과 같다. 예를 들어 재무 조정을 담당하는 에이전트가 본번 데이터의 레코드를 변경하려고 하는 경우, 게이트웨이는 사용자 토큰을 인증하고 API 호출을 확인할 수 있다. 하지만 그 요청이 에이전트 출발점이라는 것, 에이전트가 제한된 기능만 가진다는 것, 그리고 그 조작이 신뢰할 수 없는 외부 데이터에 의해 유발된 도구 체인의 일부라는 것은 게이트웨이에는 보이지 않는다. 인증 정보는 유효하고 API 호출도 허가되어 있는데도 불구하고, 조작의 목적과는 벗어나 있다. 비용이 드는 제어가 전체 그림의 극히 일부에만 기능하는 상태다.

또한 에이전트의 권한을 담당하는 사람의 권한 범위 내로 제한하는 것은 유효한 원칙이지만, 그것만으로는 충분하지 않다. 20개의 에이전트가 1명의 사용자 권한으로 작동하는 경우에도, 각각에 고유의 ID, 감사 로그, 행동 프로필, 만료 경로가 필요하다. 권한의 상한선을 정하는 것과 개별 귀속(어트리뷰션)을 확립하는 것은 완전히 별개의 문제다.

이 과제는 '기존 시스템에 대한 후부착'이라는 현실과도 깊이 관련되어 있다. 많은 기업에서는 이미 어떤 형태의 IAM(아이덴티티 접근 관리) 시스템이 운영 중이며, 거기에 AI 에이전트를 통합하는 순서가 문제가 된다. 이론적인 보안 성숙도 모델은 향후 필요한 제어를 나열하는 경향이 있으나, 현실의 '기존 환경에 대한 적용 순서'라는 더 어려운 질문에 답하지 못하고 있다는 지적이 있다.

AI 에이전트의 활용이 확대되는 가운데, 보안 논의는 '무엇을 도입할 것인가'에서 '어떤 순서로 쌓아올릴 것인가'로 이동하고 있다고 볼 수 있다. 게이트웨이는 중요한 제어 중 하나지만, 그것이 기능하기 위한 전제 조건——에이전트의 식별, 위임 관계의 추적, 행동 문맥의 기록——이 먼저 정비되어 있지 않으면, 실효성은 제한적이다. 에이전트의 본번 운영을 향해, 이러한 '의존성에 기초한 단계적 전개'의 관점이 향후 보안 설계에서 중요해질 것으로 본다.