AI 에이전트는 게이트웨이보다 먼저 ID가 필요하다

Hush Security는 날카로운 주장과 함께 Google News에 등장했다. 기업은 AI 에이전트의 트래픽에 게이트웨이를 두기 전에 각 에이전트를 먼저 식별해야 한다는 것이다. 많은 에이전트가 여전히 사람의 권한을 빌리거나 자격 증명을 공유하기 때문에 이 쟁점은 중요하다. 게이트웨이는 연결을 검사할 수 있지만, 모든 호출자가 동일하게 보인다면 책임성을 확립할 수 없다.

이 주장은 Hush Security의 2026년 7월 자금 조달 발표와 비인간 ID 플랫폼 확장에 뒤따랐다. 이 회사는 3,000만 달러를 조달하고 에이전트를 발견하며, ID를 부여하고, 제한된 액세스를 중개하며, 활동을 기록하도록 설계된 Identity Gateway를 공개했다. 핵심 아이디어는 단순하다. 어떤 에이전트가 행동하는지 알기 전에는 보안 통제가 해당 에이전트를 신뢰성 있게 관리할 수 없다는 것이다.

이 입장은 엔터프라이즈 AI 전반에서 부상하는 게이트웨이 우선 접근법에 이의를 제기한다. Cisco, Palo Alto Networks, Microsoft 및 다른 보안 공급업체들은 이제 에이전트와 도구 사이에 통제를 배치하고 있다. 그러나 게이트웨이가 보는 것은 요청이며, 그 뒤에 있는 완전한 ID, 소유자, 위임된 권한 또는 실행 이력까지 반드시 파악하는 것은 아니다. 그 결과는 익숙한 보안 경계와 낯선 귀속 문제의 조합이다.

이는 게이트웨이의 중요성을 둘러싼 논쟁이 아니다. 게이트웨이는 인증, 정책 검사, 트래픽 검사, 도구 제한을 위한 유용한 집행 지점으로 남아 있다. 문제는 기업이 그 검문소를 통과하는 모든 주체에게 고유한 자격 증명을 발급하기 전에 검문소부터 설치하고 있는지다.

Google News 헤드라인이 가리키는 더 큰 ID 전환

Hush Security는 게이트웨이만으로는 해결할 수 없는 ID 문제로 AI 에이전트 보안을 재정의하고 있다.

이 회사는 비인간 ID에 초점을 맞춰 2025년 스텔스 모드에서 모습을 드러냈다. 여기에는 직원이 아닌 소프트웨어가 사용하는 서비스 계정, API 키, 액세스 토큰 및 기타 자격 증명이 포함된다. Hush는 처음에 기업이 오랫동안 겪어온 문제를 다뤘다. 조직은 종종 목록화, 교체, 폐기가 어려운 머신 자격 증명을 축적한다.

자율 에이전트는 위험도를 높인다. 하나의 작업 중 여러 시스템에 걸쳐 지침을 해석하고, 도구를 선택하며, 데이터를 검색하고, 조치를 수행할 수 있기 때문이다. 기존 자동화는 미리 정해진 순서를 따른다. 반면 에이전트는 새로운 정보를 받은 뒤 경로를 바꿀 수 있어, 실제 권한을 예측하기가 더 어렵다.

VentureBeat는 7월 30일 보도에서 Hush가 기존 작업을 에이전트 ID 게이트웨이로 확장하고 있다고 설명했다. 제안된 플랫폼은 에이전트와 기업 리소스 사이에 위치한다. Hush는 에이전트를 발견하고, 이를 사람 소유자와 연결하며, 작업별 액세스를 발급하고, 활동을 기록하며, 에이전트를 중앙에서 폐기할 수 있다고 말한다.

Hush는 자사의 액세스 모델을 “최소 에이전시(least agency)”라고 부른다. 이 용어는 사용자나 워크로드에 작업에 필요한 액세스만 부여하는 최소 권한 보안 원칙을 확장한 것이다. 최소 에이전시는 에이전트의 목표, 실행 맥락, 위임된 권한을 이 결정에 추가한다.

프로덕션 오류 진단을 요청받은 코딩 에이전트를 생각해 보자. 이 에이전트에는 로그, 소스 코드, 배포 메타데이터에 대한 읽기 권한이 필요할 수 있다. 그러나 청구 기록을 변경하거나, 고객 데이터베이스를 내려받거나, 자체 보안 정책을 다시 작성할 권한까지 자동으로 부여받아서는 안 된다.

