How Axonius built secure multi-tenant AI agents on Bedrock AgentCore

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Axonius는 기존 고객별 사일로형 SaaS 배치를 유지해 테넌트마다 전용 AgentCore 런타임을 두고, 데이터 격리·기존 인증 연동·비용 추적·수명주기·관측성 요구를 함께 다루는 AI 에이전트 구조를 선택했다.

📌 핵심 요약

• Axonius는 1,400개가 넘는 시스템의 데이터를 통합하는 자산 인텔리전스 플랫폼으로, 보안·감사·규정 준수의 수작업 부담을 최대 50% 줄이고 AWS에서 수백 개의 격리된 고객 환경을 운영한다.
• 첫 AI 에이전트는 수십 개의 동시 통합 소스에서 나오는 수백만 개의 데이터 포인트를 분석해 대규모 기업 환경의 격차와 위험을 식별하며, 주니어 분석가가 시니어 분석가의 장시간 수작업 없이 복잡한 분석을 수행하도록 지원한다.
• 검토된 풀·브리지·사일로 모델은 각각 신속한 온보딩과 운영 단순성, 게이트웨이 기반의 계층적 통제, 고객별 전용 컴퓨팅과 최대 격리를 제공하며, 사일로에는 AWS 계정당 기본 1,000개 에이전트 할당량과 높은 운영 부담이라는 제약이 있다.
• Axonius의 핵심 요구사항은 민감한 고객 데이터의 테넌트 격리, 기존 Amazon EC2 인증·권한 부여 모듈과의 연동, 테넌트별 모델 비용 추적, 고객 API에 대한 안전한 접근, 기존 CD 흐름 편입, 대규모 에이전트 관측성이었다.
• 최종 구조는 고객별 전용 AgentCore 런타임과 세션별 격리 microVM을 중심으로 Amazon ECR, Amazon Bedrock, IAM 역할 태깅, Amazon Bedrock Knowledge Bases와 Amazon S3 Vectors, 메타데이터 필터링, Amazon Bedrock Guardrails를 결합한다.

🧩 주요 포인트

1. 풀 모델은 하나의 런타임과 JWT 라우팅으로 운영과 온보딩을 단순화하지만 격리가 애플리케이션 코드에 의존하고, 브리지 모델은 Gateway의 Cedar 정책과 Lambda 인터셉터로 통제를 강화하는 대신 구성 요소와 네트워크 복잡성을 늘린다.
2. Axonius의 고객별 Amazon VPC 구조와 기존 테넌트 관리 방식은 전용 런타임을 사용하는 사일로 모델과 직접 맞물리며, 새로운 AI 기능을 도입하면서도 기존 격리 경계를 유지하게 했다.
3. 사일로 모델의 전용 AgentCore 런타임과 IAM 정책은 권한 경계를 단순화하고 테넌트별 독립 구성을 허용하지만, AWS 계정당 기본 1,000개 에이전트 할당량과 수백 개 런타임의 배포·업데이트·관측 부담을 함께 관리해야 한다.

🧠 상세 정리

1. ISV의 멀티테넌트 AI 과제와 Axonius의 배경

독립 소프트웨어 공급업체는 AI 에이전트를 서비스에 추가할 때 보안, 확장성, 출시 속도, 비용 추적을 고려해야 하며, 이러한 문제를 전체 서비스뿐 아니라 각 테넌트 수준에서도 해결해야 한다. Axonius는 보안 및 IT 팀이 위험의 우선순위를 정하고 수정 작업을 조율하도록 돕는 자산 인텔리전스 플랫폼이다. 1,400개가 넘는 시스템의 데이터를 하나의 권위 있는 정보원으로 통합해 관련 팀의 협업을 지원하고, 보안·감사·규정 준수에 드는 수작업 부담을 최대 50% 줄인다. Axonius는 AWS에서 SaaS 인프라를 운영하며 수백 개의 고객 환경을 서로 격리해 관리하므로, AI 에이전트를 추가할 때도 고객별 보안 경계를 유지하는 것이 중심 과제가 됐다.

2. 풀·브리지·사일로 멀티테넌시 패턴

