AI 에이전트의 RAG, 권한 관리에 구조적 허점

기업용 AI 에이전트의 보급이 확대되는 가운데, 검색 확대 생성(RAG)이라 불리는 메커니즘의 권한 관리에 간과되기 쉬운 구조적 결함이 있음이 구체적인 사례로 확인되었다. 밀라노를 거점으로 하는 Microsoft 파트너 기업 SynSphere Italia의 최고경영자이자 IT 아키텍트인 Egiziago Cioffi는 자신이 구축한 Azure OpenAI 메일 어시스턴트에서 수신 이메일의 약 60%를 자동 처리할 수 있는 시스템을 개발했다. 평가 점수는 양호했으며 사내 테스트도 통과했으나, 어느 검증에서 심각한 문제가 드러났다.

Cioffi는 저권한 계정으로 어시스턴트에 문의를 하자 해당 계정이 본래 SharePoint상에서 직접 접근할 수 없어야 하는 콘텐츠가 응답에 포함되어 있음을 확인했다. 고권한 계정에 의한 문의와 저권한 계정에 의한 문의 결과가 일치한 것이다. 이는 어시스턴트가 요청을 보낸 사용자의 권한이 아닌 데이터를 인덱싱할 당시의 서비스 계정 권한으로 정보를 취득·응답했음을 의미한다. 평가 점수와 단위 테스트에는 '누구의 권한으로 정보를 반환할 것인가'라는 관점이 포함되지 않았다.

RAG란 AI가 사전에 학습한 지식뿐 아니라 사내 문서 등 외부 데이터를 실시간으로 검색하여 응답에 활용하는 메커니즘이다. 그 검색 단계에서 '누가 질문했는가'에 따른 접근 제어가 기능하지 않으면 권한이 없는 사용자에게 기밀 정보가 전달될 위험이 발생한다. Microsoft의 Azure AI Search는 2025년 5월의 프리뷰부터 문서 수준의 접근 제어 기능을 제공하기 시작했으며, SharePoint의 접근권과의 연계도 후속 프리뷰에서 추가되고 있다. 다만 이 기능이 모든 이용 경로에서 확실히 유효하게 작동하는 것은 아니다.

Microsoft의 공식 문서에 따르면 'Azure OpenAI On Your Data'에서 문서에 대한 접근권을 관리하는 필드가 올바르게 설정되지 않은 경우 문서 수준의 접근 제어는 무효화된다. 달리 말해 설정이 불완전한 경우에는 접근 제한이 '개방 상태'가 되는 사양이며, 의도하지 않게 보안 허점이 생기기 쉬운 구조가 되어 있다. Cioffi의 시스템은 Azure AI Search를 경유하지 않는 커스텀 파이프라인을 채택했으며, 쿼리 실행 시의 권한 검사는 개발자가 독자적으로 구현하지 않는 한 기능하지 않는 구성이었다.

이 문제가 개별 사례에 그치지 않음을 보여주는 데이터도 있다. AI 보안 기업 Straiker는 2025년 7월 자사의 STAR Labs에 의한 위협 보고서를 공표했다. 동 보고서에 따르면 업무용 AI 에이전트를 대상으로 실시한 1,700건 이상의 공격 실험에서 성공한 공격의 91%가 악성코드나 네트워크 내 횡단 이동을 전혀 사용하지 않고 데이터의 은폐된 유출로 끝났다. 에이전트 자체가 정보를 반환해버리기 때문에 종래형 공격 수법을 필요로 하지 않는다는 점이 특징적이다.

이 일련의 사실이 시사하는 바는 AI 에이전트의 평가 기준이 '정확하게 답할 수 있는가'에 치우치기 쉽고, '누구에게 무엇을 답해야 할 것인가'라는 권한의 관점이 뒤로 밀려나기 쉽다는 구조적 과제라고 할 수 있다. 기업이 RAG를 활용한 에이전트를 본번 환경에 배포할 때는 기능 테스트와 동등하거나 그 이상으로 접근 제어의 검증이 필요하다는 견해를 할 수 있다. 향후는 기술 선정이나 아키텍처 설계 단계부터 권한 관리를 포함하는 '보안 바이 디자인' 사고방식이 AI 에이전트 개발에서도 중요성을 더해갈 것으로 위치지어진다.

기업에 있어서의 실무적 시사는 명확하다. 평가 점수가 양호해도 그것만으로는 불충분하며, 서로 다른 권한 수준의 계정을 이용한 실제 검증이 필수적이다. 또한 이용하는 서비스의 설정 사양을 파악한 위에서 권한 검사가 실제로 기능하고 있는지를 로그 수준에서 확인하는 것이 안전한 운용의 전제가 된다. AI 에이전트의 도입이 가속화하는 현재, 이러한 보안 측면의 검증이 개발·운용 프로세스의 표준으로 정착해갈지 여부가 향후의 주목점 중 하나가 된다.