RAG 2.0 보안 – Microsoft·Meta의 전략, QueryPie가 연결한다

1. 서론: 왜 RAG 2.0인가, 그리고 무엇이 달라졌는가?

1.1 RAG의 부상과 구조적 허점

Retrieval-Augmented Generation (RAG)는 생성 AI의 새로운 활용 방식으로 자리 잡고 있습니다. RAG는 대형 언어 모델(LLM)이 사전 학습된 정보에 의존하는 한계를 넘어서, 외부에서 검색한 문서나 데이터베이스 기반 지식을 실시간으로 프롬프트에 삽입하여 응답의 정확성과 최신성을 극대화합니다. 이로 인해 GPT-4나 Claude, Gemini와 같은 고도화된 모델 조차도 자체 지식만으로는 대응하기 어려운 기업 내부 질의에 높은 정확도로 응답할 수 있게 되었습니다.

그러나 이러한 구조적 진보는 동시에 새로운 보안 위협을 초래합니다. 특히 멀티테넌트 환경에서 여러 사용자가 동일한 벡터 인프라나 프롬프트 체인을 공유할 경우, 접근 권한을 초과한 문서가 검색되어 프롬프트에 삽입되고, 결과적으로 민감한 정보가 권한 없는 사용자에게 전달될 수 있습니다. 이는 단순한 프롬프트 설계 실패가 아니라, LLM 이전 단계에서 발생하는 검색 및 주입 흐름의 통제 실패로 인해 생기는 구조적 결함입니다[1].

• 벡터 인프라**(Vector Infrastructure)**

  • 문서, 지식, 로그 등의 비정형 데이터를 임베딩(embedding)하여 벡터 형태로 저장하는 시스템 구성
  • RAG에서는 사용자의 질문이 이 벡터 공간에서 가장 유사한 문서를 검색하기 위해 사용됩니다.
  • 주로 Pinecone, Weaviate, Qdrant, FAISS 등의 벡터DB가 활용됩니다.

• 프롬프트 체인**(Prompt Chain)**

  • 검색된 문서를 LLM에 전달하기 위한 일련의 프롬프트 구성 절차
  • 전체 흐름: 사용자 질문 → 문서 검색 → 프롬프트 주입 → 응답 생성
  • 일반적으로 LangChain, LlamaIndex 및 AutoGen과 같은 프레임워크에서 체계적으로 정의됩니다.

기존 IAM(Identity and Access Management) 기반 인증 또는 RBAC(Role Based Access Control) 중심의 권한 관리 체계로는 이러한 흐름을 완벽히 통제할 수 없습니다. 특히 벡터 검색은 정형 쿼리가 아닌 유사도 기반 추론에 의존하기 때문에 결과가 불안정하고 예측 불가능하며, 메타데이터 필터링이 누락되면, ACL이 존재하더라도 실제 응답 흐름에서는 무시되는 결과로 이어질 수 있습니다. 이에 따라 RAG 보안을 단순 문서 격리 수준에서 실행 시점 보안 제어(runtime security control)로 확장해야 한다는 주장이 힘을 얻고 있습니다[2].

1.2 실험 기반 위협 시나리오: Kenny 사례

QueryPie는 이러한 구조적 보안 취약성을 내부 실험을 통해 구체적으로 검증하였습니다. 다음은 해당 실험 중 가장 대표적인 위협 시나리오로 정리된 "Kenny 사례"입니다.

실험 기반 사례: Kenny와 Brant의 연봉 정보 유출

[그림 1] 실험 기반 시나리오: Kenny 사례

1. 상황 구성

   • Kenny: 보안팀 소속으로, 프로젝트 회의록과 연봉 정보가 포함된 문서를 사내 Confluence에 업로드
   • Brant: 개발팀 소속으로, "최근 입사자의 연봉 범위는?"이라는 질문을 사내 RAG 기반 에이전트에 전송
   • 시스템 구조: 인증은 되어 있으나, 검색 시 user_id 기반 메타데이터 필터 미적용

2. 위협 경로

   • a. Brant의 질문이 벡터 검색을 유도함
   • b. Kenny 작성 문서가 유사도 기준으로 선택되어 프롬프트에 삽입됨
   • c. 해당 문서의 연봉 정보 요약이 포함된 응답이 LLM을 통해 생성되어 Brant에게 반환됨
   • d. Brant는 자신의 접근 권한을 초과하는 민감 정보를 전달받음

3. 원인 분석

   • 문서 메타데이터(user_id)는 존재했으나, 검색 API 계층에서 필터링 미적용
   • 세션 기반 권한 분기 미구현
   • 프롬프트 주입 전 컨텍스트 제어 부재

벡터 DB에 정보가 저장되는 방식 - 문서 인덱싱 및 벡터화

1. 원문 분할 (Chunking)

• 긴 문서는 문단 또는 의미 단위로 잘게 쪼갬 (예: 500~1000 tokens)
• Kenny의 Confluence 문서가 여러 조각으로 나뉨

2. 임베딩 생성 (Embedding)

• 각 조각은 임베딩 모델(예: OpenAI, Cohere, BGE 등)을 통해 고차원 벡터로 변환됨
• 예: vector = embed("해당 문서 조각 내용")

3. 벡터와 메타데이터 결합 후 저장

벡터와 함께 다음과 같은 메타데이터가 JSON 형태로 결합되어 저장됨:

{
  "vector": [0.12, -0.45, ..., 0.33],
  "metadata": {
    "doc_id": "CONF-2024-001",
    "user_id": "kenny",
    "department": "security",
    "upload_time": "2024-03-11T08:15:00Z",
    "sensitivity": "confidential"
  }
}

4. 벡터 DB 저장 (Vector Database Storage)

• 이러한 결합된 벡터와 메타데이터는 Pinecone, Weaviate, Qdrant 또는 FAISS와 같은 벡터 DB에 저장됨

메타데이터가 연결되는 방식 - 벡터와 별개가 아닌 ‘결합 구조’

• 대부분의 벡터 DB는 벡터 + 메타데이터를 일체형 객체로 다룸
• 예: Weaviate의 Object 단위, Pinecone의 Item, Qdrant의 Point
• 따라서 저장 시 메타데이터는 검색 조건 필터링에 사용 가능

예시 – Kenny의 문서 저장 구조

검색 시 작동 방식 - Brant의 질의가 처리되는 과정

1. 사용자 입력 → "최근 입사자의 연봉 범위는?"
2. 임베딩 생성 → 쿼리 벡터가 생성됨
3. 벡터 유사도 검색
4. 필터링 미적용 → Kenny의 문서가 결과에 포함됨
5. Top-K 유사 문서 선택 → 프롬프트로 삽입
6. LLM 응답 생성 → 민감한 데이터가 Brant에게 전달됨

핵심 문제: 필터 조건 미적용

이상적인 구조라면 아래와 같이 세션 기반 동적 필터가 작동해야 함:

results = vector_db.search(
    vector=query_vector,
    top_k=5,  // 유사도가 가장 높은 5개
    filter={
        "user_id": {"$eq": "brant"},
        "sensitivity": {"$ne": "confidential"}
    }
)

하지만 Brant는 권한 기반 필터 없이 유사도 기준으로 Kenny의 문서를 받아보게 됨

이 사례는 보안 사고가 LLM의 응답 생성 단계가 아닌, 그 이전의 벡터 검색 및 문서 삽입 단계에서 이미 결정된다는 점을 분명히 보여줍니다. 모델이 잘못 생성한 것이 아니라, 시스템이 권한이 없는 문서를 프롬프트에 허용한 것이 문제의 핵심입니다[2].

1.3 RAG 2.0의 등장: 정적 검색 기반(static retrieval-based structure)에서 실행 시점 보안 제어(runtime security control)로의 전환

이러한 문제의식 속에서 등장한 것이 바로 RAG 2.0입니다. RAG 1.0이 임베딩, 검색, 삽입, 응답이라는 고정된 4단계 처리 구조로 구성되었다면, RAG 2.0은 다음과 같은 보안 중심의 실행 기반 평가 흐름을 지향합니다:

RAG 2.0 보안 모델의 주요 구성 요소는 다음과 같습니다.

• 세션 기반 정책 평가(Session-based policy evaluation)
• 프롬프트 삽입 전 메타데이터 필터 적용
• 실행 흐름 중간의 권한 분기 및 차단
• 응답 근거의 추적(Explainable provenance)
• 사용자/문서/컨텍스트 단위의 ACL 통합 관리

이러한 통제 요소는 기존의 인증/인가 시스템 외부에서 처리되는 것이 아니라, LLM 호출 전후의 실행 시점(runtime)에서 보안 정책이 동적으로 평가되어야 하며, 이를 통해서만 진정한 의미의 데이터 보안 격리를 실현할 수 있습니다. RAG 2.0의 핵심은 검색과 응답 사이의 정책 흐름 통합이며, 이는 단순 접근제어가 아닌 프롬프트 구성 권한의 분기와 검증을 포함합니다[3].

1.4 실행 시점 보안 제어(runtime security control)의 필요성: 누가 무엇을, 언제 어떤 문서를 참조할 수 있는가?

앞서 살펴본 바와 같이, RAG 2.0 환경에서는 단순한 정적 필터링이나 사용자 인증만으로는 보안 통제가 완성되지 않습니다. 사용자가 무엇을 요청했는지뿐 아니라, 그 요청에 대해 어떤 문서가 언제, 누구에 의해 제공되었는지를 동적으로 평가할 수 있어야 합니다. 이른바 실행 시점 보안 제어(runtime security control)가 요구되는 이유입니다.

실제로 Microsoft, Meta, 그리고 QueryPie와 같은 기업들은 각기 다른 방식으로 이러한 문제에 접근하고 있으며, 실행 기반 정책 통제 구조를 점진적으로 내재화하고 있습니다. 이들의 구조는 상이해 보이지만, 공통적으로 “모델이 답을 생성하기 전에, 어떤 정보가 포함될 수 있는지를 평가한다”는 보안 철학을 공유하고 있습니다.

