Axonius는 기존 AWS 배포를 떠받치는 고객별 격리 모델을 포기하지 않으면서 자사 사이버보안 SaaS 플랫폼에 AI 에이전트를 추가하고 있으며, 이는 새로운 AWS Machine Learning Blog 사례 연구에 따라 알려졌다.

이 회사는 Amazon Bedrock AgentCore를 사용해 수백 개의 개별 고객 환경에서 에이전트를 실행했다. 이 설계는 에이전트 기능을 추가하는 소프트웨어 공급업체가 직면한 핵심 문제를 다룬다. 즉, 에이전트는 여러 테넌트에서 유용해야 하면서도 자신이 서비스하는 고객의 데이터, API, 신원 제어, 운영 비용에 제한되어야 한다.

AWS는 이 아키텍처와 보고된 이점을 벤더가 작성한 게시물에서 설명한다. 출처에는 Axonius의 독립적인 성능 테스트나 고객 의견이 없으므로, 배포 규모와 운영 결과에 대한 주장은 AWS가 보고한 것으로 간주해야 한다.

Axonius는 사일로 기반 SaaS 모델을 유지한다

Axonius는 보안 및 IT 팀을 위한 자산 인텔리전스 플랫폼을 제공한다. AWS에 따르면 이 서비스는 1,400개 이상의 시스템에서 정보를 대조하며 수백 개의 격리된 고객 환경을 운영한다. 각 고객 워크로드는 로드 밸런서, 데이터베이스, 범용 컴퓨팅 인프라 같은 구성 요소를 포함한 전용 Amazon Virtual Private Cloud, 즉 Amazon VPC에서 실행된다.

게시물에서 설명한 첫 번째 AI 에이전트는 대규모 엔터프라이즈 환경을 분석하고, 격차와 위험을 식별하며, 여러 통합에서 들어오는 수백만 개의 데이터 포인트를 해석한다. AWS는 이 기능이 주니어 분석가가 복잡한 분석을 수행할 수 있도록 하면서, 시니어 분석가가 수동 조사에 몇 시간을 쓰지 않아도 되게 하려는 목적이라고 말한다.

Axonius는 그 워크로드를 공유 SaaS 아키텍처로 옮기는 대신, 기존 테넌트 모델을 따르는 에이전트를 원했다. 이 결정이 기술 요구사항을 형성했다. 즉, 한 고객의 환경을 처리하는 에이전트는 다른 고객의 데이터에 접근해서는 안 되며, 동시에 서비스의 기존 인증, 배포, API 패턴과 통합되어야 한다.

AI 빌더에게 중요한 점은 여기서의 멀티테넌시는 단순히 요청에 고객 ID를 할당하는 문제가 아니라는 것이다. 에이전트는 보안 제품에 기대되는 경계를 유지하는 방식으로 배포, 권한 부여, 연결, 모니터링, 청구되어야 한다.

서로 다른 트레이드오프를 가진 세 가지 배포 패턴

AWS는 SaaS 에이전트 배포를 위한 세 가지 일반적인 패턴인 사일로, 풀, 브리지에 따라 설계 선택을 설명한다.

사일로 아키텍처에서는 각 테넌트가 전용 리소스를 받는다. AgentCore Runtime에 적용하면 고객마다 전용 에이전트를 배포하는 것을 의미할 수 있다. 이는 명확한 인프라 경계를 제공하지만, 프로비저닝, 업데이트, 모니터링, 종료해야 할 리소스 수를 늘린다.

풀 모델은 공유 리소스를 사용한다. 하나의 에이전트가 여러 테넌트에 서비스를 제공할 수 있으며, 각 세션은 고유한 세션 ID를 받는다. AWS는 AgentCore Runtime이 각 세션에 전용 microVM을 제공하고, 애플리케이션 수준의 제어가 테넌트 간 분리를 처리한다고 말한다.

이 접근 방식은 배포와 고객 온보딩을 단순화하지만, 애플리케이션에 더 많은 책임을 부여한다. 에이전트는 각 요청에서 테넌트 컨텍스트를 올바르게 해석하고 테넌트 간 접근을 방지해야 한다. 테넌트별 동작은 공유 배포에서 추가 조건 로직을 필요로 할 수도 있다.

