Build a multi-account AI agent with AgentCore Gateway and MCP

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Bedrock AgentCore Gateway와 MCP를 활용해 각 LOB 계정에 원본 데이터를 유지하면서, 중앙 플랫폼의 AI 에이전트가 필요한 도구 결과만 받아 여러 계정의 정보를 통합하도록 설계한다.

📌 핵심 요약

• 중앙 플랫폼 계정은 AgentCore Runtime의 에이전트와 Amazon Bedrock 추론을 운영하고, 기반 모델 선택·Amazon Bedrock Guardrails 적용·비용 추적을 관리한다.
• 각 LOB는 자체 데이터와 업무 로직을 MCP 서버의 도구로 노출하며, AgentCore Gateway는 등록된 LOB 전체의 도구 검색과 호출을 단일 엔드포인트로 제공한다. 원본 데이터셋은 소유 계정에 남고 요청에 필요한 도구 결과만 플랫폼 계정으로 전달된다.
• 사용자 JWT는 에이전트를 거쳐 Gateway로 전달되며, 정책 엔진이 연결된 경우 Policy in AgentCore가 JWT 클레임과 Cedar 규칙으로 사용자별 호출을 허용하거나 거부한다. Gateway에서 LOB로 나가는 요청은 AgentCore Identity의 OAuth 2.0 M2M 자격 증명을 사용하고, LOB는 Okta 기반으로 토큰을 검증한다.
• 예제는 Amazon DynamoDB 조회와 Amazon Bedrock Knowledge Bases 기반의 은행 정책 PDF 검색을 MCP 도구로 제공한다. 신규 구현에서는 Amazon Bedrock Managed Knowledge Base를 Gateway의 네이티브 커넥터로 직접 연결하는 대안도 제시한다.
• 배포 예제는 동일한 AWS Organizations 조직에 속한 네 계정의 AWS CDK 초기화와 리소스 배포를 지원한다. 샘플의 주요 접근 통제는 OAuth audience 검증이며, 운영 환경에서는 allowedWorkloadConfiguration으로 호출의 신원 체인에 Gateway가 포함되도록 제한해 정책 우회 위험을 줄이도록 권고한다.

🧩 주요 포인트

1. LOB의 MCP 도구 인터페이스와 Gateway의 단일 접점 → 데이터 소유권과 구현 자율성을 유지하면서 중앙 에이전트의 여러 계정 접근을 통합한다.
2. 사용자 JWT에 대한 Cedar 평가와 LOB 호출의 OAuth 2.0 M2M 인증 분리 → 사용자별 권한은 Gateway에서 집행하고, allowedWorkloadConfiguration으로 직접 호출에 따른 정책 우회 위험을 낮춘다.
3. Amazon Bedrock 추론의 플랫폼 집중과 두 가지 지식 검색 연결 방식 → 모델·비용 관리 책임을 중앙화하면서 검색 파이프라인의 세부 제어와 검색 인프라 운영 부담 사이에서 구현 방식을 선택한다.

🧠 상세 정리

1. 분산된 데이터를 유지하면서 에이전트의 접근 범위 확장

기업은 여러 AWS 계정에 흩어진 데이터를 복사하거나 중앙으로 옮기지 않고도 AI 에이전트가 함께 활용하기를 원한다. 각 업무 부문인 LOB가 별도 계정을 사용하는 이유는 데이터 소유권을 명확히 하고, 범위를 격리하며, 독립적인 배포 주기를 유지하기 위해서다. 그러나 한 계정의 데이터만 보는 에이전트는 활용 가치가 제한되고, 분산 소스를 연결하려면 데이터 복제나 복잡한 계정 간 IAM 구성을 다뤄야 한다. 원문은 Amazon Bedrock AgentCore Gateway와 MCP를 이용해 이러한 연결을 통합하는 구조를 제시한다. 여기서 데이터가 계정에 남는다는 뜻은 원본 데이터셋을 이동하지 않는다는 의미이며, 개별 요청을 처리하는 데 필요한 도구 결과는 질의 시점에 플랫폼 계정으로 전달된다.

2. 플랫폼 계정의 에이전트와 추론 관리

플랫폼 팀은 중앙 계정에서 AgentCore Runtime으로 에이전트를 운영하고, Amazon Bedrock을 통해 LLM 추론을 실행한다. Runtime은 서버리스이며 특정 프레임워크에 종속되지 않고, 전용 microVM의 세션 격리와 사용량 기반 과금, 내장 인증을 제공한다. 설명에는 단일 에이전트를 사용하지만 동일한 구조는 여러 에이전트를 지원하며, 에이전트는 개별 LOB 서버 대신 플랫폼의 Gateway에 연결된다. 플랫폼 팀은 사용 가능한 기반 모델과 Amazon Bedrock Guardrails를 관리하고 단일 과금 경계에서 비용을 추적해 여러 LOB 계정의 모델 할당량을 따로 관리하는 부담을 줄인다. 수요가 커질 경우에는 추론을 여러 전용 계정으로 분산하고, Gateway를 Inference Gateway로 사용해 요청에 따른 제공자 선택과 팀별 호출률 제한을 적용하는 확장 방식도 설명한다.