이러한 전략적 흐름과 구현상의 차이는 5장에서 상세히 분석합니다. 이 백서의 후반에서는, 단일 정책 통제 계층을 구축하기 위한 기술적 접근법과, 실행 흐름을 제어할 수 있는 정책 구성 조건을 구체적으로 제시할 예정입니다.

2. 멀티테넌트 RAG 보안 아키텍처 구현 사례

2.1 실행 기반 사례 개요: 멀티테넌트 RAG 환경에서의 사용자 격리 실패

RAG는 일반적으로 문서 임베딩, 벡터 검색, 프롬프트 삽입, 응답 생성의 단계를 따릅니다. 이 중 벡터 검색과 프롬프트 삽입 단계는 외부 문서를 다루기 때문에, 사용자 권한을 기반으로 정보 흐름을 통제하지 않으면 데이터 유출 위험이 매우 높아집니다.

특히 멀티테넌트 SaaS 환경에서는 여러 조직 또는 사용자의 문서가 동일한 벡터 저장소와 인프라에서 공존하며, 각 사용자 세션이 검색 요청을 보낼 때 실행 시점의 권한 평가가 수행되지 않으면, 비인가 정보가 다른 사용자에게 노출될 수 있습니다.

이러한 구조에서 발생하는 핵심 문제는 사용자 기반 접근 통제(User-level Authorization) 가 누락된 상태에서 벡터 유사도 기준만으로 문서가 선택되어, LLM 프롬프트에 비인가 문서가 포함된다는 점입니다.

결과적으로, RAG 보안의 핵심은 LLM 응답이 아닌, 그 이전 단계인 검색 및 문서 삽입 계층에서의 권한 제어에 달려 있으며, 이는 세션 기반 사용자 격리(Session-based User Isolation) 없이는 실현될 수 없습니다.

다음은 이 문제를 해결하기 위해 실제 기업과 오픈소스 프로젝트들이 어떤 구조적 접근을 하고 있는지를 보여주는 구현 사례들입니다.

2.2 Microsoft: API 게이트웨이 기반의 테넌트 라우팅 및 메타데이터 필터

Microsoft는 Azure OpenAI 기반 멀티테넌트 RAG 솔루션에서, 사용자 인증과 문서 접근 제어를 단일 API 게이트웨이 계층에서 처리하는 구조를 구현하고 있습니다. 이 구조는 단순히 질의를 전달하는 것이 아니라, 실행 시점에서 사용자의 세션 정보를 기반으로 벡터 검색 대상과 결과 문서를 동적으로 통제합니다.

사용자가 RAG 요청을 보낼 경우, API Gateway는 먼저 OAuth 토큰을 검증하고 사용자의 테넌트를 식별한 후, 해당 테넌트 전용 벡터 저장소로 요청을 라우팅합니다. 공용 저장소에 접근하는 경우에도 user_id, tenant_id, access_scope 등 메타데이터 조건을 바탕으로 검색 결과를 필터링하여 민감 문서가 프롬프트에 삽입되지 않도록 설계되어 있습니다. 선택된 문서와 생성된 응답은 모두 감사 로그로 저장되며, 실행 보안과 감사 가능성을 함께 확보합니다 [7].

이러한 아키텍처는 API Gateway → Orchestrator → Vector DB → LLM → Logging이라는 일련의 흐름 속에서 실행 시점 접근 통제(runtime policy enforcement)를 실현한 대표적 사례입니다.

다이어그램: Microsoft RAG 보안 흐름 구조

[그림 2] Microsoft RAG 보안 플로우

핵심 제어 기능 테이블

2.3 AWS: S3 기반 Knowledge Base 내 메타데이터 필터링과 논리적 분리 구조

AWS 환경에서는 멀티테넌트 RAG 시스템을 구현할 때, S3 버킷을 중심으로 단일 Knowledge Base를 구성하되, 내부적으로 메타데이터 기반 필터링과 논리적 분리(logical partitioning)를 결합하여 보안 경계를 구성합니다.

S3에 저장된 문서들은 x-amz-meta-* 형식의 커스텀 메타데이터를 통해 tenant_id, access_level, classification 등의 정보를 부여받습니다. 이후 RAG 검색 요청이 들어오면, SageMaker 또는 Bedrock 기반의 오케스트레이션 계층에서 쿼리 벡터와 함께 IAM 인증 정보 또는 JWT를 추출하여, 권한 조건을 만족하는 문서만 검색 대상으로 설정합니다.

공통 벡터 DB(예: Amazon OpenSearch 또는 Kendra)를 사용하더라도, 문서 접근은 메타데이터 조건에 따라 동적 필터링되며, 이는 단일 저장소를 사용하되 논리적으로 테넌트를 분리하는 효과를 가집니다. 따라서 문서가 공유 저장소에 존재하더라도, 각 사용자 또는 조직은 자신이 접근할 수 있는 문서만을 대상으로 벡터 검색 및 프롬프트 삽입을 수행하게 됩니다.[8]

이 구조는 실제 인프라 분리를 하지 않더라도 멀티테넌시 보안을 구현할 수 있는 메타데이터 기반 논리 경계(LBAC: Label-Based Access Control) 모델로 간주됩니다.

다이어그램: AWS S3 기반 멀티테넌시 RAG 구조

[그림 3] AWS 멀티테넌트 RAG 아키텍처 with S3

핵심 제어 기능 테이블

2.4 LlamaIndex: 메타데이터 기반 필터링의 간결한 구조

LlamaIndex는 Search-to-Generate 아키텍처를 기반으로 하면서도, 매우 단순하고 명확한 방식으로 메타데이터 기반 보안을 구현합니다. LlamaIndex의 핵심 특징은 각 문서 조각(chunk)을 인덱싱할 때 metadata={"user_id": ..., "department": ..., "access_level": ...} 형식의 키-값 구조로 저장하고, 검색 시 이 필드를 활용해 필터 조건을 적용하는 방식입니다.

이 구조는 복잡한 IAM 시스템이나 외부 권한 서비스 없이도, 단일 Python 애플리케이션 내에서 사용자 세션 정보에 따라 권한 평가를 수행할 수 있도록 구성되어 있습니다. 세션에서 유추된 user_id 또는 role 값에 따라 쿼리 필터가 동적으로 생성되며, LLM에 전달되는 문서는 항상 해당 조건을 만족하는 조각으로 제한됩니다.

또한 LlamaIndex는 벡터 검색 엔진(Faiss, Weaviate, Qdrant 등)과 유연하게 연동되며, 검색 결과와 메타데이터가 결합된 형태로 반환되어 결과 필터링 로직을 매우 단순하게 유지할 수 있습니다.

공식 데모에서는 서로 다른 사용자가 동일한 질문을 입력하더라도, 각 사용자는 자신이 업로드한 문서에 기반한 응답만 받을 수 있으며, 권한이 없는 문서는 검색 단계에서 제외됩니다. 이는 프롬프트 주입 이전에 메타데이터 필터 조건을 강제 적용함으로써, 매우 직관적이고 경량화된 실행 시점 제어(runtime enforcement)를 실현한 대표 사례입니다 [9].

다이어그램: LlamaIndex의 메타데이터 필터링 구조

[그림 4] LlamaIndex의 메타데이터 기반 필터링

핵심 제어 기능 테이블

2.5 Pinecone & Weaviate: 벡터 인프라 단에서의 구조적 분리

상용 벡터 데이터베이스인 Pinecone과 Weaviate는 멀티테넌시 보안을 보장하기 위해 벡터 인프라 계층에서의 구조적 분리(structural isolation) 전략을 채택하고 있습니다. 이러한 구조는 벡터 검색 요청에 별도의 정책 평가가 없어도, 아키텍처 수준에서 데이터 간 격리를 선제적으로 수행할 수 있다는 특징을 가집니다.

Pinecone은 하나의 인덱스 안에서 namespace 단위를 설정하여, 각 고객 또는 조직별로 독립된 저장 공간을 구성합니다. 벡터 검색 시 클라이언트는 특정 namespace를 명시해야 하며, 다른 namespace의 데이터에는 접근할 수 없습니다. 이는 저장소 수준에서의 하드 격리(hard isolation) 구조를 통해 보안을 달성합니다.

Weaviate는 데이터 저장 구조를 shard 단위로 구성하며, 각 테넌트의 데이터를 독립적인 샤드에 저장합니다. 검색 질의는 해당 샤드에만 라우팅되도록 구성되어 있으며, 중앙 설정 없이도 물리적 분리에 준하는 논리적 분리를 실현할 수 있습니다 [10].

이러한 방식은 정책 엔진 없이도 사용자 간 정보 경계를 보장할 수 있으며, 수천 개 이상의 테넌트를 동시에 운영하는 SaaS 환경에서 확장성과 성능을 확보할 수 있는 벡터 인프라 설계 전략으로 주목받고 있습니다.

다이어그램: Pinecone & Weaviate의 벡터 기반 멀티테넌시 구조

[그림 5] Pinecone & Weaviate의 벡터 기반 멀티테넌시

핵심 제어 기능 테이블

2.6 Meta: 프롬프트 삽입 전 컨텍스트 기반 필터링

Meta는 자체 LLM 실험 및 오픈 리서치를 통해, 프롬프트 삽입 단계에서의 실행 시점 정책 적용을 강화하고 있습니다. 이는 단순한 벡터 유사도 기반 검색을 넘어서, 사용자 세션 정보와 문서의 컨텍스트 속성을 함께 고려하는 PBAC (Purpose-Based Access Control) 구조로 해석됩니다.

Meta는 정확한 내부 구현을 공개하지 않았으나, 여러 발표와 리서치 활동을 통해 다음과 같은 구조가 추론 가능합니다.

1. 문서 저장 시 access_scope, confidentiality, created_at 등의 컨텍스트 기반 메타데이터 필드가 포함됨
2. LLM 프롬프트를 생성하기 전에, 세션 정보(user, role, query context) 와 비교하여 삽입 가능한 문서를 정책적으로 선별함
3. LLM 응답에는 참조된 문서의 ID 또는 요약 해시가 함께 기록되어, 사후 감사가 가능함