브리지 모델은 두 접근 방식을 결합한다. 에이전트 런타임은 공유하되, 도구 계층에서는 더 엄격한 테넌트 강제를 적용한다. AWS가 논의한 아키텍처에서 AgentCore Gateway는 에이전트와 외부 도구 사이에 위치해, 도구 호출이 실행되기 전에 테넌트 경계를 기준으로 검사할 수 있게 한다.

AWS는 이 하이브리드 패턴을 인프라 오버헤드를 줄이면서도 고객 시스템 접근에 대한 더 강력한 제어 지점을 유지하는 방법으로 제시한다. 사례 연구는 프로덕션 구현의 모든 세부 사항을 공개하지 않으므로, उपलब्ध한 증거만으로는 Axonius가 각 구성 요소를 공유 리소스와 전용 리소스 사이에 어떻게 분배했는지 평가할 수 없다.

신원과 도구 접근은 격리 경계의 일부다

Axonius는 이미 테넌트별 Amazon EC2 인프라에서 실행되는 인증 및 권한 부여 모듈을 갖고 있었다. 요구사항은 그 ID 흐름을 대체하지 않고 에이전트를 추가하는 것이었다.

AWS는 테넌트가 Amazon Cognito 같은 OAuth 2.0 신원 제공자를 통해 인증하는 설계를 설명한다. 토큰에는 예를 들어 사용자 지정 테넌트 ID 같은 테넌트별 클레임이 포함된다. AgentCore Runtime의 내장 JWT 권한 부여기는 신원 제공자의 discovery endpoint를 사용해 토큰을 검증하고, 에이전트는 클레임을 읽어 요청을 올바른 고객 환경으로 라우팅한다.

이 분리는 중요하다. 토큰 검증은 요청이 허용된 신원 제공자에서 왔음을 확인하지만, 에이전트와 그 도구는 여전히 테넌트 클레임을 올바르게 적용해야 한다. 실제로 보안 경계는 플랫폼의 권한 부여 메커니즘과 신원을 API, 데이터 저장소, 도구에 매핑하는 코드 모두에 의존한다.

같은 원칙이 서비스 통합에도 적용된다. AWS는 테넌트와 연결된 에이전트가 그 테넌트의 API에 안전하게 접근해야 한다고 말한다. 게시물은 AgentCore Gateway를 외부 도구 호출의 잠재적 강제 지점으로 제시하며, 도구가 고객 워크로드와 상호작용하기 전에 테넌트 컨텍스트를 확인할 수 있는 계층을 만든다.

증거, 비용 통제, 운영 규모

AWS는 모델 호출이 에이전트 비용의 상당 부분을 차지할 것으로 예상되기 때문에 비용 추적을 Axonius의 핵심 요구사항 중 하나로 꼽는다. 테넌트별 회계는 SaaS 제공업체가 AI 기능의 가격을 정하고, 사용 한도를 설정하고, 비정상적으로 높은 소비를 보이는 고객이나 워크플로를 식별하는 데 도움이 될 수 있다.

회사는 또한 기존의 사일로 기반 지속적 전달 프로세스에 에이전트 워크로드를 추가해야 했다. 이 요구사항은 쉽게 간과된다. 프로토타입에서는 잘 작동하는 아키텍처도 각 고객 환경이 고유한 배포 수명주기를 가지면 운영이 어려워질 수 있다.

관측 가능성도 또 다른 우려 사항이었다. AWS는 Axonius가 많은 수의 에이전트를 대상으로 장애를 조사할 수 있을 만큼 충분한 세부 정보를 갖춘 플릿 수준 모니터링, 경보, 트레이싱이 필요했다고 말한다. 이러한 요구는 에이전트 운영을 일반적인 애플리케이션 모니터링과 다르게 만든다. 팀은 서비스가 이용 가능한지뿐 아니라 어떤 모델 호출, 도구, 세션, 테넌트 권한이 결과에 기여했는지도 이해해야 한다.