멀티테넌트 AI 에이전트의 배치 방식은 풀, 브리지, 사일로의 세 가지 공통 패턴으로 구분된다. 풀 모델에서는 하나의 에이전트가 여러 테넌트를 담당하고, AgentCore 런타임이 사용자 세션마다 고유한 세션 ID와 격리된 microVM을 할당하지만 데이터와 도구의 테넌트 라우팅은 공유 구조 안에서 처리된다. 사일로 모델은 테넌트마다 전용 에이전트와 런타임을 제공해 컴퓨팅과 권한 경계를 분리한다. 브리지 모델은 일부 구성요소를 전용으로 두고 다른 구성요소를 공유하는 혼합 방식이며, 전용 AgentCore 런타임과 공유 Amazon Bedrock Knowledge Bases를 함께 사용하는 구성이 그 예로 제시됐다.

3. 첫 AI 에이전트와 기존 사일로 환경

Axonius의 첫 AI 에이전트는 대규모 기업 환경의 상태를 해석하고 격차와 위험을 찾아내기 위해 설계됐다. 이 에이전트는 수십 개의 동시 통합 소스에서 유입되는 수백만 개의 데이터 포인트를 분석하고 의미를 파악하며, 주니어 분석가가 시니어 분석가의 장시간 수작업을 점유하지 않고도 복잡한 분석을 수행하도록 지원한다. 기존 SaaS 배치는 고객마다 전용 Amazon VPC를 제공하는 사일로 구조이며, 각 VPC에는 Application Load Balancer, Network Load Balancer, 데이터베이스와 일반 컴퓨팅 인프라가 포함된다. Axonius는 AI 기능을 위해 테넌트 관리 방식을 바꾸기보다 이 기존 구조를 유지하고 고객별 에이전트를 배치하는 방향을 택했다.

4. 격리·인증·비용·운영 요구사항

가장 우선적인 요구사항은 민감한 고객 데이터를 다루는 에이전트가 해당 고객의 데이터에만 접근하도록 테넌트 범위를 엄격히 제한하는 것이었다. 기존 인증 및 권한 부여 모듈은 테넌트에 할당된 Amazon EC2에 있으므로, AI 에이전트의 신원 흐름은 이 모듈을 중단하거나 대체하지 않고 연동돼야 했다. 모델 호출이 에이전트 비용의 대부분을 차지할 수 있기 때문에 테넌트별 모델 비용을 추적하고 이를 향후 가격 책정 판단에 활용할 수 있어야 했으며, 각 에이전트는 해당 고객 워크로드의 API에도 안전하게 접근해야 했다. 이와 함께 에이전트 배포를 기존 사일로형 CD 흐름에 포함하고, 많은 수의 에이전트를 추적하면서 장애 알림과 디버깅용 추적 기능을 제공하는 관측성도 필요했다.

5. 옵션 1: JWT 기반 공유 풀 런타임

풀 옵션은 하나의 AgentCore 런타임을 여러 테넌트가 공유하되 각 세션을 전용 microVM으로 분리하고, 애플리케이션 수준에서 테넌트를 구분하는 방식이다. 테넌트는 OAuth 2.0 신원 공급자가 발급한 JWT로 인증하며, 토큰에는 custom:tenant_id와 같은 고유 테넌트 클레임이 포함될 수 있다. 런타임의 JWT 권한 부여 기능은 검색 URL에서 공개 키를 가져와 토큰 발급자를 검증하고, 에이전트 코드는 해당 클레임을 읽어 올바른 고객 환경으로 도구 호출과 데이터 접근을 전달한다. 하나의 런타임만 배포·모니터링·업데이트하면 되고 신규 고객을 별도 인프라 프로비저닝 없이 빠르게 온보딩할 수 있지만, 격리가 애플리케이션 코드의 정확성에 의존하고 테넌트별 맞춤 구성에는 조건부 로직이 추가된다는 한계가 있다.

6. 옵션 2: Gateway 통제를 결합한 브리지 모델

브리지 옵션도 하나의 AgentCore 런타임과 세션별 microVM을 공유하지만, 모든 외부 도구 호출을 AgentCore Gateway로 보내 에이전트 코드 바깥에서 테넌트 경계를 검사한다. Cedar 규칙은 호출자의 신원 속성과 요청된 도구를 비교해 결정적인 허용 또는 거부 판단을 내리고, REQUEST Lambda 인터셉터는 JWT에서 테넌트 문맥을 추출한 뒤 STS AssumeRole을 통해 수명이 짧은 테넌트 범위 IAM 자격 증명으로 교환한다. Gateway는 인터셉터를 Cedar 정책보다 먼저 실행하므로 동적으로 보강된 요청 문맥을 정책 판단에 사용할 수 있고, RESPONSE 인터셉터로 신원에 따라 검색 가능한 도구를 필터링할 수도 있다. 이중 통제는 에이전트의 라우팅 버그가 있더라도 교차 테넌트 호출을 막고 Amazon CloudWatch에 결정을 기록하는 중앙 거버넌스를 제공한다. 반면 Gateway, 인터셉터, 테넌트 매핑, Cedar 정책, STS 신뢰 관계와 VPC 엔드포인트를 함께 구성해야 해 다른 옵션보다 설정과 네트워크의 복잡성이 커진다.