이 구조는 Microsoft나 QueryPie의 RAG 보안 전략과 유사하게, 프롬프트 삽입 직전의 실행 시점 보안 평가(runtime enforcement) 를 통해 민감 정보 노출을 사전에 방지합니다. 특히, LLM이 응답을 생성하기 전에 정책을 적용함으로써, 사후 필터링이 아닌 사전 제어 중심의 설계가 실현된 구조로 평가됩니다 [11].

다이어그램: Meta의 컨텍스트 기반 PBAC 흐름

[그림 6] Meta의 컨텍스트 기반 PBAC 플로우

핵심 제어 기능 테이블

2.7 실무적 시사점과 기술적 과제

앞서 분석한 Microsoft, AWS, Meta, LlamaIndex, Pinecone, Weaviate 사례는 서로 다른 인프라 구조를 기반으로 하지만, 프롬프트 삽입 이전의 실행 흐름 통제가 RAG 보안의 핵심이라는 점에서 공통된 전략적 방향성을 보여주고 있습니다. 특히 RAG 2.0 환경에서는 단순한 권한 설정만으로는 정보 유출을 방지할 수 없으며, 질문-문서-응답으로 이어지는 동적 실행 흐름에 보안 정책이 실시간으로 적용되어야 합니다.

실무적 시사점

• 프롬프트 삽입 시점의 조건 평가가 보안 통제의 핵심: Most LLMs generate 대부분의 LLM은 전달받은 문서를 바탕으로 응답을 생성하므로, 어떤 문서가 프롬프트에 삽입되는지가 보안 통제의 마지막 방어선이 됩니다.Microsoft와 Meta는 이 지점을 PBAC (Purpose-Based Access Control) 정책 적용 지점으로 활용하고 있으며, 프롬프트 구성 이전 단계에서 사용자의 목적, 세션 속성, 문서 메타데이터를 종합적으로 평가합니다.

• 실행 흐름은 다단계 제어 구조로 구성: RAG 시스템은 질의 임베딩, 벡터 검색, 문서 필터링, 프롬프트 구성, 응답 생성이라는 일련의 실행 흐름을 따릅니다. 이러한 각 단계는 서로 다른 시스템 계층에서 작동하기 때문에, 보안 통제 역시 단일 지점이 아니라 각 계층별로 반복적이고 누적적으로 수행되어야 합니다. 예를 들어, LlamaIndex는 검색 시점에 필터를 적용하고, Meta는 프롬프트 구성 직전 단계에서 정책 평가를 수행합니다.

• 벡터 인프라 수준의 격리도 효과적인 보안 수단: Pinecone과 Weaviate는 실행 흐름 중간에 별도 정책 엔진을 두지 않더라도, namespace 또는 shard 단위의 구조적 저장소 분리를 통해 고객 간 데이터를 논리적으로 격리합니다. 이는 대규모 멀티테넌시 환경에서 정책 기반 평가가 어려운 경우에도 효과적인 보안 모델로 기능합니다.

• 정책 표현은 ACL을 넘어 CBAC·PBAC으로 확장되어야 한다: 단순한 ACL (Access Control List) 기반 문서 접근 제어만으로는 실행 흐름 통제를 실현하기 어렵습니다. 사용자의 세션 속성, 질의 목적, 요청 시점, 문서 상태 등을 통합적으로 평가하는 CBAC (Context-Based Access Control) 및 PBAC 모델이 필요하며, Meta는 이 구조를 내재화하고 있습니다.

• 정책 정의보다 정책 반영이 보안의 본질: 많은 조직이 정책 정의서는 보유하고 있으나, 그것이 실제 실행 흐름 내에서 어디에서, 어떻게 반영되는가에 대한 구조는 미흡한 경우가 많습니다. 보안 통제는 선언 그 자체가 아니라, 정책의 실행 반영 여부에 따라 성립합니다.

기술적 과제

실행 흐름 기반 보안을 안정적으로 구현하기 위해서는 다음과 같은 기술적 과제를 해결해야 합니다.

전략 요약

이상의 분석을 통해, 다음과 같은 전략적 통찰을 도출할 수 있습니다:

• 프롬프트 삽입 통제가 실행 흐름 보안의 핵심 지점입니다.
• 사용자 세션 정보와 문서 메타데이터를 기반으로 실시간 정책 평가가 수행되어야 합니다.
• PBAC (Purpose-Based Access Control), CBAC (Context-Based Access Control), ACL (Access Control List)은 통합적으로 설계되어야 합니다.
• 정책은 선언형 문서가 아니라, 실행 흐름 내에서 동적으로 반영되어야 실효성을 가집니다.

3. 실행 흐름 통제를 위한 보안 전략 설계 원칙

3.1 전략의 전제: 실행 흐름을 통제하지 않으면 보안은 무력화된다

앞서 살펴본 다양한 기업과 프레임워크(Microsoft, Meta, AWS, LlamaIndex, QueryPie)는 각기 다른 방식으로 멀티테넌트 RAG의 보안을 구현하고 있습니다. 그러나 이들 사례가 지향하는 궁극적인 목표는 하나입니다. 모델이 어떤 정보를 바탕으로 응답을 생성하는지를 실행 흐름의 각 단계에서 통제할 수 있어야 한다는 것입니다. 벡터 임베딩, 검색, 프롬프트 구성, 모델 호출, 응답 반환이라는 RAG의 실행 경로 중, 하나라도 보안 통제가 누락되면 ACL은 사실상 무력화됩니다. 특히 LLM은 의도한 바 없이 포함된 정보를 응답에 녹여내기 때문에, 프롬프트 삽입 전 단계에서의 통제가 가장 중요한 보안 지점이 됩니다.

이러한 구조적 배경 위에서, 실행 흐름 기반 보안 전략은 다음 세 가지 질문에 대응할 수 있어야 합니다:

• 질문자는 누구인가 (세션 기반 사용자 맥락)
• 질문 맥락은 무엇인가 (목적, 시간, 자원 조건 등)
• 삽입 가능한 문서는 어떤 조건을 만족해야 하는가 (메타데이터 기반 제약 조건)

3.2 실행 흐름 보안을 구성하는 5대 원칙

실제 보안 설계에서 실행 흐름을 통제하기 위해 요구되는 기술 전략은 다음의 5가지 원칙으로 정리할 수 있습니다. 이 원칙들은 플랫폼과 프레임워크에 관계없이, RAG 2.0을 구현하기 위한 보안 최소 기준이라 할 수 있습니다.

원칙 1. 세션 기반 정책 평가 (Session-based Policy Evaluation)

사용자의 인증 토큰 또는 세션 ID는 단순 인증에만 사용되는 것이 아니라, 정책 평가의 핵심 컨텍스트 정보로 사용되어야 합니다. 프롬프트 생성 이전 단계에서 현재 사용자의 권한 수준, 역할, 속성 등을 반영한 정책 평가가 이루어져야 하며, 이를 통해 “어떤 문서를 어떤 질문에 삽입할 수 있는가”를 실시간으로 결정해야 합니다. Microsoft, Meta, QueryPie는 모두 이 구조를 구현하거나 지향하고 있습니다[9].

원칙 2. 메타데이터 기반 문서 필터링

임베딩된 문서에는 user_id, tenant_id, security_level, document_type 등 다양한 메타데이터가 포함되어야 하며, 벡터 검색 시 반드시 필터링 조건으로 활용되어야 합니다. 이 과정은 코드 상에서 개발자가 누락할 수 있는 부분이기 때문에, 정책 계층에서 이를 강제하거나 API 프록시에서 래핑 구조로 감싸는 방식이 추천됩니다[10].

원칙 3. 실행 흐름 중간의 분기 (Mid-Pipeline Branching)

검색된 문서를 프롬프트에 삽입하기 전, 정책 평가 결과에 따라 분기 또는 차단이 가능해야 합니다. 예를 들어, 사용자가 질문한 카테고리(예: "성과평가")가 특정 문서 분류와 충돌하거나, 요청 시점이 허용된 시간대가 아닐 경우 삽입이 거부되어야 합니다. 이를 통해 동적 상황 변화에도 유연한 대응이 가능합니다.

원칙 4. 실행 경로의 추적 가능성 (Traceable Path Evaluation)

모든 실행 흐름은 로그로 구성된 실행 트레이스로 남아야 합니다. 단순 로그 수준이 아니라, 어떤 질문에 어떤 문서가 삽입되었고, 어떤 조건 하에서 정책이 통과 혹은 차단되었는지를 시각화 가능하도록 구성하는 것이 좋습니다. 이는 보안 감사 및 설명 가능성 확보에 중요하며, 특히 금융·공공·의료 산업에서 요구됩니다[11].

원칙 5. 응답 결과와 입력 경로의 연계 (Provenance Binding)

모델이 반환한 응답은 “어떤 문서를 기반으로 생성되었는가”를 명시적으로 표현할 수 있어야 하며, 응답 내부에 참조 문서 ID나 시그니처를 포함하는 방식으로 구현됩니다. 이는 사용자가 결과를 신뢰하게 하고, 동시에 추후 사후 감사나 의도치 않은 정보 유출의 경로를 역추적할 수 있게 해줍니다.

3.3 실행 흐름 보안 전략의 아키텍처적 정리

다음 도식은 위 원칙들을 기반으로 구성된 실행 시점 보안 제어(runtime security control)의 개념적 구조를 요약한 것입니다.

[그림 7] 실행 플로우 보안 아키텍처

3.4 구조적 설계를 무력화하는 공격 시나리오의 실현 가능성

지금까지 정리한 5대 전략은 보안 아키텍처의 설계 기준입니다. 그러나 현실에서는 단순히 설계 미비가 아닌, 의도적 우회, 정책 누락, 세션 오용 등의 방식으로 실행 흐름이 우회될 수 있습니다.

