Govern AI agent tool access with Amazon Bedrock AgentCore Gateway

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

조직의 인공지능 에이전트가 내부 도구에 접근하는 경로를 하나의 관리형 게이트웨이로 통합하고, 실제 위험과 조직 성숙도에 맞춰 연결·통제·카탈로그·강화의 네 단계로 거버넌스를 확장하는 방법을 설명한다.

📌 핵심 요약

• 로컬 mcp.json에 자격 증명과 도구 주소를 분산 저장하면 보안 조직이 어떤 에이전트가 어떤 내부 자원에 접근하는지 파악하기 어렵고, 자격 증명 유출 시 노출 범위도 즉시 판단하기 어렵다.
• 기업의 MCP 도입에서는 자격 증명 난립, 정책 불일치, 감사 공백, 비용 불투명성, 검토되지 않은 통합이라는 다섯 가지 구조적 문제가 반복되며, 여러 에이전트와 내부 API의 조합이 늘수록 관리 대상도 급증한다.
• Amazon Bedrock AgentCore Gateway는 에이전트 트래픽의 단일 진입점을 제공하고, AgentCore Identity·Policy·Amazon Bedrock Guardrails·AWS Agent Registry를 결합해 인증, 인가, 자격 증명, 정책, 개인정보 보호, 도구 검색을 중앙화한다.
• 권장 성숙도 여정은 연결, 통제, 카탈로그, 강화의 네 범위로 구성되며, 모든 기능을 처음부터 구축하지 않고 현재 발생한 거버넌스 문제에 필요한 단계까지만 도입한다.
• 첫 번째 범위에서는 Cognito 기반 JWT 인증과 저위험 Lambda 도구로 최소 게이트웨이를 구축하고, 두 번째 범위에서는 사용자별 SSO, 동적 클라이언트 등록, Cedar 정책, 개인정보 필터, 사용자 동의와 요청·응답 인터셉터를 추가한다.

🧩 주요 포인트

1. 각 에이전트의 로컬 설정에 비밀정보와 정책을 맡기는 구조는 에이전트와 도구의 조합만큼 관리 지점을 늘리므로, 단일 게이트웨이가 접근 현황과 변경 지점을 통합하는 기반이 된다.
2. 소규모 시범 단계에서는 인증된 사용자의 도구 접근을 폭넓게 허용하더라도 중앙 인증·자격 증명·감사 기록부터 확보할 수 있으며, 이는 기존 환경을 한 번에 교체하지 않고도 통제를 시작하게 한다.
3. 사용자와 규제 요구가 늘어나면 기계 단위 신뢰를 실제 사용자 단위 권한으로 전환하고, 정책 판정·민감정보 차단·위임 동의·응답 정제를 결합해 행위별 책임 추적성을 높인다.

🧠 상세 정리

1. 출발점이 되는 접근권한 질문

글은 코딩 에이전트, 자율 에이전트, 사람과 상호작용하는 에이전트의 종류나 업무 성숙도와 관계없이 같은 질문에서 출발한다. 조직은 어떤 인공지능 에이전트가 고객 데이터에 접근할 수 있는지, 누가 그 권한을 부여했는지, 자격 증명이 지금 유출되면 무엇이 노출되는지를 짧은 시간 안에 설명할 수 있어야 한다. 이를 답하지 못하는 상태에서는 에이전트가 내부 도구와 연결되어도 보안팀이 접근 현황과 잠재적 피해 범위를 파악하기 어렵다. 사례에서는 인프라 엔지니어가 동료의 노트북에서 빌드를 점검하던 중 mcp.json 안에 평문 운영 데이터베이스 비밀번호와 교체 예정이라는 주석을 발견한다. 이 장면은 로컬 설정 중심의 연결 방식이 비밀정보 유출뿐 아니라 접근권한의 소유자와 승인 경로까지 불분명하게 만든다는 문제를 보여준다.

2. MCP 환경의 다섯 가지 구조적 실패

기업의 MCP 배포에서 반복되는 문제는 자격 증명 난립, 정책 불일치, 감사 공백, 비용 불투명성, 검토 절차 밖에서 생기는 비공식 통합으로 정리된다. 로컬 설정마다 비밀정보가 존재하면 보관 위치와 교체 상태를 한곳에서 확인할 수 없고, 개별 에이전트의 설정이 서로 달라지면 정책 변경도 일관되게 반영되지 않는다. 또한 누가 언제 어떤 도구를 호출했는지 기록하지 못하면 사고 조사와 책임 확인이 어려우며, 호출 비용을 팀별로 귀속하기도 힘들어진다. 예를 들어 에이전트 10개가 내부 API 5개에 각각 연결되면 수작업으로 관리해야 할 자격 증명 집합이 50개가 된다. 백엔드 정책 하나가 바뀌어도 50개 위치를 모두 수정해야 하므로, 규모가 커질수록 누락과 정책 편차가 조용히 축적될 수 있다.

