Fine-grained access control for Amazon Bedrock Managed Knowledge Base tools

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Bedrock Managed Knowledge Base를 공유하는 에이전트의 세분화된 접근 제어는 LLM 대신 신뢰할 수 있는 코드가 검증된 사용자 신원을 userContext에 주입하고, ACL awareness가 검색 결과를 제한하도록 설계한다.

📌 핵심 요약

• AnyCompany 예시에서는 여러 부서가 하나의 에이전트와 지식 베이스를 공유하며, LLM이 검색 사용자 신원까지 결정하면 프롬프트 주입이나 모델 오류로 다른 부서의 문서가 노출될 수 있다. 같은 위험은 여러 고객이 공유하는 멀티테넌트 SaaS에도 적용된다.
• Amazon Cognito가 발급한 JWT를 Amazon Bedrock AgentCore Gateway가 검증하고, 요청 인터셉터가 검증된 email을 tools/call의 userContext에 덮어쓴다. Managed Knowledge Base의 ACL awareness는 이 사용자에게 허용된 문서만 검색 결과로 반환한다.
• 기본 방어는 요청 인터셉터와 ACL awareness의 조합이다. 추가 방어로 Policy in AgentCore의 Cedar 정책이 userContext.userId와 JWT의 email 불일치를 거부하고, 지식 베이스의 리소스 기반 정책이 Gateway 실행 역할 외 주체의 검색을 차단한다.
• ACL awareness는 최종 사용자를 인증하지 않으며 전달받은 userContext를 신뢰한다. ACL이 활성화된 Amazon S3 데이터 소스에서는 ACL 항목이 없는 문서가 수집되지 않고, ACL 변경은 다음 동기화 후 적용되며, ACL 오류로 제외된 문서에 대해 오류가 반환되지 않는다. ACL이 비활성화된 데이터 소스의 문서는 모든 사용자에게 반환된다.
• Managed Knowledge Base는 Retrieve와 AgenticRetrieveStream을 제공한다. 이를 MCP 도구로 노출할 때 관리자는 대상 지식 베이스를 parameterValues로 고정하고, 인터셉터가 userContext를 전달할 수 있도록 parameterOverrides로 해당 필드를 도구 스키마에 노출해야 한다.

🧩 주요 포인트

1. LLM이 도구 인수를 구성하는 구조 → 검색 사용자 신원은 모델의 판단에서 분리하고 검증된 인증 정보로 결정해야 한다.
2. ACL awareness가 호출자가 전달한 userContext를 신뢰 → Gateway에서의 신원 주입뿐 아니라 지식 베이스에 직접 접근하는 경로의 제한도 중요하다.
3. ACL 동기화 지연·조용한 문서 제외·ACL 비활성 데이터 소스의 전체 공개 → 검색 결과의 누락과 노출 범위는 데이터 소스 설정 및 동기화 상태와 함께 해석해야 한다.

🧠 상세 정리

1. 공유 에이전트에서 발생하는 사용자 신원 위조 위험

기업이 내부 문서를 검색해 답변하는 AI 에이전트를 업무에 도입하면서, 하나의 조직에서 수백 개의 에이전트가 여러 데이터 소스와 도구에 연결될 가능성이 제기된다. 가상의 AnyCompany에서는 A부서 직원이 자기 부서의 사업 계획과 전사 공지를 비교해 지연된 과제를 요청하고, B부서 직원도 같은 도우미를 사용한다. 검색을 사용자별로 제한하지 않으면 A부서 직원의 답변에 B부서 사업 계획이 포함될 수 있으며, 부서를 고객사로 바꾸면 멀티테넌트 SaaS에서도 같은 문제가 발생한다. 기존 애플리케이션은 코드가 로그인 사용자를 확인하고 그 권한으로 검색하지만, 에이전트에서는 LLM이 실행 중 호출할 도구와 인수를 결정한다. 따라서 검색 도구가 검색 대상 사용자 신원을 인수로 받으면 프롬프트 주입이나 LLM 오류가 다른 직원의 신원으로 검색하는 결과를 만들 수 있다.

2. 검증된 신원을 도구 계층에서 주입하는 설계

해결책은 모든 직원이 같은 에이전트와 지식 베이스를 사용하면서도 각자 열람할 수 있는 문서만 검색하도록 구성하는 것이다. 검색 백엔드는 Amazon Bedrock Managed Knowledge Base이며, Amazon Bedrock AgentCore Gateway를 통해 MCP 도구로 에이전트에 제공된다. 핵심 원칙은 LLM이 사용자의 신원을 결정하게 두지 않고, 신원 공급자가 검증한 정보를 바탕으로 신뢰할 수 있는 코드가 결정하도록 하는 것이다. Managed Knowledge Base의 ACL awareness는 userContext의 userId에 전달된 이메일을 기준으로 결과를 제한하지만, MCP 도구에서는 이 값이 LLM이 구성하는 인수가 될 수 있고 Gateway와 지식 베이스는 그 값이 인증된 사용자에 속하는지 자체적으로 확인하지 않는다. 따라서 이 설계는 도구 계층에서 검증된 사용자 속성을 주입하고 리소스 계층에서 해당 속성으로 검색 범위를 제한한다. 예제는 A부서와 B부서 사업 계획 및 전사 공지라는 세 문서를 하나의 지식 베이스에 저장하고, user-a와 user-b가 같은 에이전트를 통해 검색하도록 구성한다.