이러한 위협은 단순한 기술적 취약점이라기보다는, 프롬프트 삽입 구조와 정책 평가 흐름 사이의 단절을 노리는 방식으로 나타납니다. 따라서 보안 설계는 "무엇을 허용할 것인가?"라는 정책 선언을 넘어서, "실제로 그 허용이 지켜지고 있는가?"를 증명할 수 있어야 합니다.

다음 장에서는 이러한 시나리오를 구체화하여 분석합니다. Kenny 사례 외에도, 다음과 같은 공격 경로를 중심으로 실현 가능한 5가지 시나리오를 제시합니다:

• 연봉 정보와 같은 인사 데이터 유출
• 접근 불가한 문서의 인용 요약
• 팀 외 문서 기반의 허위 응답 생성
• 세션 공유를 통한 권한 확장
• 문서 만료 정책 미적용으로 인한 과거 기록 노출

4. 구조적 설계를 우회하는 위협 시나리오 분석

4.1 시나리오 기반 위협 분석의 필요성

앞서 살펴본 실행 흐름 기반 보안 전략은 설계 원칙의 관점에서는 충분히 강력해 보이지만, 실제 운영 환경에서는 설계와 구현 사이의 공백, 또는 예외 조건 처리의 누락으로 인해 위협이 현실화될 수 있습니다. 특히 RAG 시스템은 벡터 검색, 문서 삽입, 프롬프트 구성, 응답 반환이라는 일련의 흐름이 존재하며, 각 단계가 기술적으로는 분리된 구성 요소로 관리되기 때문에, 보안 제어 지점 사이의 틈이 공격 포인트가 될 수 있습니다.

본 절에서는 실행 흐름 기반 보안 전략이 어떻게 우회될 수 있는지를 보여주는 5가지 시나리오를 제시합니다. 이 시나리오는 모두 실제 기업 내부 테스트, 실무 운영 사례, 또는 보안 커뮤니티에서 제기된 구조적 취약성에서 파생된 것으로, 기술이 아닌 정책의 맹점에서 발생하는 정보 유출 가능성을 보여줍니다.

4.2 시나리오 1: 문서 메타데이터 필터 누락으로 인한 연봉 정보 노출

상황 요약

• 사용자는 "최근 입사자의 연봉 수준은?"이라는 질문을 RAG 기반 사내 에이전트에 입력합니다.
• 시스템은 해당 사용자의 세션 정보를 확인했지만, 벡터 검색 시 user_id 조건이 필터에 적용되지 않았습니다.
• 결과적으로 다른 부서의 기밀 문서가 검색되어 프롬프트에 삽입되고, 연봉 정보가 요약된 형태로 응답됩니다.

보안 원칙 위반 지점

• 원칙 2: 메타데이터 기반 필터링 누락
• 원칙 3: 실행 흐름 중간 분기 없음

실현 가능성 평가

• 벡터DB에서 필터 조건이 개발자가 수동으로 넣어야 하는 구조일 경우 실수로 누락되기 쉽습니다.
• API 계층이 정책 평가 기능을 갖추고 있지 않다면, 이런 필터링 누락은 복구하기 어렵습니다[12].

4.3 시나리오 2: 팀 외부 문서의 인용 응답 생성

상황 요약

• 한 개발자가 "신제품의 디자인 철학은 무엇이었나?"라는 질문을 합니다.
• LLM은 검색 결과 중 디자인팀이 작성한 문서의 요약 내용을 포함해 응답합니다.
• 해당 문서는 공개 문서이지만, 질문자의 세션 맥락에서는 접근 권한이 없는 문서입니다.

보안 원칙 위반 지점

• 원칙 1: 세션 기반 정책 평가 누락
• 원칙 5: 응답-출처 연계 없음

실현 가능성 평가

• 많은 시스템이 문서의 "공개" 상태에만 기반하여 접근을 허용합니다.
• 하지만 RAG 환경에서는 문맥 상 “누가 질문했는가”에 따라 동일 문서도 응답 삽입 여부가 달라져야 합니다[13].

4.4 시나리오 3: 세션 공유 또는 에이전트 클로닝(복제)을 통한 권한 상승

상황 요약

• 사용자 A가 승인된 세션 토큰을 사용자 B와 공유하거나, 내부 RAG 에이전트를 개인 작업 공간으로 복제합니다.
• 복제된 에이전트는 통합된 정책 집행(PDP 등)이 없지만, 여전히 원래 구성으로 검색을 수행하여 B의 범위를 벗어난 문서에 접근합니다.

보안 원칙 위반 지점

• 원칙 1: 세션 기반 평가 미적용
• 원칙 4: 실행 경로 추적 없음

실현 가능성 평가

• 복제된 워크플로우에서 프록시나 PDP(Policy Decision Point: 정책 결정 지점)가 이식되지 않으면 정책이 전혀 적용되지 않습니다.
• 특히 LangChain, LlamaIndex 기반 에이전트는 쉽게 복제 가능한 구조를 갖고 있어 우회가 용이합니다[14].

4.5 시나리오 4: 문서 만료 및 기밀도 정책 미적용

상황 요약

• 3년 전 임원의 퇴사 관련 문서가 벡터 저장소에 남아 있으며, 최근 질의에서 높은 유사도로 검색됩니다.
• 해당 문서는 이미 폐기 대상으로 분류되었지만, 시스템은 임베딩된 벡터에 대한 수명 정책을 고려하지 않습니다.
• 결과적으로 모델은 오래된 내부 이슈를 기반으로 오해의 소지가 있는 답변을 생성합니다.

보안 원칙 위반 지점

• 원칙 2: 메타데이터 필터링 (유효기간/기밀등급 미적용)
• 원칙 3: 정책 기반 분기 없음

실현 가능성 평가

• 대부분의 벡터DB는 TTL(Time-To-Live) 정책을 기본 지원하지 않으며, 임베딩 수명에 대한 명시적 만료 제어가 어렵습니다[15].

4.6 시나리오 요약

4.7 실행 흐름 보안 우회 위협이 제시하는 과제

이상의 시나리오는 단순한 정책 선언이나 인증 구조만으로는 보안성을 담보할 수 없음을 보여줍니다. 각 시나리오에서 발생한 위협은 보안 정책이 시스템의 실행 흐름에 적용되지 않거나, 프롬프트 구성 경로에 정확히 연동되지 않은 경우에 발생합니다.

이제 이러한 위협 시나리오를 기반으로, 실제 기업들이 어떠한 방식으로 실행 흐름을 제어하고 있는지를 살펴볼 필요가 있습니다. 특히 Microsoft, Meta, 그리고 QueryPie는 보안 정책을 설계 선언 수준이 아니라 실행 경로 내에 통합하고 있으며, 이를 위해 PBAC(Purpose-Based Access Control: 목적 기반 접근제어), CBAC(Context-Based Access Control: 문맥 기반 접근제어), ACL(Access Control List: 접근제어 목록), PDP(Policy Decision Point: 정책 결정 지점)와 같은 정책 구조를 복합적으로 적용하고 있습니다.

다음 절에서는 이들 세 기업이 RAG 2.0 보안 구현을 위해 선택한 전략과 아키텍처적 접근을 비교 분석합니다.

5. 실행 흐름 통제 전략 비교: Microsoft, Meta, QueryPie

5.1 비교 목적: 선언형 정책에서 실행 흐름 통합으로

앞서 제시한 위협 시나리오는 단순히 보안 정책이 부재해서 발생한 것이 아니라, 정의된 정책이 실행 흐름에 통합되지 않았기 때문에 발생한 것입니다. 특히 RAG(Retrieval-Augmented Generation) 환경에서는 문서가 언제, 어떤 맥락에서, 누구에 의해 프롬프트에 삽입되는지가 보안 통제의 핵심 지점이 됩니다. 이는 단순한 RBAC 수준의 통제로는 해결할 수 없습니다.

Microsoft, Meta, 그리고 QueryPie는 이러한 실행 흐름 보안에 대해 각기 다른 전략으로 접근하고 있습니다. Microsoft는 Graph API와 Copilot 게이트웨이를 중심으로 API 계층에서의 정책 평가 구조를 구현하였고[16], Meta는 LLM 프롬프트 직전 단계에서 세션 기반 문맥 조건(Context-Based Access Control, CBAC) 을 반영하여 문서 삽입 여부를 동적으로 평가합니다[17]. 한편, QueryPie는 RAG 시스템 자체는 제공하지 않지만, RAG를 포함한 다양한 외부 LLM 시스템의 실행 흐름을 제어할 수 있는 정책 실행 계층(MCP Agent PAM) 을 제공합니다[18].

QueryPie의 접근 방식은 다양한 RAG 솔루션 앞단에서 정책을 평가(PDP), 실행(PEP), 정보 수집(PIP) 할 수 있는 독립적이고 확장 가능한 보안 아키텍처를 제공한다는 점에서 Microsoft 및 Meta와 차별화됩니다. 이는 곧 QueryPie가 단일 벡터DB나 단일 에이전트에 종속되지 않고, 멀티테넌트 환경의 다양한 실행 흐름에 정책 기반 보안 계층을 덧씌울 수 있다는 것을 의미합니다.

본 장에서는 이들 세 기업의 실행 흐름 통제 전략을 다음과 같은 5가지 요소를 중심으로 비교합니다:

• PBAC (Purpose-Based Access Control) 정책 적용 위치
• CBAC (Context-Based Access Control) 구현 방식
• ACL 연동 구조의 범위와 유연성
• PDP(PIP/PEP 포함) 구성 위치 및 형태
• 확장성 및 실행 흐름 통제 범위

이러한 비교는 단순한 기능의 유무가 아니라, 정책이 실행 경로 내 어디에 존재하고, 어떻게 반영되는지를 기준으로 분석합니다. 정책은 문서로 존재하는 것이 아니라, 실행 경로 내에서 실질적으로 평가되고 집행되는지를 기준으로 분석되어야 합니다. 본 절에서는 실행 흐름에 통합된 정책 구조의 구현 여부를 중심으로 각 사례를 비교하겠습니다.

