통합 검색이 백도어가 된다
인제스트(원본 문서를 검색용으로 수집, 가공하는 과정)에서는 문서 하나가 수백 개의 청크(작은 문단 단위)로 나뉜다. 검색기는 파일 전체가 아니라, 사용자의 질문과 의미가 비슷한 청크를 찾는다.
이때 원본 문서가 가진 소유권, 공유 범위, 민감도 같은 권한 정보를 청크에 별도로 복사해야 한다. 그렇지 않으면 Microsoft SharePoint, 파일 시스템, 문서관리시스템에 있던 접근제어 정보가 검색 인덱스에서 사라진다. 여러 저장소의 청크를 한곳에 모아 검색할수록, 이 검색 시스템은 조직 전체를 가로지르는 광범위한 정보 접근 경로가 된다.
Microsoft의 검색 서비스 Azure AI Search에서는 인덱스 프로젝션(원본 문서의 속성을 하위 청크로 투영하는 기능)을 사용해 원본 문서의 사용자, 그룹 ID를 모든 하위 청크에 상속해야 한다. 이 작업을 빠뜨리면 검색 요청이 들어왔을 때 사용자의 접근 권한을 확인할 ACL(접근제어목록)이 없어져, 권한에 따른 검색 결과 필터링이 불가능해진다.
에이전트의 권한은 누구의 것인가
하나의 서비스 계정으로 모든 질의를 처리하면, 실제 사용자의 권한이 아니라 에이전트가 가진 권한의 합집합으로 검색이 실행된다. 그 결과, 정상적인 자격 증명을 가진 에이전트가 사용자를 대신해 사용자가 볼 수 없는 문서까지 가져오는 ‘혼란한 대리자(confused deputy)’ 문제가 발생한다. 일반적인 RAG에서는 이 문제가 한 번의 검색으로 끝날 수 있지만, 에이전트는 툴을 호출할 때마다 같은 문제를 반복한다. 로그에는 ACL 위반이 아니라 정상적인 검색 요청만 남는다.
실제로 허용해야 할 접근 범위는 ‘사용자의 권한’과 ‘에이전트에게 위임된 범위’의 교집합이다. RFC 8693의 토큰 교환 방식은 사용자를 주체(subject), 에이전트를 행위자(actor)로 명시해 이러한 위임 관계를 보존한다.
검색 후 청크를 버리는 사후 필터링은 해결책이 아니다. 필터가 작동할 때는 이미 민감한 내용이 프로세스 메모리, 변수, 로그, 트레이스 등에 남았을 수 있다. 모델에 인용하지 말라고 지시해도 표현의 변화, 검색 순위, 문서의 존재 여부, 점수, 응답 지연을 통한 정보 노출까지 막을 수는 없다.
따라서 접근 권한은 모델이나 애플리케이션의 사후 처리에 맡기지 말고, 서버가 인증된 사용자 세션을 기준으로 검색 단계부터 강제해야 한다. 모델이 내용을 읽었다면 이미 공개된 것으로 간주하고, 그 사실을 하나의 접근으로 기록해야 한다.
권한 철회의 속도가 보안을 결정한다
유사도 검색에는 두 겹의 권한 통제가 필요하다. 먼저 서버에서 테넌트별로 검색 범위를 제한하고, 민감한 원천을 조회할 때는 사용자의 권한을 다시 확인한다. 인덱스에는 사용자 명단 대신 group:…과 같은 권한 키를 저장한다. 질의 시점에 IdP(신원 공급자)가 현재 그룹 멤버십을 확인하면, 퇴사나 그룹 탈퇴 같은 변경 사항을 재인덱싱 없이 반영할 수 있다. Microsoft도 Microsoft Entra ID의 그룹 ID와 Microsoft Graph의 최신 멤버십 정보를 결합해 이 방식을 구현한다.
권한 정보의 동기화 간격은 곧 권한 철회 SLA다. 검색 기반 AI의 권한 누수를 다룬 연구 ConfusedPilot의 측정에서는 권한이 철회되거나 삭제된 문서가 검색 결과에 38~183초 더 노출됐다. 협업 문서 도구 Notion은 재인덱싱 중에도 검색 결과의 원문을 PostgreSQL에서 다시 읽고, 서버에서 권한을 재검사한다. 반대로 재인덱싱이 야간에만 이루어진다면, 철회된 권한이 반영되기까지 최악의 경우 하루가 걸릴 수 있다.
요약, 그래프 노드, 메모리, 시맨틱 캐시, 다이제스트, 트레이스는 원문과 별개의 새 객체다. 따라서 원문의 ACL을 자동으로 상속한다고 가정해서는 안 된다. 여러 원천에서 파생된 객체에는 각 원천 권한의 교집합을 적용해야 한다. 그렇지 않으면 접근이 제한된 문단이 공개 요약이나 캐시로 바뀌어 노출될 수 있다. 캐시 키도 테넌트, 사용자, 말뭉치 버전, 도구 설정에 종속시켜야 한다.
인가 검증은 검색 품질 지표인 NDCG(정규화 할인 누적 이득)와 분리해 수행한다. 권한이 서로 다른 사용자에게 동일한 질의를 실행하고, 접근 범위가 매우 좁은 카나리 문서를 심어 무단 노출 여부를 확인한다. 권한 변경 후에는 공표한 SLA 안에 해당 정보가 인덱스, 캐시, 트레이스에서 모두 사라지는지 검사해야 한다. 접근 거절 응답이 문서의 존재 자체를 암시하지 않는지도 확인한다. ACL이 없는 청크를 모든 사용자에게 공개하는 Elasticsearch식 ‘fail-open’ 동작 역시 이런 인가 회귀 시험으로 탐지할 수 있다.