같은 구분은 생산성 에이전트에도 적용된다. 회의 브리프를 준비하는 어시스턴트는 캘린더, 메모, 승인된 문서를 검색할 수 있다. 그렇다고 이를 실행한 직원이 접근 가능한 모든 사서함, 클라우드 드라이브 또는 관리 콘솔에 무제한으로 접근할 필요는 없다.

게이트웨이는 금지된 대상이나 형식이 잘못된 요청을 차단할 수 있다. 그러나 여러 에이전트가 동일한 OAuth 토큰이나 서비스 계정을 사용할 경우 정책은 둔감해진다. 게이트웨이는 승인된 자격 증명이 파일을 요청했다는 사실은 알 수 있다. 그러나 어떤 에이전트가 요청했는지, 왜 행동했는지, 그 행동이 원래의 위임 범위 안에 있었는지는 알지 못할 수 있다.

이 때문에 Google News 헤드라인은 일반적인 자금 조달 기사보다 더 큰 의미를 갖는다. Hush는 단순히 또 하나의 검사 계층을 추가하는 것이 아니다. 에이전트의 소유자, 목적, 권한, 세션, 행동을 관리하는 기준 기록이 ID가 되어야 한다고 주장한다.

이 모델은 사고 대응도 바꾼다. 보안팀은 보통 누가 리소스에 접근했는지 묻는 것으로 조사를 시작한다. 공유 자격 증명은 답을 애플리케이션, 직원 또는 서비스 계정 수준으로 축소할 수 있다. 특히 한 사람의 권한 아래 여러 자율 프로세스가 작동할 때, 고유한 에이전트 ID는 더 좁은 조사 출발점을 제공한다.

공유 자격 증명은 게이트웨이를 추측에 의존하게 만든다

게이트웨이는 각 요청에 연결된 ID와 맥락만큼만 정밀하게 정책을 집행할 수 있다.

많은 초기 엔터프라이즈 에이전트는 스크립트처럼 배포됐다. 개발자는 API 키를 저장하거나 서비스 계정을 할당하거나 인간 사용자의 OAuth 토큰을 그대로 전달했다. 이 방식은 프로토타입을 빠르게 작동시키지만, 여러 주체를 하나의 보안 ID로 합쳐 버린다.

직원, 에이전트 호스트, 모델, 개별 에이전트, 도구 세션은 모두 동일한 권한 부여 아래에서 보일 수 있다. 에이전트가 하위 에이전트를 생성하면 이 사슬을 재구성하기는 더욱 어려워진다. 다운스트림 서비스는 어떤 구성 요소가 작업을 시작했는지 모른 채 유효한 토큰을 받을 수 있다.

VentureBeat가 2026년 6월 107명의 엔터프라이즈 응답자를 대상으로 실시한 설문조사에 따르면, 69%가 에이전트 배포에서 공유 API 키를 사용했다. 에이전트 보안 연구에서는 82%가 주로 모델 공급업체나 하이퍼스케일러가 제공하는 통제에 의존하는 것으로 나타났다.

이러한 통제는 유용한 보호 기능을 제공한다. 프롬프트 필터는 알려진 인젝션 패턴을 탐지할 수 있고, 데이터 유출 방지 시스템은 민감한 콘텐츠를 표시할 수 있으며, 클라우드 정책은 관리형 리소스에 대한 액세스를 제한할 수 있다. 하지만 이런 기능 가운데 어느 것도 모든 에이전트 인스턴스에 고유한 ID를 자동으로 생성하지는 않는다.

이 설문조사에서 Microsoft Entra Agent ID의 응답자 도입률은 13%였다. 다른 ID 전용 제품의 비중은 한 자릿수에 머물렀다. 이러한 격차는 기업이 에이전트별 책임성보다 범용 AI 보호 체계를 더 빠르게 배포했음을 시사한다.

에이전트가 과도한 권한을 받으면 불균형은 더 심각해진다. 공유 관리자 자격 증명은 게이트웨이가 이를 모니터링한다고 해서 안전해지는 것이 아니다. 정책이 해당 자격 증명에 작업 수행을 허용한다면, 게이트웨이는 기술적으로 유효하지만 위험한 요청을 승인할 수 있다.

