기업들이 AI 에이전트(자동으로 여러 시스템에 접속해 작업을 수행하는 AI 프로그램)를 도입하면서, 에이전트가 접근할 수 있는 데이터 범위가 새로운 보안 위협이 되고 있습니다. 티켓 시스템·CRM·공유 드라이브처럼 오랫동안 별 생각 없이 쌓아온 시스템에 수년치 민감한 정보가 담겨 있고, AI 에이전트는 사람이 몇 시간 걸려 찾을 정보를 몇 초 만에 뽑아낼 수 있습니다. 전문가는 90일 안에 에이전트가 데이터를 주고받는 경로(데이터 패스)를 먼저 파악하고, 위험도가 높은 경로부터 정책을 적용할 것을 권고합니다. 핵심은 에이전트에게 시스템 접근 권한을 주더라도 반드시 필요한 데이터만 실시간으로 걸러내는 '데이터 경로 내 정책 강제' 구조를 갖추는 것입니다.
AI 에이전트가 티켓 시스템·CRM·지식베이스 등 기업 내 다양한 데이터 저장소에 접근하면서 수년치 민감한 정보가 빠르게 노출될 수 있는 구조적 위험이 확인됨.
에이전트는 사람이 하던 정보 수집·연결 작업을 거의 즉각적으로 처리하므로, 기존에 '시간이 걸린다'는 이유로 사실상 보안 통제 역할을 했던 마찰(friction)이 사라짐. 자격증명 노출, 고객 정보 결합, 사고 이력 유출 등이 가능.
에이전트 인증(authentication)·접근 권한(authorization)은 있으나 '이 상호작용에서 어떤 데이터를 봐야 하는가'라는 데이터 거버넌스(data governance) 개념이 부재함.
1주차에는 에이전트–데이터 소스–모델–도구 간 경로를 시각화하고 민감 데이터 흐름을 측정. 가장 위험한 경로부터 런타임 정책 강제 적용. 대규모 아이덴티티 재설계나 전체 데이터 재분류 등 복잡한 작업은 후순위로 미룸.
에이전트가 시스템에 접근 권한이 있더라도, 반환된 데이터 전부가 에이전트에게 적합하다고 가정하면 안 됨. 코드 안이 아닌 데이터 경로 자체에 결정론적(deterministic) 정책 강제 포인트를 두어야 개발자의 실수에 의존하지 않는 구조가 됨.
본문
Help Net Security와의 인터뷰에서 Nol8의 CEO Kelly Herrell은 AI 에이전트가 조직 내부에서 어떤 노출 위험을 만들어내는지 설명합니다. 가장 먼저 살펴봐야 할 것은 데이터 경로(data path)입니다. 에이전트가 무엇에 접근할 수 있는지, 무엇이 컨텍스트(context)로 들어오는지, 결과물이 어디로 가는지가 핵심입니다.
티켓 시스템, CRM 플랫폼, 공유 드라이브에는 에이전트가 몇 초 만에 끌어낼 수 있는 수년치 민감한 컨텍스트가 쌓여 있습니다. 이 대화에서는 데이터 접근 제한을 위한 90일 계획, 비즈니스 팀과 보안 팀 사이의 긴장 관계, 그리고 데이터 경로에서 정책을 강제해야 하는 이유를 다룹니다.
이미 운영 중인 에이전트가 있는 조직에 들어갔을 때 가장 먼저 무엇을 확인하나요? 그 답변은 대개 노출 수준에 대해 무엇을 알려주나요?
저는 에이전트 목록을 달라고 하지 않습니다. 데이터 경로를 보여달라고 합니다.
에이전트가 무엇에 접근할 수 있는지, 어떤 데이터가 컨텍스트로 들어올 수 있는지, 어떤 도구와 모델을 호출할 수 있는지, 다른 에이전트와 통신할 수 있는지, 그리고 결과 데이터가 어디로 이동할 수 있는지를 확인합니다.
에이전트 목록은 조직이 배포했다고 믿는 것을 알려줍니다. 데이터 경로는 실제로 노출된 것을 알려줍니다. 그 둘 사이의 차이가 곧 노출 범위입니다. 그다음으로는 해당 경로를 통과한 모든 상호작용을 보여줄 수 있는지, 아니면 일부 샘플만 있는지를 물어봅니다. 답은 거의 항상 샘플입니다.
대부분의 조직은 처음 두 가지 질문, 즉 '이것이 정상적인 에이전트인가'와 '무엇에 접근할 권한이 있는가'는 답할 수 있습니다. 세 번째 질문, 즉 '이 특정 상호작용에서 에이전트가 무엇을 보고, 이어받고, 공개해야 하는가'를 답할 수 있는 조직은 거의 없습니다.
에이전트 노출 지점으로 가장 의외였던 데이터 저장소는 어디였나요?
의외인 것들이 반드시 데이터베이스는 아닙니다. 그것은 기업이 수년간 쌓아왔지만 거대하게 연결된 데이터 저장소라고 생각하지 않았던 시스템들입니다.
사람들이 가장 놀라는 것은 티켓 시스템입니다. 티켓 하나에는 아직 유효한 자격증명(credential)이 들어 있는 운영 로그(production log), 고객 계정 정보, 마지막 장애가 어떻게 발생했는지에 대한 단계별 서술이 모두 담겨 있을 수 있습니다. 그런 티켓이 수년치 쌓여 있지만, 누구도 그것을 데이터셋(dataset)으로 생각하지 않았습니다. CRM 플랫폼, 협업 도구, 공유 드라이브, 지식 베이스, 채팅 이력도 마찬가지로 민감한 기관 컨텍스트를 담고 있습니다.
역사적으로 이것들을 한데 모으려면 사람이 어디를 봐야 하는지 알고, 쿼리(query)를 작성하고, 다른 애플리케이션을 열어 손으로 연결하는 과정이 필요했습니다. 그 마찰(friction)이 보안 역할을 하고 있었습니다. 전체 그림을 조립하는 데 시간과 지식이 필요했고, 그 수고가 조용히 하나의 통제 역할을 했던 것입니다. 에이전트는 같은 조각들을 거의 즉각적으로 검색하고 연관 짓습니다. 마찰이 제거되면 통제도 함께 사라집니다.
기저 데이터가 AI가 등장했기 때문에 갑자기 민감해진 것이 아닙니다. AI가 바꾼 것은 그 데이터를 발견하고, 결합하고, 이동시키는 속도와 규모, 그리고 용이성입니다.
CISO가 90일과 소박한 예산을 주면서 에이전트 주변에 데이터 접근 제한을 설정하라고 한다면, 1주차에 무엇을 하고 무엇은 의도적으로 미루나요?
1주차는 전체 환경을 재설계하려는 것이 아니라 가시성(visibility)을 확보하는 것입니다.
에이전트, 엔터프라이즈 데이터 소스, 모델, 도구, 그리고 다른 에이전트 사이의 경로를 파악합니다. 그 경계를 넘나드는 민감 데이터의 양을 측정하고, 런타임(runtime)에서 정책을 강제할 수 있는 지점을 확인합니다.
미룰 것은 대형 구축 작업입니다. 대규모 아이덴티티 재설계, 모든 에이전트 코드 재작성, 모든 기업 데이터를 먼저 완벽하게 분류하는 것, 역할별 마스킹된 복제본(masked replica) 구축, 모든 에이전트 코드에 가드레일(guardrail) 라이브러리를 넣는 것. 이 모든 것은 위험이 아닌 에이전트와 역할의 수에 따라 규모가 커집니다.
목표는 데이터가 이동하는 지점에서 빠르게 통제를 확보하는 것입니다. 먼저 관찰하고, 가장 위험도가 높은 경로에 정책을 적용한 뒤, 적용 범위를 넓혀가십시오. 더 정교한 모든 것은 그 지점들을 보고 강제할 수 있는 능력이 먼저 갖춰진 후에야 가능합니다.
90일 안에 모든 AI 거버넌스 문제를 해결할 필요는 없습니다. 경계를 넘나드는 데이터에 대한 통제를 확립하면 됩니다.
에이전트 접근 권한에 대해 비즈니스 팀과 보안 팀이 의견이 갈리는 지점은 어디이며, 조직은 이 긴장을 어떻게 해결해야 할까요?
비즈니스 팀은 컨텍스트가 많을수록 에이전트가 유용해지기 때문에 더 많은 컨텍스트를 원합니다. 보안 팀은 접근 범위가 넓을수록 노출이 커지기 때문에 자연스럽게 접근을 제한하고 싶어합니다.
두 입장 모두 타당합니다. 실수는 이 선택을 이진법으로 보는 것입니다. 에이전트에게 시스템 접근 권한을 주거나 주지 않거나 둘 중 하나라고 보는 것 말입니다.
에이전트가 Salesforce, Jira, 또는 데이터베이스에 합법적으로 접근할 필요가 있더라도 그 시스템이 반환할 수 있는 모든 데이터를 볼 필요는 없습니다. 그것이 접근 권한(authorization)과 데이터 거버넌스(data governance)의 차이입니다.
더 나은 모델은 상호작용 내부에서 데이터 자체에 정책을 강제하는 것입니다. 민감한 필드는 에이전트별·역할별로 전송 중에 마스킹되거나 차단되고, 나머지 응답은 그대로 통과합니다. 에이전트는 비즈니스가 원하는 접근 권한을 유지하고, 봐서는 안 되는 필드는 에이전트에 절대 도달하지 않습니다. 일반적인 대안인 역할별 마스킹 데이터 복사본 유지는 역할과 에이전트가 추가될 때마다 규모가 커집니다. 이 방식은 그렇지 않습니다.
비즈니스는 에이전트를 운영에 투입하고, 보안 팀은 검증할 수 있는 통제를 얻으며, 유지할 데이터의 그림자 복사본도 없습니다. 이것이 "모든 것을 허용"과 "에이전트를 차단"이라는 두 선택지 외의 세 번째 옵션입니다.
다음 에이전트를 배포하기 전에 모든 보안 팀이 갖춰야 할 통제 하나는 무엇이며, 그것을 확신하게 된 어려운 경험은 무엇이었나요?
다음 에이전트를 배포하기 전에 조직은 에이전트 환경으로 들어오고 나가는 데이터에 대해 결정론적(deterministic) 정책 강제 지점을 확립해야 합니다. 실제로 그 강제 지점은 네 가지 조건을 충족해야 합니다. 데이터 경로 안에 위치하여 트래픽이 우회할 수 없어야 합니다. 모든 페이로드(payload)를 읽어야 합니다. 레이블이나 태그가 아닌 데이터의 내용으로 판단해야 합니다. 그리고 동일한 입력이 항상 동일한 결정을 만들어내는 결정론적 방식이어야 하며, 이것이 보안 팀이 메커니즘을 승인할 수 있게 해줍니다. 이것이 저희가 AI Data Plane이라고 부르는 계층입니다.
에이전트가 특정 시스템에 대해 인증(authenticated)되고 접근이 허가(authorized)되어 있다고 해서, 그 시스템이 반환하는 모든 데이터가 에이전트가 소비하거나 공개하기에 적합하다고 가정하지 마십시오.
인증(authentication)은 에이전트가 누구인지를 답합니다. 접근 권한(authorization)은 어디로 갈 수 있는지를 결정합니다. 데이터 거버넌스(data governance)는 어떤 정보가 경계를 넘어야 하는지를 결정합니다.
이 구분이 중요한 이유는 에이전트가 정보를 검색·결합·이동하는 속도가 우리의 통제 방식이 설계된 기준인 인간의 워크플로보다 훨씬 빠르기 때문입니다. 대안이 실패하는 것을 직접 목격하면서 확신하게 되었습니다. 각 에이전트 코드 안에 통제를 두면 모든 개발자가 그것을 호출하는 것을 기억하는 데 의존하게 되고, 어느 한 팀이 잊는 순간 실패합니다. 대신 잊는 것이 불가능한 데이터 경로 자체에 강제 지점을 두십시오.
