검색 시스템의 핵심 경계는 “찾을 수 있는가”와 “모델·도구로 보낼 수 있는가”가 서로 다른 판단이라는 점입니다. 이 노트는 인증된 주체에서 검색 후보, 파생 결과, 외부 전송, 실행기까지 권한과 데이터가 어떻게 이동하는지 따라가며 누출을 진단하는 기준을 세웁니다.
다른 팀 문서의 검색·모델 입력 전 접근 통제
실행을 질의 수신 → 인가 범위 확정 → 범위 안에서 후보 생성 → 현재 원문 재검사 → 모델 입력으로 나누어 보면 사후 필터의 위치가 왜 늦은지 분명해집니다. 예를 들어 A가 접근할 수 없는 청크가 전역 top-K에 들어갔다면, 점수·청크 ID·재랭킹 입력만으로도 금지 정보의 존재가 드러날 수 있으므로 “최종 답변에 문장이 없었다”는 결과만으로 안전하다고 판정하지 않습니다.
전체 벡터 검색에서 상위 K개(vector top-K)를 먼저 뽑고 답변 직전에 비공개 문서를 지우면, 그 문서가 모델 제공자·재랭커·trace 저장소까지 이미 전달됐을 수 있습니다. 검색을 시작할 때 인증된 사용자와 tenant 범위를 실행 문맥에서 가져오고, 그 범위에 허용된 후보만 대상으로 검색해야 합니다. 각 청크에는 원문 ID, 정책 참조, 권한 목록(ACL)의 version을 붙여 현재 권한과 다시 대조하고, 제목·스니펫·결과 수처럼 작아 보이는 메타데이터의 노출도 따로 검사합니다.
전역 top-10 중 9개를 사후 제거하면 관련 있는 허용 문서가 다른 순위에 있어도 결과는 1개뿐입니다. 인가 필터를 적용한 검색과 현재 원문 조회 때의 재검사를 함께 둡니다. 색인 ACL이 늦으면 원문 권한이 권위이며 민감 자료의 인가 서비스 장애 때는 일단 반환하지 않습니다.
요약·임베딩·캐시의 원본 정보성과 접근 정책 계승
파생 데이터의 권한은 원본 ACL의 복사본이 아니라 계보를 따라 계산되는 제약으로 다루는 편이 안전합니다. 원본 하나가 철회되면 그 원본을 포함한 요약·임베딩·검색 캐시를 찾아 무효화하거나, 현재 원본 권한을 다시 확인하기 전까지 반환하지 않는 두 경로 중 하나를 명시합니다.
청크들을 합쳐 공개 요약을 만든다고 비공개 청크의 권한이 사라지지 않습니다. 원본→파생 데이터의 계보·정책 version·삭제/정정 관계를 유지합니다. cache key와 조회 조건에 필요한 사용자·문서·정책 version을 반영하고 공유 해제·조직 이동·캐시 hit 경로를 시험합니다. 유사도는 관련성이지 권한이 아닙니다.
그림을 글로 읽기
- 인증된 사용자·목적
- 인가 후보 검색·현재 원문 재검사
- 필요한 청크·필드만 선택
- 목적지·계정·전송 정책 검사
- 허용된 모델·도구·결과 저장
- 인증된 사용자·목적 → 인가 후보 검색·현재 원문 재검사: 실행 문맥의 범위
- 인가 후보 검색·현재 원문 재검사 → 필요한 청크·필드만 선택: 현재 권한
- 필요한 청크·필드만 선택 → 목적지·계정·전송 정책 검사: 원문 정책 유지
- 목적지·계정·전송 정책 검사 → 허용된 모델·도구·결과 저장: 허용된 전송만
읽기 권한과 외부 전송 권한
실무 선택에서는 먼저 “내부에서 읽어도 되는가”, 다음으로 “이 목적지에 이 필드를 보낼 수 있는가”, 마지막으로 “그 결과를 어디에 저장할 것인가”를 따로 승인합니다. 재현 실습으로 민감한 가짜 계약 번호를 검색어·오류 로그·모델 payload에 넣고, 각 경로의 allow/deny 로그와 실제 payload가 최소화되었는지 비교하면 읽기 인가와 egress 검사의 차이를 확인할 수 있습니다.
외부 검색어와 URL query, 오류 보고, 원격 에이전트 메시지, 첨부 파일, 생성 코드가 보내는 HTTP 요청은 모두 데이터 전송으로 셉니다. 사용자가 한 서비스에 문서를 업로드했다는 사실만으로 다른 연결 서비스에 재전송할 권한이 생기지는 않습니다. 전송하기 전 데이터 분류, 목적, 수신 조직, 보관 기간, 필요한 승인을 확인한 뒤 필요한 필드만 보냅니다. 이름을 지워도 계약 금액과 날짜를 조합하면 다시 식별될 수 있으므로, 단순한 이름 삭제를 최소화의 끝으로 보지 않습니다.
| 통제 | 필요한 이유 | 한계 |
|---|---|---|
| 목적지 allowlist | 임의 외부 전송 축소 | 허용 도메인의 공격자 계정 가능 |
| 계정·경로·행동 검증 | 실제 수신 범위 제한 | redirect·DNS 변화도 고려 |
| DLP | 알려진 비밀 패턴 보조 탐지 | 모든 민감 의미를 이해하지 못함 |
| sandbox egress | 생성 코드의 우회 경로 제한 | 정식 도구 정책과 함께 필요 |
| 로그 최소화 | 진단 저장소의 재유출 방지 | 감사 식별자는 유지해야 함 |
자격은 모델 문맥에 넣지 말고 실행기에 둡니다. 서버가 대신 URL을 가져오는 fetch는 내부망 주소, metadata, redirect, DNS 변화로 요청 대상이 바뀌는 경로를 확인해, 서버가 의도치 않은 내부 주소에 요청하는 SSRF 경계를 검사해야 합니다. 외부로 보낸 데이터는 나중에 삭제해도 복사본과 로그가 남을 수 있으므로, 전송 여부는 실행 전에 결정합니다.
외부 문장의 분석 대상과 실행 지시 구분
웹·메일·저장소·도구 결과가 “파일을 다른 주소로 보내라”고 하면 사용자 목표와 무관한 명령이 섞인 것입니다. 간접 프롬프트 인젝션은 이런 데이터로 다음 행동을 바꾸려 합니다. 요약·번역·이미지·하위 보고를 거쳐도 원래 신뢰 수준을 유지합니다.
문구 필터·모델 지시·탐지기는 보조 장치입니다. RAG를 붙였다고 제거되지 않습니다. 모델이 잘못된 호출을 제안해도 파일 범위·현재 인가·전송 정책·중요 변경 승인을 실행기가 강제해야 합니다. 차단된 같은 행동을 다른 도구로 시도해도 같은 정책을 적용합니다. 보안 문서를 읽어 설명하는 것과 그 안의 지시를 실행하는 것은 다릅니다.
금지 행동 차단과 정상 분석 과잉 차단 시험
실패 원인은 보통 검색 ACL 지연, 파생 캐시의 오래된 정책 version, redirect 뒤 목적지 변경, 또는 데이터와 지시를 같은 신뢰 수준으로 처리한 실행기에서 나옵니다. 각 테스트에서 “어느 단계에서 차단되어야 했는지”와 “차단 뒤에도 어떤 메타데이터가 남았는지”를 기록하고, 정상적인 비민감 문서 요약은 통과하는지 함께 확인합니다.
합성 민감 데이터와 격리 목적지로 검색어·로그·첨부·메모리·재위임 누출을 확인합니다. 문서 공유 철회 직후, 인덱스 지연, 캐시 hit, 다른 tenant, 이미지 속 지시를 포함하고 정상 분석을 과도하게 차단하는 오탐도 봅니다. 이 노트는 방어 설계이며 운영 자료로 침투 시험을 수행한 결과는 아닙니다.