AI 에이전트 보안
Amazon Bedrock AgentCore Gateway로 도구 접근을 4단계로 통제합니다
AWS 공식 가이드는 Connect·Control·Catalog·Harden 순서로 에이전트의 도구 연결, 사용자별 정책, 카탈로그, 복구·감사를 단계적으로 확장합니다.
이 글에서 다룰 내용
도구 접근 통제가 필요한 이유, Connect·Control·Catalog·Harden 4단계, 실무 점검표
AI 에이전트의 도구 호출, 왜 통제가 필요할까요?
AI 에이전트는 답변만 생성하는 챗봇과 다릅니다. 데이터베이스를 조회하고, 업무 시스템에 정보를 입력하며, 외부 API를 호출하는 등 실제 도구를 사용할 수 있습니다.
문제는 에이전트가 필요 이상의 권한을 갖거나 신뢰하기 어려운 도구에 연결될 때 발생합니다. 잘못된 지시 하나가 개인정보 조회, 데이터 변경, 승인되지 않은 외부 전송으로 이어질 수 있기 때문입니다.
Amazon Bedrock AgentCore Gateway는 에이전트가 조직 도구에 접근하는 단일 보안 진입점을 제공합니다. AWS 공식 글은 AgentCore Identity로 인증·권한·자격증명을 다루고, AgentCore Policy로 도구 호출 정책을 적용하며, Guardrails와 AWS Agent Registry를 결합하는 구성을 설명합니다.
이 글에서 다룰 내용
Connect·Control·Catalog·Harden 4단계, AgentCore Identity·Policy·Guardrails의 역할, AWS Agent Registry와 감사·복구 설계
1단계 Connect: 통제된 단일 진입점을 만듭니다
AWS 공식 가이드의 첫 단계는 Connect입니다. 여러 로컬 설정에 흩어진 MCP 자격증명을 줄이고, 에이전트가 조직 리소스에 접근하는 경로를 AgentCore Gateway로 모으는 단계입니다.
공식 예시는 Amazon Cognito 기반 JWT 인증, AgentCore Identity의 외부 자격증명 관리, CloudWatch Logs와 CloudTrail 감사를 조합합니다. 초기에는 읽기 전용 검색처럼 위험이 낮은 도구 하나로 시작하고 기존 로컬 설정과 병행해 점진적으로 전환합니다.
이 단계의 목표는 모든 통제를 한 번에 완성하는 것이 아닙니다. 누가 어느 게이트웨이를 거쳐 어떤 조직 리소스에 접근했는지 추적 가능한 최소 경로를 먼저 만드는 것입니다.
AWS 글은 1~20명의 파일럿 사용자와 저위험 도구를 Connect 단계의 대표 조건으로 제시합니다. 이 수치는 보편적 기준이 아니라 AWS가 제시한 성숙도 모델의 예시 범위입니다.
2단계 Control: 사용자별 정책과 보호 장치를 적용합니다
두 번째 Control 단계는 단순한 기계 단위 인증에서 사용자 단위 신뢰로 이동합니다. AgentCore Policy의 Cedar 규칙으로 역할·토큰 클레임·입력 파라미터에 따라 도구 호출을 허용하거나 거부하는 구조입니다.
AWS 공식 글은 Policy를 먼저 LOG_ONLY 모드로 연결한 뒤 실제 결정 변화를 관찰하고, 검증 후 ENFORCE로 전환하는 순서를 설명합니다. Amazon Bedrock Guardrails는 PII 필터와 프롬프트 공격 탐지 같은 안전·개인정보 보호 통제를 더합니다.
외부 SaaS가 사용자 동의를 요구하면 AgentCore Identity의 3LO 흐름을 사용하고, 같은 신뢰 체계를 공유하는 내부 서비스는 OBO 토큰 교환을 검토할 수 있습니다. 실제 적용 여부는 연결 대상과 신원 공급자의 지원 범위를 확인해야 합니다.
핵심은 사용자·도구·파라미터별 정책 결정과 그 이유를 감사 로그에 남기는 것입니다. 정책 모드와 Guardrails 강도는 비프로덕션에서 먼저 검증한 뒤 올리는 편이 안전합니다.
3단계 Catalog: 승인된 도구를 발견·배포·비용 귀속합니다
세 번째 Catalog 단계는 등록 요청이 티켓에 쌓이거나 온프레미스·다른 클라우드·외부 SaaS까지 연결해야 할 때 도구 카탈로그와 셀프서비스 등록 흐름을 추가합니다.
AWS 공식 글은 AWS Agent Registry로 스킬과 도구를 발견하게 하고, 소유자·접근 그룹·환경·위험 등급을 담은 YAML 매니페스트와 코드 리뷰로 등록 변경을 관리하는 예시를 제시합니다.
온프레미스 대상은 PrivateLink나 Direct Connect 같은 경로를, SaaS는 아웃바운드 OAuth를 사용할 수 있습니다. 비용은 CloudWatch 지표와 Cost Explorer 태그를 도구·그룹별로 연결해 귀속하는 구성을 설명합니다.
이 단계에서도 MCP 보안의 핵심은 등록 자체가 아니라 승인 흐름입니다. 새 도구와 정책 변경을 코드 리뷰·보안 검사·스테이징 검증 뒤 운영에 반영해야 합니다.
4단계 Harden: 사설 연결·복구·폐기까지 운영합니다
마지막 Harden 단계는 규제 산업, 글로벌 사용자, 고가용성 요구가 생겼을 때 네트워크 경계와 복구 체계를 강화합니다. AWS 공식 예시는 PrivateLink 기반 사설 경로, 정책 우회를 막는 인바운드 전용 집행, CloudWatch·CloudTrail 감사 구성을 설명합니다.
Route 53 상태 확인과 다중 리전 액티브-패시브 구성을 사용하면 장애 시 복구 경로를 설계할 수 있습니다. 이때 도구는 재시도에도 안전하도록 멱등성을 고려해야 합니다.
등록 후 사용되지 않는 도구가 쌓이지 않도록 호출 지표를 기준으로 폐기 후보를 만들고, 알림·검토·정책 전환·삭제를 단계적으로 수행하는 워크플로도 포함됩니다.
이 단계의 목표는 보안 기능을 많이 붙이는 것이 아니라 정책 우회·공개 경로·단일 리전 장애·미사용 도구 같은 운영 위험을 가시화하고 복구 가능하게 만드는 것입니다.
안전한 Gateway 운영을 위한 체크리스트
먼저 로컬
mcp.json
에 흩어진 자격증명, 서로 다른 정책 설정, 감사 공백, 비용 귀속 불가, 검토되지 않은 통합을 목록화합니다. AWS 공식 글은 이를 credential sprawl, policy drift, audit gaps, cost opacity, shadow IT의 다섯 문제로 정리합니다.
다음으로 파일럿에서는 저위험 도구 하나와 중앙 인증·감사부터 시작합니다. 사용자별 통제가 필요해지면 Cedar 정책과 Guardrails를 LOG_ONLY 또는 탐지 중심으로 검증한 뒤 집행 단계로 전환합니다.
도구가 늘어나면 Registry와 코드 리뷰 기반 등록 흐름을 도입하고 비용 태그를 연결합니다. 운영 규모가 커지면 사설 연결, 장애 복구, 정책 대시보드, 미사용 도구 폐기까지 확장합니다.
마무리
Amazon Bedrock AgentCore Gateway를 도입하는 목적은 단순히 더 많은 도구를 에이전트에 연결하는 것이 아닙니다. 에이전트가 누구의 권한으로, 어떤 조건에서, 어느 도구를, 어디까지 사용할 수 있는지 명확하게 만드는 데 의미가 있습니다.
중요한 점은 네 단계를 한 번에 도입하는 것이 아닙니다. Connect로 경로를 통합하고, Control로 사용자별 정책을 적용하며, Catalog로 도구를 운영하고, Harden으로 사설 연결과 복구를 강화하는 순서로 현재 문제에 맞춰 확장해야 합니다.
한 줄 요약: AWS 공식 성숙도 모델의 Connect·Control·Catalog·Harden 4단계로 에이전트 도구 접근을 점진적으로 통제합니다.