5.2 Microsoft: Graph 기반 정책 조건, API 계층에 결합된 PDP 구조

Microsoft는 Copilot 및 Azure OpenAI 기반의 멀티테넌트 환경에서, Microsoft Graph API를 통해 사용자 권한, 문서 메타데이터, 협업 맥락을 통합 관리합니다. 이 데이터는 API Gateway 계층에 연동된 PDP(Policy Decision Point) 역할의 보안 로직에 의해 실시간으로 평가되며, 결과적으로 프롬프트 삽입 여부를 제어합니다[19].

이 구조는 다음과 같은 실행 흐름 통제 방식을 따릅니다:

• 사용자의 질의가 Copilot API를 통해 전달되면, Microsoft Graph를 통해 해당 사용자의 조직 내 권한, 협업 대상자, 업무 목적 등의 정보가 수집됩니다.
• API Gateway는 이 정보를 바탕으로 사용자의 질의 목적(Purpose)을 추론하고, 연관 문서의 접근 허용 여부를 평가합니다.
• 허용된 문서만 프롬프트에 삽입되며, 삽입 내역과 응답은 감사(Audit) 시스템에 저장됩니다.

Microsoft의 방식은 PBAC(Purpose-Based Access Control) 구현에서 가장 명확한 예시 중 하나로, 조직 내 역할과 업무 목적에 따라 문서 노출을 동적으로 통제합니다. 또한 CBAC(Context-Based Access Control) 요소로는 사용자 세션의 시점, 디바이스, 위치 등을 조건으로 활용하고 있습니다. 이와 같이 세션 기반 맥락 정보가 문서 메타데이터와 결합되어 프롬프트 삽입 정책이 동작하게 됩니다.

ACL(Access Control List) 연동 구조 측면에서는 Microsoft 365 기반의 문서 권한 체계와 긴밀하게 연결되어 있어, 기존의 SharePoint, OneDrive, Teams 등의 권한 구조를 그대로 활용할 수 있습니다.

한편, Microsoft의 PDP 구조는 Copilot API Gateway에 집중되어 있는 중앙집중형 형태로 설계되어 있습니다. 이는 기업 내부 시스템과의 연계에는 적합하지만, 조직 외부의 다양한 RAG 구성 요소와 연결하거나 사용자 정의 정책을 동적으로 확장하기에는 유연성이 다소 제한될 수 있습니다.

Microsoft의 실행 흐름 통제 구성 요약

Microsoft의 보안 아키텍처는 전사적 자원과 보안 정책이 일관된 체계 안에서 운영될 수 있다는 장점이 있습니다. 다만 실행 흐름 외부에서 API를 통해 들어오는 이기종 RAG 시스템이나 LLM 워크플로우와의 연결성은 제한적이므로, 다중 시스템과의 통합 보안 제어에는 추가 구성이 요구됩니다[20].

5.3 Meta: LLM 프롬프트 전 문서 삽입 흐름에 CBAC 내장

Meta는 자사의 LLM 운영 환경에서 프롬프트 구성 직전 단계에서의 정책 평가 구조를 강조합니다. 이는 단순히 사용자 인증 기반으로 접근을 제어하는 것이 아니라, 세션 맥락(Session Context)과 문서의 컨텍스트(Context Metadata) 를 결합하여 문서 삽입 가능 여부를 실행 시점에서 정책적으로 판단하는 구조로 구현되어 있습니다[21].

Meta는 일반적으로 다음과 같은 실행 흐름을 따릅니다:

1. 사용자가 질문을 입력하면, 세션 ID 및 사용자 역할(Role), 세션 목적(Purpose) 등의 정보가 내부 평가 로직에 전달됩니다.
2. 검색된 문서들에는 access_scope, confidentiality, created_at 등과 같은 메타데이터가 포함되어 있으며, 이는 세션 컨텍스트와 비교 평가됩니다.
3. 삽입 가능성이 있는 문서 중, 정책 조건을 만족하는 문서만 프롬프트에 전달됩니다.
4. 생성된 응답에는 참조된 문서의 해시 또는 문서 ID가 첨부되어, 사후 감사 및 추적이 가능하도록 설계되어 있습니다.

이러한 구조는 Context-Based Access Control (CBAC) 의 대표적인 구현 사례로, 사용자의 실행 맥락에 따라 동적으로 문서 접근 가능 여부를 제어합니다. 또한 문서의 목적 태그나 분류 등 추가 조건이 포함되는 경우에는 PBAC(Purpose-Based Access Control) 로 확장되어 동작합니다.

Meta는 내부 ACL 모델을 기반으로 문서-사용자 권한을 미리 정의하며, 실행 시점에는 CBAC 정책 로직이 이를 기반으로 문서 삽입 조건을 재평가합니다. 이러한 구조는 Microsoft와 유사한 방식으로 동작하지만, 프롬프트 구성 직전의 내부 오케스트레이션 계층에서 정책이 평가된다는 점에서 차별화됩니다.

한편 Meta의 구조는 대부분 자체 플랫폼에 내장된 형태로 운영되며, 외부 SaaS 환경이나 다양한 RAG 구성요소와 연계 가능한 범용 API를 제공하지는 않습니다. 따라서 정책 유연성이나 외부 연동성 측면에서는 제한적인 부분이 존재합니다.

Meta의 실행 흐름 통제 구성 요약

Meta의 보안 전략은 실행 시점 평가 중심 구조로 설계되어 있으며, 특히 LLM이 응답을 생성하기 전에 정책을 통해 문서 삽입을 제어한다는 점에서 보안 효과가 높습니다. 하지만 내부 환경에 최적화된 설계로 인해 확장성은 제한적이며, 다양한 RAG 에이전트나 멀티 클라우드 환경에서 동일한 구조를 재현하기는 어렵다는 한계도 존재합니다[22].

5.4 QueryPie: OPA 기반 정책 모델로 실행 흐름 전체를 계층 분리 제어

QueryPie는 자체적인 RAG(검색-생성) 기능을 제공하지 않지만, 다양한 LLM, 벡터 DB, 프롬프트 체인 앞단에 배치되어 실행 흐름 전체를 통제할 수 있는 보안 계층(MCP Agent PAM) 을 제공합니다. 이 구조는 QueryPie가 단순한 인증/인가 솔루션이 아닌, 정책 기반 실행 보안 아키텍처로 기능한다는 점에서 Microsoft 및 Meta와 구분됩니다[23].

QueryPie의 핵심 전략은 OPA(Open Policy Agent) 기반의 정책 모델을 중심으로 한 PDP(Policy Decision Point), PEP(Policy Enforcement Point), PIP(Policy Information Point) 계층 분리를 전제로 구성되어 있습니다. 이 구조는 다음과 같은 방식으로 실행 흐름을 제어합니다:

1. 사용자의 요청은 MCP Agent PAM의 프록시 계층(PEP) 을 통해 수신됩니다.
2. 프록시는 요청의 세션 정보, 사용자 역할, 질의 목적, 시간, 리스크 수준 등을 추출한 후 PDP에 전달합니다.
3. PDP는 사전에 정의된 정책 파일(ai-policy.yaml 또는 JSON 형태)을 기반으로 평가를 수행하며, 이 때 PBAC/PBAC/ACL 조건을 결합한 객체 기반 평가가 이루어집니다.
4. 정책에 부합하지 않는 경우 삽입이 차단되며, 모든 흐름은 실행 로그로 정형화된 트레이스 형태로 저장됩니다.

QueryPie는 특히 다양한 접근제어 모델을 하나의 구조로 통합할 수 있는 유연성을 갖추고 있습니다:

• ABAC(Attribute-Based Access Control): 문서 속성, 사용자 속성 등 메타데이터 기반
• ReBAC(Relationship-Based Access Control): 문서-사용자 간 조직적 관계 기반
• RiskBAC(Risk-Based Access Control): 시간, 위치, 세션 위험도 등 동적 조건 반영

이러한 구조는 단순히 정책을 평가하는 것을 넘어, 정책이 실행 흐름에 정확히 반영되고 있는지를 보장하는 실행 기반 정책 관리로 기능합니다. 또한 QueryPie는 Meta, Microsoft와 달리 다양한 RAG 솔루션과 동시에 연동 가능한 통합 보안 계층으로 기능할 수 있다는 장점이 있습니다. 예를 들어 LangChain, LlamaIndex, AutoGen 등 서로 다른 에이전트 프레임워크를 사용하는 환경에서도, QueryPie는 공통의 프록시 계층을 통해 정책 적용을 일괄적으로 수행할 수 있습니다.

QueryPie의 실행 흐름 통제 구성 요약

QueryPie는 실행 흐름 제어 강도와 확장성에서 가장 강력한 구조를 제공하며, 다수의 에이전트, 다수의 백엔드와 연결되는 RAG 운영 환경에서 실행 시점 정책 통제의 중심 계층으로 기능할 수 있습니다. 특히 보안 정책의 충돌 탐지, 관리자 승인 삽입, 거버넌스 기반 정책 버전 관리 등의 기능도 내장되어 있어, 단일 RAG 솔루션에 국한되지 않고 보안 계층 전체를 독립적으로 구현할 수 있는 장점을 가집니다[24].

Microsoft, Meta, QueryPie의 실행 흐름 통제 구조

[그림 8] 실행 플로우 비교

5.5 비교 요약 표: 실행 흐름 통제 전략 매트릭스

아래 표는 Microsoft, Meta, QueryPie가 어떻게 실행 흐름 내에서 보안 정책을 통제하는지를 비교한 것입니다. 각 항목은 보안 전략의 핵심 구성 요소(PBAC, CBAC, ACL), 정책 실행 계층의 위치(PDP/PEP/PIP), 프롬프트 삽입 시점의 통제 여부, 그리고 다양한 RAG 시스템과의 연동 가능성에 따라 평가됩니다.

Microsoft, Meta, QueryPie 실행 흐름 통제 전략 비교 요약