3. Gateway의 통합 접점과 LOB의 도구 소유권

AgentCore Gateway는 각 LOB의 MCP 서버를 대상으로 등록하고, 하나의 엔드포인트에서 의미 기반 도구 검색과 인증, 세분화된 권한 제어 및 관측 기능을 제공한다. MCP 서버 외에도 HTTP 대상을 지원하므로 AgentCore Runtime 에이전트, A2A 서비스와 다른 HTTP 엔드포인트를 각각의 하위 경로로 연결할 수 있다. 플랫폼 팀은 Gateway 계층에서 Guardrails와 Cedar 기반 정책을 적용해 에이전트 코드 외부에서 통제를 집행할 수 있다. LOB는 Amazon S3 버킷이나 데이터베이스를 직접 노출하는 대신 get_balance, get_profile, get_credit_score와 같은 도구로 데이터와 업무 로직을 감싼다. 각 LOB는 노출할 기능과 내부 구현을 직접 결정하며, MCP 도구 인터페이스가 일관되게 유지되는 한 플랫폼 에이전트에 영향을 주지 않고 구현을 변경할 수 있다.

4. 은행 정책 검색과 지식 기반 연결의 선택

대출 부문의 search_lending_policies 도구는 은행 정책 PDF를 대상으로 Amazon Bedrock Knowledge Bases의 완전관리형 RAG 기능을 사용한다. 참조 아키텍처는 독립형 지식 기반을 MCP 서버 안에서 감싸 검색 파이프라인을 세밀하게 제어하는 방식을 택한다. 구체적인 요청 흐름에서 Lending & Wealth LOB는 Amazon DynamoDB의 구조화된 데이터를 조회하고, Amazon S3에 저장된 PDF와 Amazon OpenSearch Serverless 인덱싱을 사용하는 지식 기반에서도 검색한다. 원문은 신규 구현의 대안으로 Amazon Bedrock Managed Knowledge Base를 Gateway에 네이티브 커넥터로 직접 연결하는 방식도 제시한다. 이 대안에서는 에이전트가 표준 MCP 호출로 지식 기반을 질의하고 별도의 검색 인프라를 운영하지 않으므로, 검색 과정의 세부 제어 필요성과 운영 부담을 함께 고려할 수 있다.

5. 계정 간 호출의 인증과 사용자별 권한 분리

계정 간 연결은 각 LOB의 독립형 MCP 서버를 스포크로, AgentCore Gateway를 허브로 사용하는 구조이며 MCP over Streamable HTTP로 통신한다. 에이전트에는 Gateway가 하나의 MCP 서버로 보이지만, 실제 도구 호출은 등록된 여러 LOB 대상으로 분배된다. 사용자 JWT가 Gateway로 전달되면, 정책 엔진이 연결된 경우 Policy in AgentCore가 신원·역할·행동에 대해 JWT 클레임과 Cedar 규칙을 평가한다. 허용된 호출에 대해서는 Gateway가 AgentCore Identity에서 OAuth 2.0 M2M 자격 증명을 가져와 외부 요청에 붙이고, 해당 LOB 서버는 Okta의 OIDC 엔드포인트를 기준으로 토큰을 인증한 뒤 로컬에서 처리한다. LOB로 전달되는 호출은 M2M 인증을 사용하므로 사용자 수준의 권한 제어는 Gateway에서 집행되며, LOB는 원본 데이터셋 전체가 아니라 도구가 생성한 특정 결과만 반환한다.

6. 사용자 질문에서 통합 응답까지의 처리 흐름

사용자는 React 웹앱에서 Okta로 로그인하고, Okta는 sub, groups, audience 등의 신원 클레임을 포함한 JWT를 반환한다. 사용자의 프롬프트는 HTTPS로 Amazon CloudFront에 도달한 뒤 AWS Fargate 기반 Amazon ECS에서 실행되는 FastAPI 백엔드로 전달된다. 백엔드는 사용자 입력이 에이전트에 도달하기 전과 에이전트 출력이 사용자에게 전달되기 전에 Amazon Bedrock Guardrails를 적용해 개인 식별 정보인 PII를 가린다. 이어 Authorization 헤더로 사용자 JWT를 전달하면서 AgentCore Runtime의 Strands Agent를 호출하고, 에이전트는 Amazon Bedrock의 추론 응답을 바탕으로 사용할 도구를 결정한다. 도구 실행 결과는 LOB, Gateway, 에이전트, 백엔드 순서로 돌아오며, 샘플 애플리케이션의 추적 패널은 접근한 LOB와 Policy in AgentCore의 거부 내역을 보여준다.