프롬프트 인젝션은 이 문제를 잘 보여준다. 에이전트는 신뢰할 수 없는 텍스트를 읽다가 기밀 자료를 가져오거나 구성을 변경하라는 지시를 받을 수 있다. 이 지시는 문서, 웹사이트, 이메일, 도구 응답 또는 데이터베이스 레코드를 통해 들어올 수 있다. 그러면 언어 필터는 정당한 의도와 조작된 의도를 구별해야 하는 어려운 과제에 직면한다.

ID 통제는 다른 계층을 다룬다. 모든 문장이 악의적인지 판단할 필요가 없다. 모델이 무엇을 결정하든 에이전트에 제공되는 최대 권한을 제한할 수 있다.

예를 들어 읽기 전용 권한을 가진 리서치 에이전트는 악의적인 지시를 마주친 뒤 소스 저장소를 삭제할 수 없다. 임시 지원 에이전트는 티켓이 종료된 뒤에도 고객 데이터 접근 권한을 유지할 수 없다. 결제 초안을 작성하도록 승인된 재무 에이전트는 정책이 두 작업을 모두 허용하지 않는 한 해당 결제를 승인할 수도 없다.

수명이 짧은 자격 증명은 노출을 더 줄인다. 재사용 가능한 비밀을 에이전트 환경에 넣는 대신, ID 시스템은 하나의 작업, 리소스, 시간 창에 대한 토큰을 발급할 수 있다. 토큰은 자동으로 만료되며 세션이 끝날 때 폐기할 수 있다.

이 모델은 더 나은 로그도 지원한다. 감사 기록에는 에이전트, 인간 후원자, 작업, 정책 결정, 사용한 자격 증명, 결과 조치가 식별되어야 한다. 게이트웨이 요청만 기록하면 사고 후 조사자가 너무 많은 것을 추론해야 한다.

기업은 이미 중요한 인간 활동을 관리할 때 맥락을 보존한다. 사용자, 기기, 애플리케이션, 세션, 인증 방법, 리소스를 기록한다. 자율 소프트웨어는 사람의 검토를 기다리지 않고 많은 작업을 실행할 수 있으므로, 최소한 이에 상응하는 세부 정보가 필요하다.

과제는 규모다. 조직은 직원을 채용하는 속도보다 더 빠르게 에이전트를 생성, 복제, 종료할 수 있다. 따라서 ID 프로비저닝은 자동화되어야 한다. 수동 등록은 지연을 만들고, 우회 방식을 부추기며, 거버넌스 밖에 섀도 에이전트를 남길 것이다.

이러한 압력은 수명 주기 관리를 필수로 만든다. 각 에이전트 ID에는 생성 이벤트, 소유자, 승인된 목적, 정책 집합, 만료 규칙, 폐기 경로가 필요하다. 이 가운데 어느 하나라도 정의되지 않으면, 게이트웨이는 조직이 완전히 설명할 수 없는 행위자로부터 트래픽을 받게 된다.

게이트웨이는 트래픽을 통제하지만, ID는 권한을 확립한다

가장 강력한 아키텍처는 ID를 권한의 원천으로, 게이트웨이를 그 권한이 집행되는 장소 중 하나로 다룬다.

AI 게이트웨이는 일반적으로 모델, 에이전트, 도구, 데이터 서비스 사이의 통신을 중개한다. 연결을 인증하고, 요청을 검사하며, 속도 제한을 적용하고, 콘텐츠를 필터링하고, 로그를 생성할 수 있다. MCP 게이트웨이는 Model Context Protocol 연결에 대해 유사한 작업을 수행한다.

MCP는 AI 애플리케이션이 공통 인터페이스를 통해 외부 도구를 발견하고 호출할 수 있게 하는 개방형 프로토콜이다. 맞춤형 통합 코드의 필요성을 줄이지만, 표준화된 연결은 에이전트가 도달할 수 있는 표면도 확장할 수 있다.

게이트웨이는 중앙 정책 검문소를 제공하기 때문에 유용해진다. 보안팀은 각 백엔드를 수정하는 대신 많은 도구 앞에 규칙을 배치할 수 있다. 그러나 이러한 아키텍처상의 편의는 에이전트가 누구인지, 권한이 어디서 비롯됐는지에 답하지 못한다.

ID는 그 기반을 제공한다. 고유한 ID는 에이전트를 코드, 호스트, 소유자, 작업, 승인된 기능에 연결할 수 있다. 그러면 권한 부여는 현재 조건에서 해당 ID가 무엇을 할 수 있는지 결정할 수 있다.

