사이버 보안

왜 AI 에이전트를 보호하는 첫 번째 계층이 에이전트 게이트웨이여서는 안 되는가?

Nik Kale은 AI 에이전트 보안이 에이전트 목록화와 식별, 위임 맥락 설정에서 시작해 운영 게이트웨이를 통한 정책 적용으로 이어지는 6개 계층의 연쇄 구조로 구축되어야 한다고 본다. 또한 제한된 권한, 귀속 가능한 로그, 포괄적인 중지 경로에 중점을 둔 실용적인 준비 상태 테스트 프레임워크를 제안한다.

2026-08-30
5 분 읽기
6 조회수
فريق تحرير certi.news
왜 AI 에이전트를 보호하는 첫 번째 계층이 에이전트 게이트웨이여서는 안 되는가?

엔터프라이즈 AI 플랫폼 및 보안 전문가인 Nik Kale은 많은 조직이 에이전트 운영 게이트웨이를 주요 통제 지점으로 삼아 시작하지만, 이러한 게이트웨이는 충분히 존재하거나 성숙하지 않은 ID 및 귀속 계층에 의존한다고 본다. 그 결과 게이트웨이는 토큰과 API 요청의 유효성을 확인할 수는 있지만, 어떤 에이전트가 요청을 실행했는지, 누가 해당 에이전트를 위임했는지, 어떤 작업을 수행하고 있었는지, 또는 요청이 신뢰할 수 없는 구성 요소에서 시작된 도구 호출 연쇄의 일부인지 항상 알 수 있는 것은 아니다.

에이전트 배포가 확대되면서 이 문제는 실질적인 중요성을 얻고 있다. 6월, 미국 사이버보안 및 인프라 보안국(CISA)은 실제 악용이 관찰된 후 LiteLLM의 취약점을 알려진 악용 취약점 목록에 추가했다. 이 취약점은 게이트웨이 자체를 통해 호스트에서 명령을 실행할 수 있게 했으며, 두 번째 취약점과 결합하면 인증 정보 없이도 악용할 수 있었다. 자료에 따르면 해당 게이트웨이에서는 한 달 동안 7개의 공통 취약점 및 노출(CVE)이 공개되었다.

보안은 단일 통제 지점이 아니라 신뢰 연쇄다

Kale은 이를 «신뢰 기반 배포»라고 부른다. 즉, 이전 계층에 요구되는 테스트를 통과하기 전에는 이후 계층을 운영상 완성된 것으로 간주하지 않는 방식이다. 통제 기능은 병행해 개발할 수 있지만, 프로덕션에서의 활성화는 명확한 순서를 따라야 한다.

  • 에이전트 목록화 및 책임 있는 소유권: 모든 프로덕션 에이전트에는 알려진 소유자, 명확한 목적, 승인된 도구, 수명 주기상의 상태가 있어야 한다.
  • 독립된 ID 및 위임 맥락: 시스템은 에이전트와 그 소유자, 그리고 에이전트가 누구 또는 어떤 주체를 대신해 작업을 수행하는지 알아야 한다.
  • 단기성·업무 한정 자격 증명: 침해된 에이전트가 위임받은 작업과 관련 없는 리소스에 접근할 수 있어서는 안 된다.
  • 귀속 가능한 측정: 작업의 시작부터 다른 시스템에 미치는 최종 영향까지 작업을 재구성할 수 있어야 한다.
  • 런타임 조치 적용: 정책 결정은 토큰의 유효성만이 아니라 에이전트의 ID, 위임 주체, 작업, 조치를 근거로 해야 한다.
  • 행동 기준선 및 시스템 전반의 중지 경로: 보안팀은 에이전트가 접근하는 모든 위치에서 에이전트의 실질적인 권한을 중지할 수 있어야 한다.

정의하고 귀속할 수 있는 것부터 시작하라

제안된 프레임워크에 따르면 첫 단계는 오픈 소스 프레임워크, 클라우드 서비스, 서비스형 소프트웨어 제품, 개발자 도구 내부에 존재하는 프로덕션 에이전트를 파악하는 것이다. 목록에는 에이전트 소유자, 책임 범위, 수명 주기 단계, 허용된 도구, 데이터 범위, 자격 증명 출처가 포함된다. 이러한 목록이 없다는 것은 단순한 문서화 문제가 아니다. 조직이 사전에 알고 있어야 할 원본을 확인하는 데 사고 대응 시간의 일부를 소모할 수 있기 때문이다.

저자는 에이전트의 ID가 개발자 코드, 공유 서비스 계정, 사용자 세션 안에 묻혀서는 안 된다고 강조한다. 호출자가 «에이전트»라는 사실만으로는 충분하지 않다. 누가 작업을 위임했는지, 구체적인 작업이 무엇인지, 에이전트가 어떤 리소스를 사용해야 하는지도 기록해야 한다. ID는 행위자를 식별하고, 위임은 에이전트가 누구의 권한으로 일하는지와 그 권한이 부여된 이유를 설명한다.