7. 도구 발견과 배포 전제조건

Strands Agent는 시작 시 AWS Agent Registry의 Preview 기능을 조회해 등록된 LOB MCP 서버를 발견하고, Gateway의 tools/list 메서드로 LOB 도구를 찾는다. 새로운 LOB를 연결하려면 Gateway 대상을 추가하며, 에이전트는 다음 tools/list 호출에서 새 도구를 발견한다. 제공되는 저장소의 배포 스크립트는 네 계정에서 AWS CDK를 초기화하고 플랫폼과 LOB 리소스, MCP 서버, Gateway 대상을 배포하며 CloudFront 뒤의 Amazon ECS에 React 웹앱을 실행한다. 전제조건에는 동일한 AWS Organizations 조직의 플랫폼·LOB 계정, 플랫폼의 Amazon Bedrock 모델 접근 권한, 각 계정의 AgentCore 구성이 포함된다. 또한 OAuth 2.0 클라이언트 자격 증명 방식을 지원하는 M2M 앱 클라이언트와 LOB 데이터 소스가 필요하며, OIDC 제공자는 Okta 외에 Amazon Cognito나 Microsoft Entra ID도 예시로 언급되지만 저장소는 Okta를 사용한다.

8. LOB 서버 구현과 운영 환경의 접근 제한

각 LOB 팀은 FastMCP로 타입이 지정된 입력과 출력을 갖는 도구를 만들고, AgentCore CLI를 이용해 MCP 서버를 AgentCore Runtime에 배포한다. 서버의 customJWTAuthorizer는 Okta의 OIDC 검색 엔드포인트를 기준으로 들어오는 OAuth 토큰을 인증하므로, 도구를 호출하려면 유효한 토큰이 필요하다. 샘플은 OAuth audience 검증을 주요 접근 통제로 사용하지만, 원문은 운영 환경에서 allowedWorkloadConfiguration에 Gateway의 ARN을 설정하도록 권고한다. 이 설정은 호출 신원 체인에 해당 Gateway가 포함되도록 제한해 Gateway 정책과 Cedar 권한 제어를 거치지 않는 직접 접근 위험을 줄인다. 제공된 본문은 Lending & Wealth 서버의 Amazon DynamoDB 및 Amazon Bedrock Knowledge Bases 클라이언트 초기화 코드 중간에서 끝나므로, 이후의 전체 구현이나 지속 평가 절차는 이 자료만으로 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 이 구조의 데이터 분산 원칙은 원본 데이터셋의 소유 계정 유지와 필요한 결과의 전달을 함께 허용한다. 따라서 중앙 에이전트가 받는 정보의 범위는 각 LOB가 설계한 MCP 도구의 반환 내용에 달려 있다.
• OAuth 2.0 M2M 인증과 사용자별 Cedar 권한 평가는 서로 다른 계층에서 수행된다. Gateway의 권한 통제가 실제 호출 경로에도 적용되도록 제한하는 것이 운영 설계의 핵심이다.
• 플랫폼은 모델·비용·공통 통제를 관리하고 LOB는 데이터와 도구 구현을 소유한다. 이 역할 분담이 유지되려면 내부 구현을 바꾸더라도 MCP 도구 인터페이스의 일관성을 보존해야 한다.

✅ 액션 아이템

• 각 LOB의 MCP 도구가 원본 데이터셋을 유지하면서 요청에 필요한 결과만 반환하도록 노출 범위 검토.
• 사용자 JWT에 대한 Cedar 권한 평가와 OAuth 2.0 M2M 인증의 역할을 구분하고, allowedWorkloadConfiguration을 통한 Gateway 경유 제한 적용 검토.
• 검색 파이프라인의 세부 제어 필요성과 운영 부담을 기준으로 Amazon Bedrock Knowledge Bases의 MCP 래핑 방식과 Amazon Bedrock Managed Knowledge Base 직접 연결 방식 비교.

❓ 열린 질문

• 각 LOB의 MCP 도구는 요청에 필요한 결과만 플랫폼 계정에 전달하도록 반환 범위를 어떻게 정할 것인가?
• Policy in AgentCore의 Cedar 규칙은 사용자 JWT의 어떤 신원·역할·행동을 기준으로 도구 호출을 허용하거나 거부할 것인가?
• 검색 파이프라인의 세부 제어와 운영 부담을 고려할 때 Amazon Bedrock Managed Knowledge Base 직접 연결은 어떤 LOB에 적합한가?