이 구분은 공항 보안검색대와 비슷하다. 모든 여행자를 검사하는 일은 가치가 있지만, 이 과정은 각 문서를 제시하는 여행자가 누구인지 아는 데 달려 있다. ID를 확립하지 않은 채 수하물만 검사하면 불완전한 보안 기록이 만들어진다.

미국 국립표준기술연구소는 2026년에 더 넓은 프레임워크에서 같은 구성 요소를 다뤘다. 에이전트 ID 프로젝트는 에이전트 식별, 권한 부여, 위임, 로깅, 투명성, 데이터 출처를 서로 연결된 작업 영역으로 제시했다.

NIST는 하나의 독점적 해법을 제안하는 대신 기존 기술을 지목했다. OAuth는 위임된 권한 부여를 전달할 수 있고, OpenID Connect는 인증된 주체 정보를 표현할 수 있으며, SCIM은 ID 프로비저닝을 지원할 수 있다. SPIFFE와 SPIRE는 소프트웨어 워크로드에 암호학적으로 검증 가능한 ID를 발급할 수 있다.

이 기술들은 문제의 서로 다른 부분을 해결한다. OAuth는 토큰이 어떤 액세스를 전달하는지 말한다. OpenID Connect는 인증된 당사자를 설명하는 데 도움이 된다. SCIM은 ID 레코드를 생성하거나 비활성화할 수 있다. SPIFFE는 통제된 인프라에서 실행 중인 워크로드가 자신이 주장하는 바로 그 워크로드임을 증명할 수 있다.

어느 하나도 자율 에이전트의 전체 수명 주기를 독립적으로 포착하지는 않는다. 기업은 여전히 워크로드 ID를 인간의 위임, 정책, 작업 범위, 행동 이력과 연결해야 한다.

그 빠진 연결 고리는 단순히 에이전트에 이름을 부여하는 것만으로는 충분하지 않은 이유를 설명한다. 요청 내부에서 자체 선언한 식별자는 변경되거나 복제될 수 있다. 신뢰할 수 있는 신원은 수신 서비스가 인정하는 시스템이 발급하거나 검증해야 한다.

신원은 인프라 전반을 이동하는 과정에서도 유지되어야 한다. 에이전트는 데스크톱 애플리케이션, 클라우드 컨테이너, 개발 환경, 관리형 플랫폼, 타사 서비스에서 실행될 수 있다. 하나의 클러스터에만 뿌리를 둔 자격 증명은 에이전트가 조직 경계를 넘을 때 의미를 잃을 수 있다.

OpenID Foundation의 에이전트 신원 관리 보고서는 이러한 이식성 문제를 설명한다. 이 보고서는 MCP 클라이언트 식별자가 반드시 신뢰할 수 있는 워크로드 또는 에이전트 신원은 아니라고 지적한다. 또한 에이전트가 신뢰 도메인을 넘나들 때 인프라 기반 증명이 더 어려워지는 이유를 설명한다.

이 문제는 인증과 대행성을 구분한다. 인증은 소프트웨어 구성 요소가 자격 증명을 통제하고 있음을 확립한다. 대행성은 해당 구성 요소가 왜 행동하는지, 누구를 위해 행동하는지, 그리고 현재 어떤 위임 권한을 보유하는지를 설명한다.

게이트웨이에는 두 종류의 정보가 모두 필요하다. 검증되지 않은 호출자는 거부해야 하지만, 위임받은 작업 범위를 초과하는 검증된 에이전트도 거부해야 한다. 인증 통과가 후원 사용자가 이용할 수 있는 모든 작업을 수행할 권한이 되어서는 안 된다.

Hush의 접근 방식은 리소스 접근에 앞서 정책 기반 신원 브로커링을 배치한다. 그러면 게이트웨이는 중개된 권한을 집행하는 메커니즘이 된다. 이 순서는 트래픽에서 먼저 신원을 찾아내는 게이트웨이보다 더 좁은 권한과 더 명확한 귀속을 지원한다.

이 아키텍처는 여전히 통합에 의존한다. 애플리케이션과 도구 서버는 수신하는 신원 클레임, 스코프 또는 기능 토큰을 준수해야 한다. 다운스트림 시스템이 모든 요청을 하나의 권한 높은 백엔드 계정으로 통합한다면 신원 기록은 집행 가치를 잃는다.