3. 중앙 게이트웨이와 보안 구성요소

제안된 구조는 Kiro, Claude Code, Cursor, Amazon Quick과 같은 MCP 지원 도구의 조직 내부 호출을 Amazon Bedrock AgentCore Gateway라는 하나의 보안 진입점으로 모은다. AgentCore Identity는 인증, 인가와 자격 증명 관리를 담당하고, AgentCore Policy는 에이전트와 도구 사이의 상호작용에 적용할 보안 정책을 정의하고 집행한다. Amazon Bedrock Guardrails는 안전과 개인정보 보호 통제를 보강하며, AWS Agent Registry는 조직이 제공하는 도구를 정리하고 선별하며 검색할 수 있는 중앙 카탈로그 역할을 한다. 관리형 서비스만이 유일한 선택지는 아니며, 글은 Kong Gateway, Open Policy Agent, NeMo Guardrails, LangFuse와 같은 자체 호스팅 선택지도 함께 언급한다. 핵심은 특정 클라이언트별 설정에 통제를 분산하지 않고 호출자의 신원, 권한, 도구와 매개변수 수준의 정책 판정, 모든 결정의 기록을 공통 경로에서 처리하는 것이다.

4. 네 단계의 성숙도 여정

글은 완전한 게이트웨이를 먼저 수개월 동안 구축한 뒤 인공지능 사용을 허용하는 방식이 실제 필요와 어긋난 결과를 낳을 수 있다고 지적하고, 통제를 현재의 문제에 맞춰 단계적으로 도입하라고 권한다. 첫 번째 연결 범위는 SSO 인증, 자격 증명 중앙화, CloudTrail 감사를 통해 조직 자원으로 향하는 하나의 관리된 출입구를 만든다. 두 번째 통제 범위는 Cedar 기반 역할·속성 접근제어, 개인정보 삭제, 제3자 위임 동의와 동적 클라이언트 등록을 추가해 누가 어떤 정책으로 무엇을 호출했는지 설명하게 한다. 세 번째 카탈로그 범위는 Registry, Resources MCP, OPA와 도구별 비용 귀속을 사용해 온프레미스 도구까지 팀이 직접 등록하고 찾을 수 있게 한다. 네 번째 강화 범위는 대규모 사용자와 장애 가능성을 전제로 비공개 연결, 거버넌스 대시보드, 지원 종료 절차, 다중 리전 장애조치를 도입하며, 각 단계는 독립적인 가치를 제공하므로 다음 문제가 실제로 나타날 때만 확장한다.

5. 범위 1의 최소 관리형 연결

범위 1은 사용자 1명에서 20명 정도의 시범 운영, 위험이 낮은 도구, 관리되지 않은 MCP 연결이 나타나기 시작한 환경을 대상으로 한다. 조직은 먼저 게이트웨이의 소유 주체를 인프라팀, 보안팀 또는 공동 책임으로 정하고, 첫 번째로 연결할 저위험 도구와 기존 mcp.json의 존치 여부를 결정한다. 구현에서는 Cognito가 발급한 JWT를 검증하는 AgentCore Gateway를 세우고, 읽기 전용 티켓 검색과 같은 Lambda 대상 하나를 등록한다. 이 단계의 인가는 거칠게 유지되어 인증된 클라이언트라면 등록된 모든 도구를 호출할 수 있지만, 백엔드 자격 증명은 클라이언트로 전달되지 않는다. AgentCore Identity는 OAuth 2.0 기반 기계 간 인증, AWS 자원에 대한 아웃바운드 인증 또는 Secrets Manager의 API 키 인증을 처리하며, CloudWatch Logs와 CloudTrail을 통해 어떤 조직 자원이 언제 사용됐는지 확인할 기반을 만든다.

6. 범위 1의 호출 흐름과 점진적 배포

클라이언트는 미리 제공된 client_id, client_secret과 게이트웨이 주소로 시작하고, 세션마다 Cognito 토큰을 받아 tools/list와 tools/call 요청에 전달자 토큰으로 첨부한다. 게이트웨이는 JWT를 검증한 뒤 등록된 Lambda 대상으로 요청을 전달하므로, 클라이언트는 각 내부 도구의 자격 증명이나 별도 연결 코드를 직접 보유하지 않는다. 배포 첫날에는 Cognito 사용자 풀, 게이트웨이와 저위험 Lambda 대상 하나를 준비하고, 둘째 날부터 셋째 날에는 모바일 기기 관리 체계를 통해 기존 mcp.json에 게이트웨이 항목을 추가한다. 이후 토큰 발급, 도구 목록 조회, 도구 호출의 전체 경로를 검증하고, 첫 주에는 모든 호출에 대응하는 CloudWatch Logs와 CloudTrail 기록이 생성되는지 확인한다. 기존 공개 자원 설정과 함께 새 항목을 배포하는 방식이므로 변화는 추가적으로 진행되며, 개인정보 통제나 사용자별 권한 구분 요구가 나타나기 전에도 연결과 감사라는 독립적인 성과를 얻는다.

