⚡ 3줄 요약
- AI 에이전트 문제의 본질은 성능이 아니라 인증 정보가 손으로 관리되며 흩어진다는 것이다 — 에이전트 10개 × 내부 API 5개면 벌써 50벌.
- 중앙 게이트웨이는 인증 정보를 에이전트에 넘기지 않는다. 백엔드 자격증명은 AWS 밖으로 나가지 않고 게이트웨이가 대신 연결한다.
- 한 번에 다 깔지 마라 — 읽기 전용 도구 1개 + 시험 사용자 1~20명으로 시작하고, 문제가 실제로 터질 때만 통제를 늘린다.
AI 에이전트를 사내에 붙일 때 다들 모델 성능부터 본다. 그런데 정작 사고가 나는 지점은 답의 품질이 아니라 인증 정보(credential)가 어디에 몇 벌 흩어져 있는지다. 에이전트를 여러 개 풀었을 때 서로 충돌하고 악성 코드까지 심은 사례가 보여주듯, 권한을 먼저 긋지 않으면 수가 늘수록 위험만 커진다. 에이전트마다 설정 파일에 API 주소와 비밀번호를 손으로 박아 넣는 순간, 관리 대상은 산술급수가 아니라 곱셈으로 늘어난다. AWS의 계산은 냉정하다 — 에이전트 10개가 내부 API 5개에 붙으면 손으로 설정한 인증 정보 50벌이 된다. 여기서 API 키 하나를 교체하려면? 50군데 중 어디에 그 키가 박혀 있는지부터 찾아야 한다.
50벌의 인증 정보는 ‘많다’가 아니라 ‘통제 불능’이라는 뜻이다
AI 에이전트는 사람을 대신해 도구를 호출하는 프로그램이다. 문제는 각 에이전트가 자기 설정 파일(mcp.json 같은)에 도구 주소와 자격증명을 따로 들고 있다는 점이다. 연결이 늘수록 이 파일들이 조직 곳곳에 복제된다.
AWS는 이 상황을 이렇게 요약한다.
⚠️ 원문이 지적하는 핵심
“에이전트 10개가 내부 API 5개에 연결되면 각각 손으로 설정한 독립 인증 정보 50벌을 유지하게 된다.” 숫자 50이 무서운 게 아니라, 그 50벌이 서로를 모른다는 게 무섭다. 한곳의 권한을 바꿔도 나머지는 그대로 살아 있다.
이 구조가 방치되면 벌어지는 일은 예측 가능하다.
- 설정 파일마다 인증 정보가 제각각이 된다.
- 권한을 바꿔도 일부 도구에만 반영된다 — 나머지는 옛 권한으로 계속 돈다.
- 누가 어떤 도구를 언제 썼는지 추적할 방법이 없다.
- 팀별로 도구 사용 비용을 가를 수 없다.
- 아무도 검토하지 않은 연결(shadow MCP)이 조직 안에 자라난다.
중앙 게이트웨이의 진짜 값어치는 ‘인증 정보를 에이전트에 안 준다’는 것
AI와 외부 도구를 잇는 표준 약속이 MCP(Model Context Protocol)다. AWS가 내놓은 답은 이 MCP 요청을 전부 하나의 관문으로 모으는 것이다. 도구 접근 관문이 Amazon Bedrock AgentCore Gateway, 신원과 자격증명을 관리하는 쪽이 AgentCore Identity다.
요청은 이 순서로 흐른다.
- 에이전트가 사내 도구 사용을 요청한다.
- 요청이 중앙 게이트웨이로 들어온다.
- 게이트웨이가 로그인 증표인 JWT(Cognito 발급)를 검증한다.
- 요청자에게 그 도구를 쓸 권한이 있는지 규칙으로 판단한다.
- 필요하면 개인정보를 가리거나 위험한 입력을 차단한다.
- 게이트웨이가 대신 사내 도구에 연결한다.
- 누가 무슨 도구를 썼는지 기록을 남긴다.
여기서 설계상 가장 중요한 한 줄은 이것이다 — “백엔드 자격증명은 AWS를 떠나지 않는다(Backend credentials never leave AWS).” 에이전트는 진짜 API 키를 받아 들지 않는다. 게이트웨이가 신원을 확인한 뒤 자기가 쥔 자격증명으로 대신 호출한다. 그래서 에이전트가 탈취돼도 API 키 자체는 새지 않는다. 50벌을 손으로 관리하던 구조가, 게이트웨이 한 곳이 자격증명을 쥐는 구조로 바뀌는 것이다. 흩어진 자격증명이 어떻게 실제 침해로 번지는지는 에이전트들이 자격 증명을 재구성해 남의 서버를 뚫은 사고가 잘 보여준다.
판단과 필터링에 쓰이는 조각들도 이름이 붙어 있다. 권한 규칙은 Cedar 기반 RBAC/ABAC(역할과 상황을 함께 보는 정책 언어), 개인정보·공격 입력 필터는 Amazon Bedrock Guardrails다.
네 단계는 ‘한 번에 다 깔지 마라’는 설계다
AWS가 이 구조를 파는 방식에서 오히려 눈여겨볼 대목은, 처음부터 완성형을 강요하지 않는다는 점이다. 성숙도 여정을 Connect · Control · Catalog · Harden 네 범위로 쪼갠다. 각 단계는 그 자체로 값어치가 있고, 다음 단계의 문제가 실제로 나타날 때만 통제를 얹는다.
| 단계 | 추가되는 통제 | 넘어갈 신호 |
|---|---|---|
| Connect (연결) | SSO 로그인, 중앙 자격증명, CloudTrail 기록 | 시험 사용자·저위험 도구를 굴리기 시작할 때 |
| Control (통제) | Cedar RBAC/ABAC 권한, PII 마스킹, 3LO 동의 | “누가 뭘 썼는지” 설명이 안 될 때 |
| Catalog (목록) | 도구 등록(Agent Registry), 셀프 등록, 환경 간 연결, 비용 구분 | 도구 등록 요청이 반복될 때 |
| Harden (고도화) | 비공개 망 연결, 다중 리전 장애 전환, 운영 대시보드, 폐기 자동화 | 사용자 1,000명 초과 + 장애 대비가 필요할 때 |
단계별로 붙는 기술 이름을 풀면 이렇다. Connect는 관문 하나를 세워 SSO로 사용자를 확인하고 CloudTrail로 기록을 남긴다. Control은 역할·상황 기반 권한(Cedar)에 3LO 동의와 동적 등록(DCR)을 더한다. Catalog는 쓸 도구를 AWS Agent Registry에 올려 한 목록에서 찾고 팀별 비용을 가른다. Harden은 비공개 연결과 다중 리전 전환까지 얹는 단계로, AWS 자신도 “사용자 1,000명을 넘고 안전장치가 없을 때” 검토하라고 못 박는다.
첫 도입은 ‘읽기 전용 도구 1개’가 정답이다
AWS의 권고는 구체적이다 — 시험 사용자 1~20명, 위험도 낮은 도구 하나. 예컨대 데이터를 바꾸지 않는 읽기 전용 검색 도구를 첫 대상으로 삼는다. 코딩 보조 도구가 사내 이슈 정보를 읽게 하는 정도가 딱 이 구간이다.
이 첫 연결에서 반드시 먼저 정할 세 가지가 있다.
- 게이트웨이를 누가 운영할지 — 인프라 팀, 보안 팀, 아니면 공동 조직.
- 첫 연결 도구와 허용할 작업의 범위.
- 기존 설정 파일
mcp.json을 계속 허용할지 — 게이트웨이만 허용하면 통제는 깔끔해지지만 기존 업무가 끊길 수 있고, 둘 다 허용하면 전환은 쉽지만 우회 경로가 생긴다.
🎯 FEEDON의 선택 — 우리라면 이렇게 한다
중앙 게이트웨이를 깐다고 보안이 자동으로 완성되지는 않는다. 이건 AWS 자신도 인정하는 부분이다. 운영 주체와 권한 변경 절차가 없으면, 흩어져 있던 50벌의 문제가 중앙 설정 한 곳으로 옮겨 앉을 뿐이다. 게이트웨이는 통제 지점을 만들어 줄 뿐, 통제 정책까지 대신 써주지 않는다. AI 도구를 볼 때 모델 말고 경계부터 확인하라는 원칙이 여기서도 그대로 통한다.
그래서 순서는 늘 같다 — 연결 목록부터 적고 → 읽기 전용 도구 1개를 게이트웨이에 올리고 → SSO와 기록을 먼저 켠 뒤 → 문제가 실제로 터질 때만 권한·목록·장애대비를 얹는다. 위에서부터 Harden을 지르지 마라. 1,000명도 안 되는데 다중 리전 전환부터 켜는 건 낭비다.
내일 당장 할 수 있는 점검 순서
- 지금 에이전트와 사내 도구의 연결 목록을 전부 적는다.
- 각 설정 파일에 박힌 인증 정보와 담당자를 확인한다.
- 읽기 전용 도구 하나를 첫 중앙 연결 대상으로 고른다.
- 통합 로그인(SSO)과 사용 기록부터 켠다.
- 개인정보가 섞일 수 있는 요청과 허용 작업을 정한다.
- 실제 문제가 생길 때만 도구 목록·비용 구분을 추가한다.
- 사용자가 늘고 장애 위험이 커질 때 비공개 연결·장애 대비를 검토한다.
한 가지 짚고 넘어갈 건, 이 글의 구성은 AWS 관리형 서비스를 중심으로 짜였다는 점이다. 직접 운영하는 대안도 있고, 어느 쪽이 맞는지는 기존 인프라와 운영 인력에 달려 있다. 실제 조직에서 설정 오류나 보안 사고를 얼마나 줄이는지, 기능별 비용과 운영 난이도는 아직 공개 검증된 수치가 없다 — 이건 도입 전에 스스로 재봐야 할 숙제다.
지금 할 일
🔒 지금 할 일
- 지금 에이전트와 사내 도구의 연결 목록을 전부 적고, 각 mcp.json에 박힌 인증 정보와 담당자를 확인한다.
- API 키가 설정 파일마다 손으로 복제된 곳을 찾아, 게이트웨이가 대신 키를 쥐도록 옮길 대상을 추린다.
- 데이터를 바꾸지 않는 읽기 전용 도구 하나를 골라 시험 사용자 1~20명으로 첫 중앙 연결을 건다.
- 권한·목록보다 먼저 통합 로그인(SSO)과 사용 기록(CloudTrail)부터 켜서 누가 뭘 썼는지 보이게 한다.
- 게이트웨이 운영 주체와 권한 변경 절차를 문서로 정해, 흩어진 문제가 중앙 설정으로 옮겨앉지 않게 한다.
출처: AWS Machine Learning Blog 「Govern AI agent tool access with Amazon Bedrock AgentCore Gateway」 · 기능·구성은 변동될 수 있음
이 글은 FEEDON이 공개 1차 자료를 바탕으로 작성·검증했습니다.