보안 벤더들이 같은 통제 지점으로 수렴하고 있다

시장은 에이전트 신원으로 이동하고 있지만, 벤더마다 신원, 네트워크 트래픽, 엔드포인트 동작 중 무엇이 집행을 주도해야 하는지에 대한 견해는 다르다.

Hush만 에이전트를 새로운 유형의 비인간 행위자로 보는 것은 아니다. Microsoft, Cisco, Palo Alto Networks, 1Password, Okta, Ping Identity와 여러 스타트업이 에이전트 중심의 신원 또는 거버넌스 기능을 선보였다.

Cisco의 Duo Agentic Identity는 인간 소유자와 연결된 별도 객체로 에이전트를 등록한다. 이 회사의 광범위한 보안 아키텍처는 MCP 게이트웨이를 통해 도구 호출을 라우팅할 수 있다. Palo Alto Networks는 Prisma AIRS 내에서 에이전트 레지스트리, 에이전트용 신원 제공자, 게이트웨이 통제를 제시했다.

Microsoft는 Entra, Purview, Defender, Sentinel 전반에 에이전트 거버넌스를 분산 배치한다. Entra Agent ID는 에이전트의 신원을 생성하고 관리하는 데 초점을 맞춘다. 다른 Microsoft 서비스는 데이터 통제, 위협 탐지, 모니터링을 담당한다.

CrowdStrike는 엔드포인트 활동을 강조한다. 이 접근 방식은 모델이 표현한 의도에만 의존하기보다 소프트웨어 프로세스가 디바이스에서 실제로 무엇을 하는지 추적한다. 인증이 성공한 뒤 파일 변경, 프로세스 실행 및 기타 구체적인 행동을 탐지하는 데 도움이 될 수 있다.

서로 다른 경로는 보완적이지만, 어느 쪽이 핵심 통제 플레인이 될지를 두고 경쟁한다. 신원 벤더들은 모든 행동이 신뢰할 수 있는 행위자와 범위가 제한된 권한에서 시작되어야 한다고 주장한다. 네트워크 벤더들은 게이트웨이를 핵심 검사 지점으로 본다. 엔드포인트 벤더들은 관측 가능한 실행에 초점을 둔다.

RSAC 2026은 이러한 범주가 얼마나 빠르게 수렴하고 있는지를 보여줬다. VentureBeat의 에이전트 보안 프레임워크 검토에 따르면 주요 벤더들은 레지스트리, 게이트웨이, 신원 객체, 런타임 모니터링을 도입했다.

남아 있는 격차는 단일 통제만으로는 충분하지 않은 이유를 보여준다. 에이전트는 모든 자격 증명 검사를 통과하고도 자신의 동작을 규정하는 정책을 수정할 수 있다. 게이트웨이는 각 도구 호출을 보더라도 위임 체인을 재구성하지 못할 수 있다. 엔드포인트 센서는 행동을 관찰할 수 있지만, 해당 에이전트에 유효한 비즈니스 권한이 있었는지는 알지 못할 수 있다.

멀티 에이전트 위임은 가장 어려운 사례를 만든다. 예를 들어 조달 에이전트가 리서치 에이전트에게 공급업체 비교를 요청한다고 가정해 보자. 리서치 에이전트는 다시 브라우징 에이전트를 생성하고, 이 에이전트는 타사 서비스에 문서를 요청한다.

각 인계는 권한을 축소하거나 유지해야 하며, 결코 조용히 확대해서는 안 된다. 최종 서비스에는 누가 작업을 시작했는지, 어떤 에이전트가 참여했는지, 요청된 행동이 원래 목적에 부합하는지를 판단할 수 있는 충분한 증거가 필요하다.

전통적인 사용자 가장은 이 경우 제대로 작동하지 않는다. 모든 하위 에이전트가 직원의 신원을 상속하면 다운스트림 시스템은 원래 사용자와 자율적 위임자를 구분할 수 없다. 침해된 하위 에이전트 하나를 해지하려면 전체 사용자 세션을 종료해야 할 수 있다.

더 나은 모델은 서명된 위임 체인을 유지하면서 각 에이전트에 고유한 신원을 부여한다. 하위 에이전트는 자신에게 할당된 업무에 필요한 권한의 하위 집합만 받는다. 로그는 인간 소유자, 상위 에이전트, 하위 에이전트, 그리고 그 결과로 발생한 행동 간의 관계를 보존한다.