QueryPie는 실행 흐름 내에서 정책 적용 위치의 독립성과 유연성 측면에서 우위에 있으며, PBAC/CBAC/ACL을 단일 정책 표현으로 통합할 수 있는 구조를 제공합니다. 특히 다양한 RAG 플랫폼과의 연결 가능성과 정책 버전 관리, 감사 로그 분리 저장 등의 기능은 실행 기반 보안의 핵심 요구사항을 충족시키는 요소로 작용합니다[25].

5.6 QueryPie의 역할: RAG가 아닌 RAG 보안을 위한 통합 제어 솔루션

QueryPie는 RAG(Retrieval-Augmented Generation) 시스템을 자체적으로 제공하지 않지만, RAG 기반 LLM 환경의 보안을 보장하기 위한 실행 흐름 통제 계층으로 설계되어 있습니다. 따라서 본 백서에서는 QueryPie를 RAG 솔루션이 아닌, 멀티 RAG 환경을 대상으로 하는 통합 보안 제어 솔루션으로 분류하며, Microsoft 및 Meta와의 전략적 비교 대상에 포함하였습니다.

QueryPie는 MCP Agent PAM이라는 정책 실행 계층을 통해, 프롬프트 삽입 이전의 모든 흐름에서 PDP(Policy Decision Point), PEP(Policy Enforcement Point), PIP(Policy Information Point) 구조를 구성하고 있으며, 실행 시점의 정책 평가를 다음과 같은 방식으로 수행합니다:

• PaC(Policy as Code): ai-policy.yaml 또는 JSON 기반의 정책 파일을 기준으로 실행 흐름 조건을 정의합니다.
• PBAC(Purpose-Based Access Control): 사용자의 요청 목적을 기반으로 문서 삽입 여부를 결정합니다.
• CBAC(Context-Based Access Control): 세션, 디바이스, 시간, 리스크 등 동적 컨텍스트에 따라 정책 평가를 수행합니다.

특히 중요한 점은, QueryPie MCP Agent PAM이 이러한 정책 평가를 실행 가능하게 만들기 위해서는 반드시 외부 RAG 솔루션으로부터 메타데이터 정보를 제공받을 수 있어야 한다는 구조적 전제가 필요하다는 점입니다. 예를 들어 LangChain, LlamaIndex, AutoGen 등의 프레임워크는 각기 다른 방식으로 user_id, doc_type, access_scope, confidentiality 등의 메타데이터를 제공할 수 있어야 하며, QueryPie는 이 정보를 수신받아 자체적인 ACL 정책 레이어에서 분리 실행 구조로 처리하게 됩니다.

따라서 QueryPie는 단일 RAG 제품에 종속되지 않고, 다양한 프레임워크에 적용 가능한 ACL 통합 레이어로서 정책 실행을 담당합니다. 이로써 벡터 DB와 프롬프트 구성 계층 간의 흐름을 별도로 감싸며, 비인가 문서의 삽입이나 유출 가능성을 정책적으로 차단하는 독립 보안 계층으로 동작할 수 있습니다.

또한 QueryPie는 다음과 같은 기능을 정책 기반으로 보장합니다:

• 멀티테넌시 격리: namespace, user_id, role, doc_type, confidentiality 기반의 정책 필터를 통해 벡터 DB의 논리적 분리 구현
• 정책 충돌 탐지 및 승인 삽입: 정책 간 모순을 탐지하고, 고위험 요청에 대해 동적 관리자 승인 요청 삽입
• 정책 트레이스 및 로그 분리 저장: 모든 요청은 실행 시점의 조건과 정책 결과를 함께 로그로 저장하여 사후 감사 가능

결국 QueryPie는 단순한 정책 정의 도구가 아니라, 각기 다른 RAG 솔루션 위에서 ACL, PBAC, CBAC 정책을 독립적으로 실행할 수 있는 범용 보안 계층입니다[26].

5.7 실행 흐름 통합 가시성: 단순 LLM 가드레일을 넘어선 구조적 통제의 필요성

현대의 AI 기반 정보 처리 시스템은 단순한 LLM(Language Model) 호출만으로 구성되지 않습니다. 대부분의 엔터프라이즈 환경에서 LLM은 AI Agent, 벡터 검색, 외부 API 연동, 문서 전처리, 그리고 MCP(Model Context Protocol) Server와 결합되어 작동합니다. 이 구조는 단일 모델이 아닌, 다수의 실행 컴포넌트가 협력하여 응답을 생성하는 분산 정책 흐름을 형성합니다.

이러한 구조에서는 더 이상 프롬프트 입력을 제한하거나 응답을 필터링하는 방식의 가드레일(guardrail) 만으로는 충분하지 않습니다. 다음의 시나리오는 그 한계를 잘 보여줍니다:

• AI Agent가 전 단계에서 불완전하게 필터링된 문서를 LLM에게 전달하는 경우
• MCP Server가 요청을 재작성하거나 리디렉션하는 과정에서 정책이 무시되는 경우
• A2A(Agent-to-Agent) 호출 흐름에서 권한이 없는 Agent가 실행을 트리거하는 경우

이러한 복합적인 호출 흐름 속에서 보안을 보장하기 위해서는 단순 정책 선언이 아닌, 실행 흐름 내 각 지점에서 정책을 평가하고 반영하는 능력, 즉 실행 기반 정책 집행(Execution-Time Policy Enforcement) 이 요구됩니다.

QueryPie MCP Agent PAM은 이 조건을 충족시키는 구조적 솔루션입니다. 단일 모델을 제어하는 것이 아니라, MCP Server – AI Agent – LLM의 전체 호출 경로를 프록시 계층을 통해 감싸고, 다음과 같은 기능을 수행합니다:

• PDP(Policy Decision Point)는 실행 요청의 목적과 세션 정보를 기반으로 정책을 평가합니다.
• PEP(Policy Enforcement Point)는 평가된 정책 결과에 따라 프롬프트 구성, 삽입, 거부를 결정합니다.
• PIP(Policy Information Point)는 외부 시스템 또는 메타데이터에서 정책 평가에 필요한 컨텍스트를 동적으로 수집합니다.

이러한 설계는 단순히 특정 문서에 접근할 수 있는지를 판단하는 ACL 수준의 권한 통제를 넘어서, AI 시스템 전체의 흐름을 ‘정책 중심 구조’로 재편성하는 역할을 수행합니다.

QueryPie는 자사 공식 백서에서 다음과 같은 철학과 전략 방향을 제시합니다:

• "정책은 프롬프트 밖에서 선언되는 것이 아니라, 실행 경로 내부에서 적용되어야 한다"는 실행 우선 원칙[27]
• "AI Agent가 결정한 흐름조차 정책 평가 대상이 되어야 하며, 중간에서 승인 삽입이나 흐름 차단이 가능해야 한다"는 실행 계층 통제 전략[28]
• "MCP PAM은 단순 접근제어가 아니라, AI 시스템 전체를 정책으로 시각화하는 보안 아키텍처의 중심 계층"이라는 구조적 목표[29]

이러한 구조적 통제 모델은 단순히 보안을 위한 것이 아니라, 설명 가능성(Explainability), 규제 대응성(Compliance), 사용자 신뢰성(Trustworthiness) 확보를 위한 기반으로도 작동합니다.

결론적으로, 미래의 AI 보안 전략은 단순 가드레일을 넘어서야 하며, 실행 흐름 자체를 통제하고 설명 가능한 정책 집행 구조를 수립하는 방향으로 진화해야 합니다. QueryPie의 구조는 AI 보안의 전략적 미래를 가장 현실적으로 반영하고 진화하고 있는 아키텍쳐입니다.

6. 결론 – 실행 흐름 제어가 RAG 2.0의 보안 핵심인 이유

6.1 정적 정책 선언은 더 이상 충분하지 않다

RAG(Retrieval-Augmented Generation) 2.0 환경에서 AI는 고정된 데이터셋을 넘어서 외부 지식을 실시간으로 가져와 응답을 생성합니다. 프롬프트에 삽입되는 문서는 벡터 검색 기반으로 선택되며, 그 과정에서 사용자 권한이나 문서 민감도 등의 보안 조건이 누락될 경우, AI 응답을 통해 비인가 정보가 노출될 가능성이 존재합니다[30].

이로 인해 보안 판단 기준은 기존의 단순한 이진형 질문:

"사용자 X가 리소스 Y에 접근 가능한가?"

를 넘어서 다음과 같은 맥락 기반 평가로 발전해야 합니다:

"사용자 X가 Z라는 목적과 T라는 시점의 세션에서, 문서 Y를 프롬프트에 삽입하고 LLM 응답에 사용해도 적절한가?"

이처럼 문서 사용 시점과 맥락을 포함한 보안 판단은 기존의 ACL(Access Control List)이나 RBAC(Role-Based Access Control)만으로는 충족되지 않으며, 목적 기반 접근제어(PBAC), 문맥 기반 접근제어(CBAC), 리스크 기반 평가(RiskBAC) 등의 모델이 통합적으로 적용되어야 합니다[31].

특히 RAG 시스템은 다음과 같은 실행 단계를 포함합니다:

1. 사용자 요청 수신
2. 벡터 검색 수행
3. 문서 필터링 및 선택
4. 프롬프트 구성
5. LLM 호출 및 응답 반환

이러한 다단계 실행 흐름 중 어느 한 곳이라도 정책 평가가 생략되면, 시스템은 사전 정의된 권한 체계를 우회하는 실행 경로를 생성하게 됩니다. 이로 인해 보안 정책은 더 이상 선언이나 사전 설정만으로는 충분하지 않으며, 프롬프트 삽입 시점에 정책이 반영되는 실행 기반 보안 아키텍처가 필수적입니다.

6.2 실행 흐름을 기반으로 한 보안 아키텍처의 3요소

RAG 보안을 실질적으로 구현하기 위해서는 정책 평가가 실행 흐름 내부에서 이루어져야 하며, 이를 위해 다음과 같은 세 가지 구성 요소가 필수적으로 작동해야 합니다:

이 구조는 정책 선언에서 정책 반영까지의 정책 생애주기(policy lifecycle) 전반을 실시간 흐름 내에 내장할 수 있는 체계를 의미합니다.

현재 대표적인 플랫폼은 각기 다른 방식으로 이 구조를 구현하고 있습니다:

• Microsoft는 Copilot의 API Gateway에서 Microsoft Graph 기반 권한 평가를 수행하며, 인증 및 역할 기반 접근을 프롬프트 구성 이전에 적용합니다. 그러나 정책 흐름은 정적이며 실행 흐름 제어는 제한적입니다[32].
• Meta는 오케스트레이션 계층 내부에 세션 기반 CBAC/PBAC 정책 평가 로직을 내장하고 있으며, 프롬프트 삽입 직전에 문서 필터링을 수행합니다. 이는 실행 시점 평가이지만, 외부 연동이나 정책 확장성은 제약이 존재합니다[33].
• QueryPie는 MCP Agent PAM 구조를 통해 외부 프록시 계층에서 PDP, PIP, PEP를 분리 구현하고 있으며, 다양한 LLM/RAG 앞단에서 실행 흐름 전체를 감싸는 구조를 제공합니다. 벡터 검색, 문서 삽입, 모델 호출 등 모든 주요 실행 지점에 정책을 삽입하고, 평가 결과에 따라 흐름을 분기하거나 차단할 수 있습니다[34].

특히 QueryPie는 단일 문서 또는 단일 질문 단위의 평가를 넘어, 세션 전체의 흐름(프롬프트 → 호출 → 응답 → 감사)을 하나의 정책 실행 단위로 통제할 수 있는 구조적 확장성을 보유하고 있습니다.

결국 실행 기반 보안은 선언된 정책이 실제 흐름에 반영되는지를 검증할 수 있는 구조를 의미하며, 이를 위해서는 실행 흐름 각 지점에 정책이 삽입되고 집행되어야 합니다. 이후 절에서는 이러한 정책이 PBAC, CBAC, ACL 등으로 어떻게 구성되고 통합되어야 하는지를 분석합니다.

6.3 PBAC, CBAC, ACL은 통합 구조 내에서만 실효성을 가진다

RAG 환경의 보안을 실질적으로 구성하기 위해서는, 목적 기반(PBAC), 문맥 기반(CBAC), 객체 기반(ACL) 접근제어 모델이 개별 기능이 아닌 통합 정책 평가 구조 내에서 유기적으로 연결되어야 합니다. 각각의 모델은 다음과 같은 역할과 한계를 가집니다:

• PBAC (Purpose-Based Access Control)
  • 사용자 요청의 목적에 따라 정책을 평가합니다(예: 사용자가 성과 평가를 위해 접근을 요청하는 경우).
  • 하지만 요청 목적만으로는 실제 실행 컨텍스트 전체를 설명하기 어렵습니다.
• CBAC (Context-Based Access Control)
  • 요청 시점의 세션 맥락(예: 사용자 역할, 시간, 디바이스, 리스크 점수 등)을 정책 조건에 포함합니다.
  • 이는 실행 시점에서의 동적 조건을 반영하지만, 문서 및 객체 자체의 권한은 반영하지 못합니다.
• ACL (Access Control List)
  • 문서나 리소스 단위로 사전에 정의된 정적 권한을 기준으로 평가합니다.
  • 하지만 CBAC이나 PBAC의 동적 특성을 내포하지 못하고, 실행 흐름 내에서는 쉽게 우회될 수 있습니다.

이 세 가지 모델은 상호보완적이며, 특히 RAG와 같은 비정형 흐름 기반 시스템에서는 각각의 정책이 별도로 동작할 경우 정책 충돌, 통제 공백, 감사 추적 불가 등의 문제가 발생할 수 있습니다[35].

이를 해결하기 위해서는 다음과 같은 정책 통합 전략이 필요합니다:

• PBAC: 요청 이유, 요청자 부서, 업무 목적 등을 기반으로 문서 삽입 허용 여부를 판단합니다.
• CBAC: 세션 시간, 디바이스 정보, 리스크 레벨 등을 기준으로 정책 실행 여부를 동적으로 평가합니다.
• ACL: 문서 자체의 권한, 작성자, 민감도, 생성일 등을 기준으로 접근 가능 여부를 평가합니다.

이 세 가지는 정책 모델의 유형이 다른 것이 아니라, 실행 시점의 서로 다른 평가 기준을 통합적으로 반영해야 하는 것입니다.

QueryPie의 실행 기반 정책 통합 구조

QueryPie MCP Agent PAM은 이러한 통합 모델을 실행 기반으로 구현할 수 있도록 설계되어 있습니다. 그 핵심은 다음과 같습니다:

1. 정책 모델 통합: ai-policy.yaml 또는 JSON 형태의 정책 구성 내에서 PBAC, CBAC, ACL 조건을 함께 선언할 수 있도록 지원합니다.

예를 들어 다음과 같은 정책 표현이 가능합니다:

allow_if:
    purpose: "hr.audit"
    session.role: "manager"
    doc.confidentiality: "low"
    session.risk_score: < 3

2. 객체 기반 평가 구조 (OPA 기반): QueryPie는 Open Policy Agent(OPA) 기반 정책 엔진을 활용하여, 사용자의 요청, 문서 속성, 세션 정보 등 모든 요소를 객체(object) 단위로 평가합니다. 이로 인해 정책 표현이 구조화되고, 다차원 조건의 조합 및 중첩 평가가 가능합니다.
3. ReBAC, RiskBAC 확장 가능성: 단순한 사용자-문서 매핑을 넘어서, 조직 내 관계 기반 정책(예: 보고 체계, 소속 팀)이나 세션 기반 리스크 평가(예: 로그인 위치, 공격 지표)를 반영하는 ReBAC(관계 기반), RiskBAC(위험 기반) 평가 방식도 적용 가능합니다[36].
4. 멀티 프레임워크와의 통합: QueryPie는 자체 RAG 솔루션이 아닌 외부 통제 계층으로 작동하므로, LangChain, LlamaIndex, AutoGen, Weaviate, Pinecone 등 다양한 RAG 프레임워크 앞단에서 메타데이터 기반 정책 평가가 가능합니다. 이 구조는 ACL+PBAC+CBAC+ReBAC+RiskBAC가 하나의 정책 흐름 내에서 조화롭게 동작하는 실행 보안 통합 환경을 구성할 수 있게 합니다.

이처럼 QueryPie는 정책 모델 간의 개념적 통합을 넘어서, 실제 실행 흐름 내부에서 이를 객체 단위로 평가하고 정책 흐름 내 삽입, 차단, 승인 삽입, 감사 기록까지 자동화할 수 있는 구조를 갖추고 있습니다. 이러한 구조는 단순한 정책 선언을 넘어, 실행 시점에서 보안 통제를 실현할 수 있는 실질적 구현 방식으로 평가됩니다[37].

6.4 실행 기반 보안을 위한 아키텍처 설계 제언

RAG 2.0 시대의 보안을 위한 기술적 대응은 단순한 정책 선언이나 권한 설정에 머무를 수 없습니다. 정책은 반드시 실행 시점의 흐름에 결합되어야 하며, 전체 시스템 구성요소—프롬프트, 에이전트, LLM 호출—를 정책 구조 안에 포함할 수 있어야 합니다. 이를 위해 다음과 같은 네 가지 보안 아키텍처 설계 원칙을 제안합니다:

1. 프롬프트 삽입 이전의 정책 분기 구조 설계
   • 벡터 검색 결과를 프롬프트에 삽입하기 전, 세션 컨텍스트와 문서 속성 기준으로 정책을 평가하고, 삽입 허용 여부를 정책적으로 결정해야 합니다.
   • 예: 문서의 confidentiality가 high이고 요청자의 risk_score가 4 이상이면 삽입 차단
2. 선언적 정책을 실행 기반 정책으로 전환
   • JSON/YAML로 작성된 정책이 단순한 선언에 머무르지 않고, 실제 실행 시점에 평가될 수 있도록 시스템 구조 내에서 정책 엔진과 실행 흐름을 연결해야 합니다.
   • OPA(Open Policy Agent), Cedar, Rego 등의 정책 프레임워크는 이를 가능하게 합니다[38].
3. PDP / PIP / PEP 구조의 분리와 계층 구성
   • 정책을 실시간으로 평가(PDP), 정보 수집(PIP), 집행(PEP)하는 구조를 각기 독립적인 계층으로 나누고, 실행 흐름의 앞단 또는 중간에서 중재 계층으로 작동시켜야 합니다.
   • QueryPie는 프록시 기반 구조로 이를 분리 구현하며, Meta는 오케스트레이션 내부에서 PDP/PEP를 묶어 운영합니다.
4. 정책 흐름의 시각화 및 실행 로그 정형화
   • 정책이 어떤 요청에 어떻게 반영되었는지를 사용자/보안 관리자 모두가 이해 가능하도록 시각화 가능해야 하며, 요청, 평가 조건, 결과, 삽입 여부를 로그로 정형화해 보관해야 합니다.
   • 이는 감사 가능성(Auditability), 설명 가능성(Explainability), 컴플라이언스 대응성(Compliance Readiness)을 동시에 만족시킵니다[39].

이러한 전략은 단지 정책을 표현하고 적용하는 차원을 넘어서, 실행 보안 정책을 중심으로 시스템을 설계하는 구조적 전환을 의미합니다. 결국 보안은 리소스 기반이 아닌, 흐름 기반 판단 모델로 진화해야 합니다.

6.5 맺음말

RAG 2.0 환경에서의 보안 전략은 단순히 문서를 보호하거나 숨기는 방식으로는 더 이상 효과를 기대할 수 없습니다. 이제 우리는 다음과 같은 질문에 대답할 수 있는 시스템을 요구받고 있습니다:

누가, 언제, 어떤 목적과 맥락으로, 어떤 문서를 AI 응답에 사용할 수 있었는가?

[그림 9] 선언에서 실행으로