7. 옵션 3: 테넌트별 전용 사일로 런타임

사일로 옵션은 테넌트마다 별도의 AgentCore 런타임과 엔드포인트를 두며, 런타임과 엔드포인트 양쪽의 IAM 리소스 기반 정책으로 호출 권한을 통제한다. 동일 계정의 역할이나 교차 계정 신원 모두 해당 테넌트 런타임에 대한 명시적 권한이 있어야 하고, 같은 테넌트 내부에서도 사용자 세션마다 격리된 microVM이 실행되므로 프로세스 상태를 공유하지 않는다. 이 구조는 테넌트 간 공유 컴퓨팅을 없애고 애플리케이션 라우팅 로직 없이 권한 경계를 단순화하며, 고객마다 서로 다른 에이전트 버전·모델·엔드포인트 설정을 적용할 수 있게 한다. 그러나 AWS 계정당 에이전트 기본 할당량은 1,000개이므로 고객 규모가 커지면 용량 계획과 할당량 조정이 필요하고, 신규 런타임과 엔드포인트 생성으로 온보딩 지연도 발생한다. 수백 개 런타임을 모니터링하고 업데이트하려면 CDK나 CloudFormation 파이프라인과 중앙 관측성을 포함한 강한 운영 자동화가 요구된다.

8. Axonius가 선택한 전용 런타임 아키텍처

Axonius는 현재의 사일로형 운영 방식과 고객별 보안 경계를 유지하기 위해 각 고객에게 전용 AgentCore 런타임과 에이전트를 제공하는 구성을 선택했다. AgentCore 런타임에서는 각 사용자 세션이 격리된 microVM으로 실행되고, Amazon ECR은 테넌트별 에이전트 컨테이너 이미지를 저장한다. 기반 모델은 Amazon Bedrock이 제공하며, IAM 역할 태깅을 사용해 비용을 테넌트별로 할당할 수 있도록 구성한다. 검색 증강을 위해 Amazon Bedrock Knowledge Bases와 비용 효율성 및 확장성을 고려한 Amazon S3 Vectors를 사용하고, 메타데이터 필터링으로 테넌트별 데이터를 격리한다. Amazon Bedrock Guardrails는 모든 모델 응답에 콘텐츠 필터링과 주제 거부 정책을 적용하며, Amazon CloudWatch도 다수의 에이전트를 관측하기 위한 모니터링 구성요소로 제시된다.

🧾 핵심 주장 / 시사점

• Axonius의 선택은 새로운 AI 기능보다 기존 고객별 Amazon VPC 격리 방식과 테넌트 관리 방법을 우선해 아키텍처의 연속성을 확보한 사례다.
• 풀·브리지·사일로의 차이는 단순한 배포 형태가 아니라 테넌트 격리 책임을 애플리케이션 코드, Gateway 정책, 전용 인프라 중 어디에 둘 것인지의 차이다.
• 사일로 모델은 최대 격리와 독립 구성을 제공하는 대신 AWS 계정당 기본 1,000개 에이전트 할당량, 프로비저닝 지연, 대규모 런타임 운영 부담을 수반한다.

✅ 액션 아이템

• Axonius의 고객별 전용 AgentCore 런타임이 데이터 격리·기존 인증 연동·고객 API 접근 요구를 충족하는지 검증.
• Amazon Bedrock 모델 호출 비용을 테넌트별로 추적하기 위한 IAM 역할 태깅 적용 범위를 점검.
• AWS 계정당 기본 1,000개 에이전트 할당량과 수백 개 AgentCore 런타임의 배포·업데이트·관측 부담을 고객 증가 규모에 맞춰 평가.

❓ 열린 질문

• Axonius의 고객 수가 AWS 계정당 기본 1,000개 에이전트 할당량에 가까워질 때 어떤 용량 계획과 할당량 조정이 필요한가?
• Amazon Bedrock 모델 호출 비용을 IAM 역할 태깅으로 테넌트별 어느 수준까지 구분할 수 있는가?
• AgentCore 사일로 모델의 최대 격리가 풀 모델의 신속한 온보딩보다 Axonius에 계속 우선되는 조건은 무엇인가?