이 구조는 보안 클라우드 워크로드가 단기 자격 증명을 교환하는 방식과 닮아 있다. 그러나 에이전트에는 불확실한 행동과 자연어 목표가 수반된다. 정책은 기술적 신원과 변화하는 작업 맥락을 모두 고려해야 한다.

실질적인 통합 문제도 있다. 기업은 이미 신원 제공자, 권한 액세스 시스템, API 게이트웨이, 서비스 메시, 엔드포인트 에이전트, 보안 모니터링 플랫폼을 운영하고 있다. 별도의 에이전트 신원 계층을 추가하면 또 하나의 콘솔과 단일 정보 원천이 생길 수 있다.

성공하는 접근 방식은 기존 신원 인프라와 연결되어야 한다. 모든 애플리케이션에 독점 프로토콜 채택이나 중복된 직원 디렉터리 유지를 요구하는 시스템은 보안 팀의 저항에 부딪힐 것이다.

이러한 압력은 표준 기반 클레임, 단기 토큰, 이식 가능한 감사 기록에 유리하게 작용한다. 또한 공식 등록을 요청하기 전에 섀도 에이전트를 발견할 수 있는 제품에도 유리하다.

직원들이 보안 승인 없이 코딩 어시스턴트를 설치하거나 로컬 에이전트를 연결할 수 있기 때문에 발견은 중요하다. 조직이 존재를 알지 못하는 에이전트에게는 완벽한 신원 정책도 아무런 효과가 없다. 네트워크, 엔드포인트, 클라우드, 신원 텔레메트리는 모두 이러한 배포를 찾아내는 데 기여한다.

따라서 시장의 수렴은 Hush의 전제를 뒷받침하지만, 모든 제품 주장을 검증하는 것은 아니다. 신원은 필수 요소가 되고 있지만 게이트웨이, 샌드박스, 엔드포인트 모니터링, 데이터 통제와 함께 작동할 것이다. 실제 경쟁은 어느 계층이 권위 있는 기록을 정의하느냐에 관한 것이다.

신원이 에이전트를 안전하게 만들지는 않는다

검증된 신원은 통제와 책임성을 개선하지만, 에이전트의 행동이 신뢰할 수 있음을 증명하지는 않는다.

이 한계는 신원 우선 서사에 대한 가장 강력한 도전이다. 인증된 에이전트도 잘못된 결정을 내리거나, 악의적인 지시를 따르거나, 데이터를 노출하거나, 안전하지 않은 도구를 호출할 수 있다. 신원은 방어자에게 누가 행동했는지를 알려준다. 그 행동이 합리적이었다는 보장은 하지 않는다.

전통적인 보안은 경고를 제공한다. 공격자가 자격 증명을 탈취하거나, 직원이 과도한 접근 권한을 받거나, 승인된 소프트웨어가 예기치 않게 동작하기 때문에 합법적인 계정도 많은 피해 사고를 일으킨다. 유효한 신원은 정책 결정의 시작일 뿐이다.

에이전트 시스템은 실행 중 계획이 바뀔 수 있어 불확실성을 더한다. 모델은 새로운 정보를 읽은 뒤 다른 도구를 선택할 수 있다. 제약 조건을 오해하거나 신뢰할 수 없는 콘텐츠를 지시로 간주할 수도 있다.

이 때문에 샌드박싱은 여전히 중요하다. 샌드박스는 실행을 격리해 침해되었거나 실수한 에이전트가 호스트 시스템에 자유롭게 영향을 미치지 못하도록 한다. 신원은 허용되는 리소스를 제한할 수 있고, 격리는 프로세스가 기술적으로 도달할 수 있는 범위를 제약한다.

프롬프트 및 출력 통제도 여전히 역할이 있다. 요청이 다른 시스템에 도달하기 전에 알려진 공격 패턴, 민감한 데이터 또는 금지된 콘텐츠를 포착할 수 있다. 그 약점은 의미 해석을 유일한 방어 수단으로 취급하는 데 있다.

완전한 아키텍처에는 심층 방어가 필요하다. 신원 계층은 행위자와 위임된 권한을 확립한다. 게이트웨이는 연결 정책을 집행한다. 샌드박스는 실행을 제한한다. 엔드포인트 및 클라우드 모니터링은 실제 동작을 기록한다. 데이터 통제는 민감한 정보를 제한한다.