행동을 분석하기 전에 권한을 줄여라

에이전트의 ID를 확인한 후에는 시간, 작업, 도구, 작업에 필요한 리소스에 따라 능력을 제한해야 한다. 자료는 워크로드 ID, 토큰 교환, 조건부 접근, 기간이 제한된 권한과 같은 기존 ID 및 접근 관리(IAM) 시스템 기능을 활용할 수 있다고 지적한다.

Kale은 205명의 보안 리더를 대상으로 한 Teleport의 2026년 연구를 인용한다. 이에 따르면 과도한 권한의 AI를 사용하는 조직은 76%의 사고율을 보고한 반면, 최소 권한 원칙을 적용하는 조직은 17%를 보고했다. 그의 분석에 따르면 이는 접근 범위가 맥락을 인식하는 런타임 정책 적용보다 신뢰 연쇄에서 더 앞선 요인일 수 있음을 보여준다.

저자가 제시하는 원칙은 «단조 위임»이다. 모든 책임 전환은 권한을 유지하거나 줄여야 하며, 권한을 늘려서는 안 된다. 금융 조정 에이전트의 예에서는 요청한 직원이 접근할 수 있는 모든 시스템을 상속받게 하는 대신, 특정 원장을 조회할 수 있는 권한만 부여하는 것을 의미한다.

게이트웨이는 언제 실제로 유용해지는가?

운영 게이트웨이는 등록된 에이전트 ID, 명시적인 위임 맥락, 구체적인 자격 증명, 귀속 가능한 로그가 갖춰진 후에야 완전한 가치를 얻는다. 그때 게이트웨이는 에이전트가 특정 주체를 위해 특정 작업의 맥락에서 특정 리소스에 대해 특정 조치를 실행할 권한이 있는지를 평가할 수 있다. 사용자 토큰이 조정 에이전트에 쓰기 권한을 부여하는 데 유효할 수 있지만, 전체 맥락을 보면 해당 조치가 작업 범위를 벗어났다는 사실이 드러날 수 있다.

가장 엄격한 통제는 결제, 접근 정책 변경, 삭제, 프로덕션 환경 수정, 데이터 내보내기처럼 영향을 되돌리기 어려운 경계에 적용해야 한다. 행동 기준선은 에이전트 활동을 구분하고 귀속할 수 있게 된 후에 마련된다. 그때 비정상적인 도구 사용, 데이터 범위 간 예상치 못한 접근, 작업에서의 이탈을 감지할 수 있다.

중지 경로는 ID 디렉터리에서 단일 객체를 비활성화하는 데 그치지 않는다. 자료가 설명하는 완전한 중지는 에이전트 ID 비활성화, 활성 및 파생 자격 증명 폐기, 도구 실행 차단, 실행 중인 작업 종료, 에이전트가 포함된 워크로드 격리를 요구한다.

30일 내 테스트 계획

저자는 기존 ID 관리 프로그램을 교체하자고 제안하지 않는다. ID 제공자가 에이전트를 기본 자산 유형으로 처리하지 않는다면, 기존 워크로드 ID에 연결된 신뢰할 수 있는 목록에서 시작한 다음 에이전트 및 작업 식별자를 신뢰할 수 있는 실행 맥락으로 추가하고, 단기성 자격 증명을 사용하며, 이러한 식별자를 도구 호출 로그에 포함할 수 있다.

실무적으로는 10개의 프로덕션 에이전트부터 시작해 각각의 소유자, 목적, 도구, 자격 증명을 문서화할 것을 제안한다. 그다음 ID 및 로깅 시스템이 에이전트를 작업을 위임한 사람 또는 서비스와 구분하는지 테스트하고, 후속 영향을 포함해 완전한 작업을 처음부터 끝까지 재구성해야 한다. 연쇄가 끊기는 지점은 새로운 운영 적용을 추가하기 전에 해결해야 할 격차를 드러낸다.

편집부의 읽기: 이 프레임워크의 가치는 새로운 게이트웨이를 제안하는 데 있는 것이 아니라 출발점을 재배치하는 데 있다. LiteLLM에 관한 사실과 Teleport 및 Okta의 수치는 권한 축소와 귀속의 중요성을 뒷받침하지만, 제안된 계층 순서가 유일한 해법이거나 모든 엔터프라이즈 아키텍처에 적합하다는 점을 그 자체로 입증하지는 않는다. 또한 이 자료는 공식 표준이 아니라 저자의 분석이므로, 적용하려면 각 조직에 존재하는 ID, 로깅 시스템, 중지 경로의 세부 사항을 검토해야 한다.

뉴스 출처
VentureBeat Startups & Funding
원문 보기 ↗
ف
작성자

فريق تحرير certi.news

같은 카테고리

추천 기사

모든 뉴스 보기