이러한 질문에 대한 정답은 고정된 권한 목록이 아닌, 실행 흐름을 기반으로 한 정책 평가 구조에서 나옵니다. 보안의 중심축은 이제 선언에서 실행으로, 권한 관리에서 정책 흐름의 통합 평가로 이동해야 합니다. 이러한 변화를 선도하는 구조는 단순한 권한 엔진이 아닌, 실행 흐름의 정책 주입, 평가, 집행, 가시화까지 전 범위에 걸쳐 통제 가능한 구조여야 하며, QueryPie MCP Agent PAM은 그 구조를 가장 현실적으로 구현한 대표 사례입니다.

본 백서는 이를 바탕으로, 단순 LLM 응답 제어를 넘어 MCP + AI Agent + LLM의 전방위 흐름 통제 구조가 보안의 본질이 되어야 한다는 전략적 패러다임 전환을 제안합니다.

부록. 실행 흐름 기반 정책 설계를 위한 PBAC 및 CBAC 고급 개념 해설

A.1 Purpose-Based Access Control (PBAC)

PBAC는 리소스 접근을 허용할지를 판단할 때 '누가(who)'와 '무엇에(what)' 접근하는가뿐만 아니라, '왜(why)' 접근하려는가라는 질문을 정책 평가 요소로 포함하는 접근제어 모델입니다. 이는 단순한 권한 부여를 넘어, 요청의 의도(intent)와 사용 목적(purpose)을 중심으로 정책을 설계하는 것을 의미합니다[40].

핵심 구조

PBAC 정책은 이러한 요소의 일치 여부 또는 허용 가능한 범위를 기준으로 접근 허용 여부를 판단합니다.

구현상의 특징

• PBAC는 일반적으로 정책 표현 언어에서 목적 값을 식별 가능한 문자열 또는 태그 형식으로 명시합니다.
• 정책 집행은 프롬프트 구성 이전 또는 API 호출 직전 단계에서 목적 필드에 대한 평가(PDP) 로 수행됩니다.

예를 들어 OPA(Rego)에서는 다음과 같은 표현이 사용될 수 있습니다:

allow {
    input.subject.purpose == "hr.audit"
    input.resource.purpose == "hr.audit"
}

한계 및 확장

• PBAC 단독으로는 세션의 위험도나 문맥 상태를 반영하지 못하며, 목적이 허위로 표기되었을 경우 이를 탐지하거나 교차 검증하기 어렵습니다.
• 이를 보완하기 위해 CBAC 또는 RiskBAC과 결합되어야 실행 흐름 내 보안 판단이 강화됩니다[41].

A.2 Context-Based Access Control (CBAC)

CBAC는 정책 평가 시 요청이 발생한 실행 맥락(context) 을 동적으로 평가하여 접근 여부를 판단합니다. 이 모델은 정적 정책이 아닌, 세션 단위 평가와 시간 조건, 위치, 디바이스, 세션 리스크 점수 등을 실시간으로 반영할 수 있다는 점에서, 실행 흐름 보안의 핵심 기반으로 간주됩니다[42].

주요 컨택스트 요소

정책 평가 방식

CBAC는 PEP가 실행 지점에서 세션 컨텍스트를 전달하고, PDP가 이를 종합 평가하여 정책 결과를 반환하는 구조로 동작합니다. 평가 로직은 OPA, Cedar, Rego 기반 엔진에서 다음과 같이 정의될 수 있습니다:

allow {
    input.session.risk_score < 3
    input.session.time >= "09:00:00"
    input.device.type == "trusted"
}

구조적 확장성과 흐름 평가

CBAC는 실행 흐름 보안 측면에서 다음과 같은 장점을 가집니다:

• 프롬프트 삽입 여부를 사용자의 현재 세션 상태와 문서의 보안 속성을 조합해 동적으로 판단
• LLM이 아닌 RAG 이전의 검색/삽입 계층에서 차단이 가능하므로, 사후 필터링이 아닌 사전 통제 구조로 작동
• 다양한 조건이 결합되기 때문에 PBAC, ACL, RiskBAC과 함께 복합 조건 평가 정책으로 통합 가능

A.3 통합 설계 시 고려 사항

PBAC과 CBAC은 상호 보완적인 역할을 하며, RAG 및 AI Agent 흐름이 함께 작동하는 환경에서는 다음과 같이 통합적으로 설계되어야 합니다:

QueryPie MCP Agent PAM은 이러한 조건을 모두 객체 기반 평가 구조(object-based policy evaluation) 로 통합하여 실행 시점에서 반영 가능하게 하며, 프록시 계층에서 이를 라우팅, 집행, 로깅까지 포함하여 처리합니다.

A.4 결론

PBAC과 CBAC은 단순한 개념 정의를 넘어, 실제 AI 보안 흐름 내에서 정책이 작동하는 기준을 설계하는 핵심 도구입니다. 선언형 정책에서 실행 기반 정책으로 전환하기 위해서는, 이 두 모델을 다중 조건 기반 객체 평가 정책으로 통합하고, 정책 흐름 전체를 추적할 수 있는 엔진 기반 실행 구조를 구축해야 합니다.

QueryPie는 OPA 기반 정책 모델, 프록시 라우팅, 실행 분기 및 거부 처리, 승인 요청 삽입, 실행 로그 정형화 등 이 모든 요구를 수용 가능한 형태로 설계되어 있으며, RAG 2.0 보안 체계를 실현하기 위한 구조적 기초를 제공합니다[43].

참고문헌

[1] Microsoft, “Design a Secure Multitenant RAG Inferencing Solution – Azure Architecture Center,” Microsoft Learn, 2025.

[2] Polymer, “Introducing Polymer’s SecureRAG,” Polymer Blog, 2025.

[3] Weaviate, “Multi-Tenancy Vector Search with millions of tenants,” Weaviate Blog, 2023.

[4] Amazon Web Services, “Multi-tenancy in RAG applications in a single Amazon Bedrock knowledge base,” AWS ML Blog, 2024.

[5] R. Theja, “Building Multi-Tenancy RAG System with LlamaIndex,” Medium, 2024.

[6] QueryPie, “Redefining PAM for the MCP Era,” White Paper, 2025.

[7] QueryPie, “MCP PAM as the Next Step Beyond Guardrails,” White Paper, 2025.

[8] Amazon Web Services, “Multi-tenancy in RAG applications in a single Amazon Bedrock knowledge base,” AWS ML Blog, 2024.

[9] QueryPie, “Uncovering MCP Security,” White Paper, 2025.

[10] QueryPie, “Google Agentspace Gets Things Done—QueryPie MCP PAM Keeps Them Safe,” White Paper, 2025.

[11] Meta Engineering, “Privacy-aware infrastructure and purpose limitation at Meta,” Meta Engineering Blog, Aug. 27, 2024.

[12] Polymer, “Generative AI Security: Preparing for 2025,” Polymer Blog, 2023.

[13] Microsoft, “Multitenant RAG Security Model,” Azure Architecture Center, 2024.

[14] LangChain, “Agent and Workflow Cloning Scenarios,” GitHub Docs, 2024.

[15] Weaviate, “Document Expiry and Vector TTL Policies,” Weaviate Docs, 2023.

[16] Microsoft Graph Team, “Data, Privacy, and Security for Microsoft 365 Copilot,” Microsoft Learn, 2023.

[17] Amazon Web Services, “Create a Generative AI Gateway to allow secure and compliant consumption of foundation models,” AWS Machine Learning Blog, 2023.

[18] AWS, “Implementing a PDP,” AWS Prescriptive Guidance, 2023.

[19] Microsoft, “Build Microsoft Graph Connectors for 365 Copilot,” Microsoft Learn, 2023.

[20] Amazon Web Services, “Metadata-based document filtering in OpenSearch,” AWS Docs, 2024.

[21] Kong Inc., “How to Manage Your API Policies with OPA (Open Policy Agent),” Kong Blog, 2024.

[22] Open Policy Agent, “OPA Philosophy – Offload Policy Decisions,” OPA Docs, 2023.

[23] NIST, “Zero Trust Architecture,” Special Publication 800-207, 2020.

[24] Microsoft, “Tutorial: Build a RAG app with the Copilot SDK,” Microsoft Learn, 2024.

[25] Cloudflare, “Take Control of Public AI Application Security with Firewall for AI,” Cloudflare Blog, 2023.

[26] PwC, “Unlocking value with AI agents: A responsible approach,” PwC Tech Effect, 2023.

[27] Open Policy Agent, “OPA: Policy Engine for Cloud Native Environments,” CNCF, 2021.

[28] Business Insider, “Samsung bans employees from using AI tools like ChatGPT after an accidental data leak,” Business Insider, May 2023.

[29] H.F. Atlam et al., “Risk-Based Access Control Model: A Systematic Literature Review,” Future Internet, vol. 12, no. 6, p. 103, Jun. 2020.

[30] Microsoft, “Azure OpenAI content filtering,” Microsoft Learn, 2025.

[31] OWASP, “LLM01: Prompt Injection,” OWASP Top 10 for LLM Applications, 2024.

[32] Open Policy Agent, “OPA Use Cases – Approval Workflow,” OPA Docs, 2023.

[33] European Commission, “Proposal for a Regulation on AI (AI Act),” Article 12 – Record Keeping, 2021.

[34] Aserto, “OPA vs. Zanzibar: Relationship-Based Access Control,” Aserto Blog, 2022.

[35] NIST, “Guide to Attribute Based Access Control (ABAC),” NIST SP 800-162, Jan. 2014.

[36] CNCF, “Love, Hate, and Policy Languages: An Introduction to Decision-Making Engines,” CNCF Blog, May 2024.

[37] NIST, “AI Risk Management Framework 1.0,” NIST, Jan. 2023.

[38] J. Byun and N. Li, “Purpose based access control for privacy protection in relational database systems,” VLDB J., vol. 17, no. 4, pp. 603–619, 2008.

[39] SSH Communications Security, “What is CARTA (Continuous Adaptive Risk and Trust Assessment)?,” SSH Academy, 2024.