정책 엔진은 에이전트의 통제 밖에 남아 있어야 한다. 에이전트가 자신의 권한을 정의하는 규칙을 편집할 수 있다면, 유효한 신원은 피해를 막는 대신 조사관이 피해의 책임 소재를 추적하는 데만 도움이 될 수 있다.

자격 증명 보호도 또 다른 위험을 제시한다. 모든 에이전트에 고유한 장기 비밀 값을 부여하면 귀속은 개선되지만, 공격자가 탈취할 수 있는 비밀의 수가 늘어난다. 신원 시스템은 단기 자격 증명을 발급하고 재사용 가능한 비밀은 에이전트 환경 밖에 보관해야 한다.

조직은 영구적인 에이전트 확산도 피해야 한다. 신원을 자동으로 생성하는 것은 유용하지만, 비활성 신원에는 자동 만료가 필요하다. 그렇지 않으면 기업은 관리되지 않는 API 키를 관리되지 않는 에이전트 계정으로 대체하게 된다.

인간 소유권 역시 오해를 불러일으킬 수 있다. 에이전트를 직원에게 매핑한다고 해서 그 직원이 모든 행동을 검토했다는 뜻은 아니다. 책임성 기록은 후원, 승인, 운영, 실행을 구분해야 한다.

관리자가 워크플로를 승인하고, 개발자가 에이전트를 배포하며, 또 다른 직원이 작업을 시작할 수 있다. 이 세 역할을 하나의 “소유자” 필드로 압축하면 잘못된 확실성을 만들 수 있다.

데이터 출처에도 비슷한 주의가 필요하다. 에이전트는 문서, 생성된 텍스트, 도구 응답, 기억된 맥락을 결합할 수 있다. 보안 로그는 필요 이상의 민감한 콘텐츠를 수집하지 않으면서도 어떤 정보가 중요한 행동에 영향을 주었는지 보존해야 한다.

지식 근로자에게 이 문제는 사이버 보안을 넘어선다. 에이전트는 개인 메모, 프로젝트 문서, 기록, 과거 결정에 점점 더 많이 작용한다. 잘 정리된 개인 지식 베이스는 맥락을 개선할 수 있지만, 접근에는 여전히 명확한 경계가 필요하다.

주간 업데이트를 준비하는 에이전트에는 선택된 프로젝트 기록이 필요할 수 있다. 모든 정보가 한 사용자에게 속한다는 이유만으로 모든 개인 메모에 대한 무제한 접근 권한까지 상속해서는 안 된다. 신원과 작업 범위는 유용한 맥락과 불필요한 노출을 구분하는 데 도움이 된다.

따라서 Hush의 주장은 프로덕션 환경에서 독립적인 검증이 필요하다. 구매자는 이 시스템이 에이전트 인스턴스를 암호학적으로 식별하는지, 기존 신원 제공자와 통합되는지, 그리고 다운스트림 도구까지 신원을 전파하는지를 물어야 한다.

또한 해지 속도, 정책 실패 시의 동작, 위임 추적, 로그 완전성을 테스트해야 한다. 도구 호출 중 맥락을 잃거나 장애 발생 시 광범위한 접근으로 기본 설정되는 통제 플레인은 줄이겠다고 약속한 위험을 다시 만들 수 있다.

회사의 자금 조달 및 제품 발표는 시장 의도를 보여줄 뿐, 측정된 보안 결과를 입증하지는 않는다. 공개된 증거는 아직 이 플랫폼이 모든 데스크톱, 클라우드, 관리형 에이전트 환경에서 어떻게 작동하는지 보여주지 않는다.

이 불확실성이 신원 우선 아키텍처를 무효로 만드는 것은 아니다. 이는 제품을 평가해야 할 기준을 정의한다. 유용한 질문은 대시보드가 에이전트를 나열하는지가 아니다. 신원이 해당 에이전트의 권한을 일관되게 제한하고, 귀속하며, 종료하는지다.

Google News 독자가 다음으로 주목해야 할 점

세 가지 신호는 에이전트 신원이 실제 인프라가 될지, 아니면 보안 마케팅 범주에 머물지를 보여줄 것이다.

