옥타 크로스 앱 액세스와 베드록 에이전트코어 기반 AI 에이전트 거버넌스 확장

게이트웨이 기반 중앙 통제 전환

AWS는 옥타 크로스 앱 액세스와 아마존 베드록 에이전트코어를 결합해 대규모 인공지능 에이전트의 권한을 중앙에서 제어하고 감사하는 아키텍처 개선 방안을 발표했다. 기존 1편에서 선보인 개별 에이전트와 도구 간의 직접 연결 방식을 벗어나, 에이전트코어 게이트웨이를 단일 진입점으로 설정하고 전용 정책 엔진을 도입하여 보안성과 확장성을 강화했다.

이번 변경으로 에이전트는 더 이상 개별 도구의 식별자나 토큰 교환 자격 증명을 직접 보유하지 않고 게이트웨이와만 통신하게 된다. 게이트웨이는 인바운드 인가자를 통해 에이전트의 권한 토큰을 검증하고 도구 실행 전 시더 정책 엔진을 호출해 사용자가 위임받은 권한 범위와 부합하는지 사전 검증을 수행한다.

확장성 한계와 전환 배경

이전 방식은 에이전트 하나와 소수의 도구 환경에서는 원활히 작동했으나 수백 개의 에이전트와 수천 개의 도구로 늘어나는 엔터프라이즈 환경에서는 구조적 한계에 부딪혔다. 모든 에이전트가 호출 대상 도구의 식별자를 직접 관리해야 했으므로 도구가 추가될 때마다 관련된 모든 에이전트의 설정을 수정해야 하는 복잡한 배선 문제가 발생했다.

또한 개별 에이전트의 실행 역할마다 토큰 교환 권한과 공급자 비밀 정보 접근 권한을 부여해야 해 불필요한 자격 증명 경로가 증식하는 보안 위험이 있었다. 각 도구 서버 코드 내부에 사용자 그룹 확인 로직을 중복 작성하는 방식 역시 규칙 파편화를 유발하고 중앙 감사를 어렵게 만드는 요인으로 지적되었다.

정책 평가와 관측성 구현

게이트웨이의 인바운드 인가자는 옥타 조직 인가 서버의 공개 설정과 사용자 정의 인가 서버 대상을 기반으로 특정 에이전트의 자격 증명 토큰만 수락하도록 설정된다. 도구 목록 조회 모드는 정적 스키마 방식을 적용하여 정책이 참조하는 도구 이름이 고정되도록 구성하며, 기본 거부 원칙을 따르는 시더 정책을 통해 허용된 작업과 권한 범위 태그를 일치시킨다.

외부 인프라인 아마존 EKS 환경에 배포된 보조 에이전트 역시 전용 역할을 통해 모델 호출과 로그 전송 권한만 부여받은 채 자체 게이트웨이를 거쳐 동일한 방식으로 제어된다. 외부 런타임 환경에서는 별도의 앞단 인가자가 없으므로 에이전트가 모델을 호출하기 전 토큰의 서명, 발행자, 대상자, 만료 시간, 클라이언트 식별자를 자체적으로 사전 검증하도록 설계했다.

지연 시간 측정 결과 게이트웨이의 인바운드 인증과 정책 검증 등 거버넌스 처리에 소요되는 중간값 시간은 약 0.2초 수준으로 나타났다. 이는 5.5초 이상 소요되는 실제 도구 실행 시간에 비해 매우 적은 비중이며, 오픈텔레메트리 기반 추적 스팬과 이벤트브릿지로 수신한 옥타 시스템 로그를 통합 조회해 인가 결정 과정을 단일 질의로 감사할 수 있음을 입증했다.

권한 위임과 동의 방식 비교

이번 방안에서 활용된 크로스 앱 액세스는 대상 애플리케이션의 인가 서버가 토큰 교환을 지원할 때 적합하며 관리자가 권한을 통제하므로 사용자에게 별도 동의 화면이 노출되지 않는다. 반면 깃허브처럼 독자적인 인가 서버를 사용하는 외부 서비스는 사용자별 개별 인가 동의 방식을 적용해야 하므로 애플리케이션의 특성에 맞춰 방식을 구분해야 한다.

권한 취소 동작에서도 명확한 차이가 확인되었는데 크로스 앱 액세스 방식은 사용자가 정지되면 약 5분의 토큰 유효 시간이 지난 후 다음 토큰 발급이 즉시 중단된다. 이에 비해 개별 동의 방식은 옥타에서 계정이 정지되어도 기존에 보관된 외부 서비스 접근 권한이 포털 인터페이스를 통해 직접 연결 해제되기 전까지 유지되는 특성을 보였다.

적용 요건과 설계상 제약

이 구조를 구현하려면 클러스터 관리 도구, 컨테이너 가상화 도구, 옥타 로그 스트리밍 기능, 클라우드 접근 권한 설정이 사전에 준비되어야 한다. 또한 EKS 노드 풀이 특정 아키텍처 환경으로 동작하는 점을 감안해 호환 컨테이너 이미지를 빌드해야 하며, 에이전트 소프트웨어 개발 키트가 로컬 주소에만 고정되지 않도록 실행 환경 변수를 적절히 지정해야 한다.

본문에 제시된 설정과 예시 코드는 개념 검증을 위한 샘플 수준이므로 엔터프라이즈 환경에 배포하기 전 조직의 보안 및 규정 준수 기준을 충족하도록 보완해야 한다. 아울러 기본 거부 정책이 적용되므로 정책 엔진 생성에 실패하거나 정책이 비활성 상태로 남아있으면 게이트웨이가 모든 도구 호출을 거부하게 되므로 배포 시 정책 상태를 면밀히 점검해야 한다.