7. 범위 2의 사용자 중심 인증과 정책

사용자가 늘고 규제 담당자가 누가 어떤 정책 아래에서 무엇을 수행했는지 묻기 시작하면 범위 2로 확장한다. 이 단계에서는 신원 공급자, 인증 코드 흐름과 클라이언트 자격 증명 방식 사이의 전환 모델, LOG_ONLY 운영 기간, 최초의 Cedar 거부 규칙을 결정해야 한다. 클라이언트는 처음 tools/list를 요청할 때 표준 메타데이터를 받아 동적 클라이언트 등록용 중계 계층을 호출하고, API Gateway 뒤의 Lambda는 Cognito 애플리케이션 클라이언트를 만든 뒤 새 client_id를 게이트웨이의 allowedClients에 추가한다. 사용자는 SSO와 OAuth 2.0 인증 코드 흐름으로 로그인하며, 이후 토큰의 sub 클레임에는 기계가 아니라 실제 사용자 신원이 담긴다. AgentCore Policy는 신원 공급자의 그룹, 토큰 클레임과 호출 매개변수를 이용해 Cedar 기반 역할·속성 정책을 적용하며, 예시로 배포 도구의 호출을 staging 환경에만 허용하는 조건을 둘 수 있다.

8. 민감정보 보호와 사용자 위임

정책을 통과한 요청에는 Amazon Bedrock Guardrails가 연계되어 개인정보 필터, 콘텐츠 정책과 프롬프트 공격 탐지를 게이트웨이 계층에서 적용한다. Guardrails가 처리하지 못하는 구조 변환이나 추가적인 속성 기반 규칙은 요청 인터셉터 Lambda가 담당하고, 응답 단계의 인터셉터는 의도하지 않게 포함된 데이터를 정리한다. 대상 서비스가 GitHub나 Figma처럼 사용자 본인의 신원을 요구하면 AgentCore Identity Credential Providers가 제3자 OAuth 인증 코드 흐름을 처리한다. 이 경우 게이트웨이는 MCP elicitation에 해당하는 -32042 오류를 보내고, 에이전트는 사용자가 브라우저에서 동의를 완료하도록 안내한다. 최종 로그에는 호출 주체, 일치한 정책 식별자, 가드레일 표시와 지연시간이 함께 기록되므로, 단순한 접속 허용 여부를 넘어 사용자별 정책 판정과 보호 조치의 적용 결과를 추적할 수 있다.

🧾 핵심 주장 / 시사점

• 거버넌스의 출발점은 모든 기능을 갖춘 플랫폼을 먼저 만드는 것이 아니라, 단일 인증 경로와 중앙 감사 기록으로 현재의 자격 증명 난립과 접근 가시성 문제부터 줄이는 것이다.
• 단계별 범위는 사용자 수 자체보다 새롭게 제기되는 질문에 의해 확장된다. 개인정보 유입, 사용자 동의, 그룹별 권한 구분을 설명해야 하는 시점이 연결 중심 구조에서 사용자 중심 통제로 넘어가는 기준이 된다.
• 효과적인 통제는 한 기능에 의존하지 않는다. 사용자 신원, Cedar 정책, Guardrails, 요청·응답 인터셉터와 제3자 동의를 같은 호출 경로에 배치해야 도구 접근과 데이터 흐름을 함께 관리할 수 있다.

✅ 액션 아이템

• 로컬 mcp.json에 분산된 자격 증명과 도구 주소를 단일 게이트웨이로 통합해 에이전트별 내부 자원 접근 현황과 변경 지점을 파악한다.
• 소규모 시범 단계에서는 Cognito 기반 JWT 인증과 저위험 Lambda 도구를 우선 적용해 중앙 인증·자격 증명·감사 기록을 확보한다.
• 거버넌스 문제의 우선순위를 정한 뒤 연결·통제·카탈로그·강화 중 필요한 단계까지만 도입하고, 규제 요구가 늘면 Cedar 정책과 개인정보 필터를 추가한다.

❓ 열린 질문

• 로컬 mcp.json의 자격 증명 유출이 발생할 때 어떤 에이전트와 내부 자원이 노출되는지 즉시 파악할 수 있는가?
• 여러 에이전트와 내부 API의 조합이 늘어날 때 자격 증명 난립·정책 불일치·감사 공백을 어떤 기준으로 우선 통제할 것인가?
• 사용자 단위 권한으로 전환할 시점에 Cedar 정책, 민감정보 차단, 위임 동의와 응답 정제를 어떻게 결합할 것인가?