첫 번째 신호는 프로덕션 환경에서 고유한 신원을 채택하는 것이다. 보안 팀은 발견되거나 등록된 에이전트 수를 넘어 살펴봐야 한다. 의미 있는 척도는 활성 에이전트 중 얼마나 많은 수가 공유 자격 증명이나 제한 없는 인간 토큰 사용을 중단했는지다.

변화의 증거로는 단기 자격 증명, 작업 범위로 제한된 접근 권한, 자동 만료, 그리고 에이전트 식별자를 보존하는 다운스트림 서비스 등이 있을 수 있다. 공유 키가 여전히 일반적이라면, 게이트웨이 도입만으로는 책임성 격차를 해소할 수 없다.

기업들이 공유 서비스 계정은 줄이고 취소 가능한 에이전트 세션은 늘었다고 보고할 때, 이 신호는 신원 우선 주장을 강화할 것이다. 반대로 런타임 접근 권한은 그대로인 채 신원 제품이 자산 목록 대시보드에만 머문다면 이 주장은 약화될 것이다.

두 번째 신호는 위임 체인 지원이다. 기업용 에이전트는 점점 더 하위 작업을 만들고, 전문 에이전트를 호출하며, 조직 경계를 넘나들게 될 것이다. 제품은 이러한 인계 과정 전반에서 권한을 보존해야 한다.

신뢰할 수 있는 구현이라면 최초의 인간 후원자, 참여한 모든 에이전트, 이전된 권한, 그리고 그에 따른 행동을 보여줘야 한다. 각 하위 신원에는 상위 에이전트가 위임할 수 있는 범위를 넘지 않는 권한만 부여되어야 한다.

표준화 기구와 벤더가 이러한 관계를 상호운용 가능하게 표현하는 방식을 주시해야 한다. 독점적인 위임 기록은 하나의 플랫폼 안에서는 작동할 수 있지만, 기업은 여러 제공업체의 에이전트를 사용한다. 플랫폼 간 검증이 벤더 환경 밖에서도 신원이 유지되는지를 결정할 것이다.

MCP 도구, 에이전트 플랫폼, 신원 제공업체가 검증 가능한 위임 증거를 교환할 수 있다면 이 신호는 논지를 강화한다. 모든 플랫폼이 경계 지점에서 에이전트를 일반 사용자 토큰으로 다시 변환한다면 논지는 약화된다.

세 번째 신호는 사고 격리다. 신원은 에이전트가 잘못 행동하거나 침해를 당했을 때 가장 중요하다. 벤더는 방어 담당자가 직원, 애플리케이션 또는 전체 워크플로를 중단하지 않고도 하나의 에이전트를 격리할 수 있음을 입증해야 한다.

유용한 테스트에는 즉각적인 권한 취소, 기존 세션 거부, 하위 에이전트 차단, 그리고 작업 체인 재구성이 포함된다. 또한 조직은 신원 인프라를 사용할 수 없게 되었을 때 정책 집행이 안전하게 실패하는지도 검증해야 한다.

보안팀은 신원 시스템, 게이트웨이, 엔드포인트, 다운스트림 애플리케이션의 로그를 비교해야 한다. 이러한 기록을 상호 연관지을 수 없다면, 기업은 여전히 사고에 대한 신뢰할 수 있는 단일 기록을 확보하지 못한 것이다.

성공 사례는 에이전트 신원이 단지 가시성뿐 아니라 결과를 바꾼다는 점을 보여줌으로써 Hush의 입지를 강화할 것이다. 인증되었지만 격리되지 않은 에이전트와 관련된 사고가 반복된다면, 시장이 신원을 독립적인 방어 수단으로 과대평가했음을 보여줄 것이다.

Google News의 프레이밍은 순서를 대체로 올바르게 짚었다. 기업은 게이트웨이를 충분한 거버넌스로 간주하기 전에 에이전트가 누구인지, 누구의 권한을 보유하는지, 그리고 그 권한이 얼마나 오래 지속되는지를 확립해야 한다.

다음 단계는 실용적이다. 생성 시점부터 최종 도구 호출까지 운영 중인 에이전트 하나를 감사하라. 팀은 그 소유자, 작업, 자격 증명, 권한, 하위 에이전트, 데이터 접근 권한, 권한 취소 경로를 식별할 수 있는가? 답변 중 어느 하나라도 공유 토큰이나 트래픽에서의 추론에 의존한다면, 신원 기반이 준비되기 전에 게이트웨이가 도입된 것이다.