3. 인증에서 문서 검색까지 이어지는 요청 흐름

사용자는 Amazon Cognito에 로그인해 JWT 형식의 액세스 토큰을 받으며, 토큰 생성 전 AWS Lambda 트리거가 email 클레임을 추가한다. 에이전트는 Gateway로 MCP 요청을 보낼 때 이 토큰을 Authorization 헤더에 전달하고, Gateway의 JWT 인가기는 서명과 만료 및 클라이언트 ID를 검증한다. Gateway의 요청 인터셉터로 동작하는 Lambda 함수는 검증된 토큰에서 이메일을 확인해 tools/call의 userContext 인수를 덮어쓴다. 이어서 Policy in AgentCore는 수정된 요청을 Cedar 정책으로 평가하고, userContext.userId가 JWT의 email 클레임과 다르면 요청을 거부한다. 커넥터 대상은 Gateway 실행 역할로 Managed Knowledge Base 검색 API를 호출하며, 지식 베이스의 리소스 기반 정책은 다른 주체의 검색을 거부한다. 마지막으로 ACL awareness가 userContext에 지정된 사용자에게 허용된 문서의 청크만 반환한다.

4. 기본 방어와 추가 방어의 역할 및 적용 조건

원문은 도구 계층과 리소스 계층에 각각 기본 방어와 추가 방어를 배치한다. 기본 방어는 요청 인터셉터가 검증된 토큰으로 userContext를 결정적으로 주입하는 것과, ACL awareness가 그 사용자에게 허용된 문서만 반환하는 것이다. Gateway를 통과하는 요청에서는 다른 주체가 지식 베이스를 호출할 수 없다는 조건 아래 이 두 장치로 세분화된 접근 제어를 달성할 수 있다고 설명한다. 다만 ACL awareness는 전달받은 userContext에 따라 결과를 거르는 기능이며, 그 자체로 사용자 신원을 확인하는 인가 메커니즘은 아니다. 추가 방어인 Policy in AgentCore와 리소스 기반 정책은 인터셉터의 버그 또는 Gateway를 우회한 직접 호출처럼 기본 방어의 전제가 깨지는 경우를 보완하므로 요구사항에 따라 추가한다. 특히 계정 내 다른 주체가 bedrock:Retrieve 권한을 가진 경우에는 리소스 기반 정책을 추가하도록 명시한다.

5. 배포 전제와 샘플 애플리케이션 구성

배포에는 리소스를 생성할 수 있는 AWS 계정과 IAM 권한, Managed Knowledge Base·AgentCore Gateway·Policy in AgentCore·AgentCore runtime을 사용할 수 있는 AWS 리전, 에이전트가 사용할 Amazon Bedrock 모델 접근 권한이 필요하다. 개발 환경에는 Node.js 22 이상과 npm, 에이전트 패키징 및 검증 스크립트 실행을 위한 uv가 요구된다. 기존 Amazon Cognito 사용자 풀에 적용한다면 액세스 토큰 사용자 지정에 필요한 Essentials 또는 Plus 요금제를 사용해야 하며, 샘플 스택은 Essentials 사용자 풀을 생성한다. sample-managed-knowledge-base-patterns 저장소의 agentcore-access-control 디렉터리에서 단일 AWS CDK 스택으로 배포할 수 있고, 저장소는 AWS CDK CLI와 aws-cdk-lib 2.274.0 이상을 npm 의존성으로 설치한다. 스택은 Amazon CloudFront의 웹 앱과 Strands Agents로 구현한 AgentCore runtime의 에이전트도 배포하며, 기본 모델은 global.anthropic.claude-sonnet-5-5 글로벌 교차 리전 추론 프로필을 통한 Claude Sonnet 5.5이다. 에이전트 자체에는 접근 제어 로직이 없으며 로그인 사용자의 액세스 토큰을 Gateway에 전달한다.

6. ACL 수집 방식과 Amazon S3 동기화 제약

Managed Knowledge Base는 데이터 소스를 연결하면 파싱, 청킹, 임베딩, 인덱싱, 검색 및 재순위화를 완전 관리형으로 수행하며, ACL awareness는 수집 시 데이터 소스의 접근 권한을 보존한다. Amazon S3 데이터 소스에서는 S3 접두사별 전역 ACL 파일이나 문서별 메타데이터 파일로 ACL을 정의할 수 있고, 예제는 문서별 메타데이터를 사용한다. dept-a-plan.txt와 같은 S3 경로에 두는 메타데이터 예시는 department를 d001, year를 2026으로 설정하고 [email protected]에 USER 유형의 ALLOW 권한을 부여한다. ACL이 활성화된 데이터 소스에서는 ACL 항목이 없는 문서가 수집되지 않으며, 문서별 메타데이터는 전역 ACL 파일보다 우선한다. 전역 ACL 파일 변경은 해당 접두사의 재인덱싱이 필요하지만 문서별 메타데이터 변경은 해당 문서만 재인덱싱하고, Amazon S3는 실시간 ACL 검증을 제공하지 않으므로 변경은 다음 동기화 이후 적용된다. ACL 오류가 있어도 오류 응답이 반환되지 않고 관련 문서가 결과에서 조용히 제외된다는 점도 운영상 제약이다.