이용 가능한 증거는 독립 감사인이나 고객 인터뷰가 아니라 AWS에서 나온 것이다. AWS는 AgentCore가 Axonius가 컴퓨트 격리, 인증, 관측 가능성에 대한 맞춤 인프라를 처음부터 구축하지 않고도 격리된 멀티테넌트 에이전트를 배포할 수 있게 했다고 보고한다. 이는 플랫폼의 역할에 대한 벤더 주장이지, 엔지니어링 시간, 보안, 총비용에 대한 독립 검증 비교는 아니다.

빌더와 기업 구매자에게 의미하는 것

SaaS 회사에게 Axonius 사례는 에이전트 추가를 위한 실용적인 순서를 보여준다. 기존 테넌트 모델에서 시작해 데이터와 도구 경계를 식별하고, 어떤 제어가 런타임, 애플리케이션, 또는 게이트웨이 계층에 속하는지 결정하는 것이다.

선택은 제품 경제에도 영향을 준다. 전용 리소스는 더 명확한 격리와 맞춤화를 제공할 수 있지만, 공유 런타임은 온보딩과 운영을 단순화할 수 있다. 브리지 설계는 중복을 줄일 수 있지만, 모든 도구 경계에서 신중한 정책 집행이 필요하다. 어떤 모델도 권한 부여 실패, 잘못된 테넌트 클레임, 과도한 도구 권한, 우발적 데이터 유출을 테스트할 필요성을 없애지 못한다.

AI 기능을 평가하는 기업 구매자는 벤더에게 테넌트 ID가 에이전트 요청을 어떻게 따라가는지, 도구 호출이 독립적으로 권한 부여되는지, 모델 사용량이 어떻게 귀속되는지, 사고 대응을 위해 트레이스가 어떻게 분리되는지를 물어봐야 한다. 이런 질문은 에이전트가 민감한 자산, 구성, 취약점 정보를 처리할 수 있는 보안 소프트웨어에서 특히 중요하다.

더 넓은 시장 시사점은 에이전트 플랫폼이 모델 접근뿐 아니라 운영적 기본 요소에서도 경쟁하고 있다는 점이다. 런타임 격리, 신원 통합, 게이트웨이, 배포 자동화, 관측 가능성은 에이전트가 데모에서 SaaS 제공업체가 수백 개 환경에서 지원할 수 있는 제품으로 넘어갈 수 있는지를 좌우할 수 있다.

다음에 주목할 점

다음 신호는 Axonius나 AWS의 구체적인 프로덕션 세부 정보가 될 것이다. 회사가 프로덕션에서 공유 런타임, 전용 런타임, 또는 브리지 구성을 사용하는지, 테넌트 수준 비용 귀속이 어떻게 구현되는지, 그리고 어떤 제어가 애플리케이션 코드와 AgentCore Gateway 중 어디에서 강제되는지 등이다.

빌더는 배포 오버헤드, 사고 처리, 격리 테스트에 대한 독립적인 증거도 주시해야 한다. 모델 선택, 처리량, 지연 시간, 그리고 첫 번째 Axonius 에이전트를 운영하는 비용에 대한 더 많은 세부 정보가 나오면, 명시된 설계 목표를 넘어 아키텍처를 판단하기 쉬워질 것이다.

Creati.ai 관점

Axonius의 사례는 보안 제품에 챗봇을 추가하는 것보다, 기존 SaaS 제어 평면에 에이전트 실행을 맞추는 데 더 가깝다. 어려운 작업은 신원, 데이터 접근, 도구, 청구, 릴리스, 디버깅을 요청의 소유자인 테넌트에 연결하는 것이다.

AWS 사례 연구는 관리형 에이전트 인프라가 ISV에 매력적인 이유를 보여주지만, 플랫폼 추상화가 애플리케이션 수준 보안 위험을 제거한다는 것을 증명하지는 않는다. 빌더에게 가장 강한 교훈은 테넌트 라우팅과 도구 권한 부여를 제품 핵심 제어로 다루고, 대규모 아키텍처를 선택하기 전에 배포 및 실패 데이터를 통해 벤더의 주장을 검증하라는 것이다.