7. 검색 API별 사용자 컨텍스트와 반환 범위

Managed Knowledge Base의 Retrieve는 하이브리드 검색을 수행하고, AgenticRetrieveStream은 질의를 하위 질의로 나눈 뒤 여러 지식 베이스를 반복적으로 검색한다. 두 API 모두 검색 시 최상위 userContext.userId에 사용자의 이메일을 전달해야 ACL awareness에 따라 결과가 제한된다. 예제는 Retrieve에 [email protected]을 전달하면서 A부서 사업 계획의 계획 관리 코드를 묻는 방식으로 사용자별 검색을 보여준다. ACL이 활성화된 데이터 소스는 userContext가 없는 질의에 문서를 반환하지 않지만, ACL이 비활성화된 데이터 소스는 userContext의 유무와 관계없이 모든 사용자에게 문서를 반환한다. 이 차이는 지식 베이스에 속한 데이터 소스의 설정에 따라 검색 결과의 공개 범위가 달라질 수 있음을 보여준다. Managed Knowledge Base는 최종 사용자를 인증하지 않고 전달받은 userContext를 신뢰하므로, 검증된 값을 전달하는 책임은 호출자에게 있다.

8. MCP 도구 스키마에서 userContext를 노출하는 이유

AgentCore Gateway에 Managed Knowledge Base 커넥터 대상을 생성하면 <target-name>___Retrieve와 <target-name>___AgenticRetrieveStream이라는 두 MCP 도구를 노출할 수 있다. 관리자는 parameterValues로 대상 지식 베이스를 고정하며, 기본 도구 스키마에서 LLM이 설정할 수 있는 인수는 검색 질의뿐이다. ACL awareness를 사용하려면 대상 생성 시 parameterOverrides로 userContext를 스키마에 노출해야 하는데, 커넥터 대상에는 직접 작성하는 도구 코드가 없어서 이 값을 지식 베이스로 전달할 통로가 도구 인수이기 때문이다. 또한 parameterOverrides로 노출한 필드만 도구 인수로 설정할 수 있으므로, 클라이언트가 직접 값을 지정할 필요가 없어도 인터셉터의 주입을 위해 userContext를 노출해야 한다. 제시된 코드에서는 경로를 $.userContext로 지정하고 visible을 true로 설정하며, 자격 증명 공급자로 GATEWAY_IAM_ROLE을 사용한다. 제공된 원문은 커넥터 구성 코드 중간에서 끝나므로 이후의 인터셉터 구현이나 정책 코드 및 검증 절차의 세부 내용은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 검색 범위를 제한하는 기능과 검색 사용자의 신원을 신뢰할 수 있게 만드는 기능은 별개의 책임이다. ACL awareness의 효과는 호출자가 전달하는 userContext의 신뢰성에 달려 있다.
• Policy in AgentCore와 리소스 기반 정책은 서로 다른 실패 경로를 다룬다. 전자는 Gateway 내부의 신원 불일치를, 후자는 Gateway 실행 역할 외 주체의 검색을 제한한다.
• ACL이 비활성화된 데이터 소스의 전체 공개와 ACL 오류에 따른 조용한 문서 제외를 함께 고려하면, 검색 결과가 많거나 적다는 사실만으로 접근 제어가 올바르게 작동한다고 판단하기 어렵다.

✅ 액션 아이템

• Amazon Bedrock AgentCore Gateway의 요청 인터셉터가 검증된 email로 userContext를 덮어쓰도록 구성하고, parameterOverrides에 userContext 노출을 반영.
• Policy in AgentCore의 userContext.userId와 JWT email 일치 조건 및 Gateway 실행 역할 외 검색을 차단하는 리소스 기반 정책의 적용 필요성 검토.
• Amazon S3 데이터 소스의 ACL 활성화 여부, ACL 항목 누락, 다음 동기화 후 변경 적용 및 오류 없이 제외되는 문서의 영향을 확인.

❓ 열린 질문

• LLM이 다른 사용자의 userContext를 도구 인수로 구성하더라도 요청 인터셉터가 검증된 email로 덮어쓰는가?
• Gateway 실행 역할 외 주체가 Managed Knowledge Base를 직접 검색할 수 있는 경로가 남아 있는가?
• ACL이 비활성화된 데이터 소스의 전체 공개와 다음 동기화 후 적용되는 ACL 변경은 의도한 검색 범위에 부합하는가?