Micha Rave, Hush Security CEO 겸 공동 창업자 – 인터뷰 시리즈

Micha Rave, Hush Security의 CEO 겸 공동 창업자는 소프트웨어 엔지니어링, 제품 관리, 엔터프라이즈 네트워킹, 클라우드 보안 및 아이덴티티 분야에 걸친 경력을 가진 경험 풍부한 사이버보안 및 기술 임원이다. 2024년에 Hush Security를 공동 설립하기 전, 그는 Proofpoint에서 클라우드 보안 제품 관리 수석 이사로 5년 이상 근무했으며, 그곳에서 Zero Trust Network Access (ZTNA)와 Secure Web Gateway (SWG) 제품 라인을 담당했다. 이전에는 Meta Networks에서 제품 관리 부사장으로 재직하며 엔터프라이즈 네트워킹 및 보안에 집중했으며, HARMAN International, Redbend, SanDisk, Hola, Jungo, Elbit Systems에서도 제품 및 엔지니어링 리더십 역할을 수행했다. 그의 배경은 실무 소프트웨어 개발 경험과 20년 이상에 걸친 보안, 네트워킹, 가상화 및 임베디드 기술 제품의 구축 및 상용화 경험을 결합한다.

Hush Security는 AI 에이전트 및 기타 비인간 아이덴티티를 보호하기 위해 장기 인증서와 정적 비밀을 아이덴티티 기반, 정책 제어 접근 방식으로 교체하는 사이버보안 기업이다. 이 플랫폼은 섀도우 및 내부 개발 에이전트를 포함한 AI 에이전트를 탐지하고, 검증 가능한 아이덴티티를 부여하며, 범위가 지정된 즉시 사용 권한, 중앙 집중식 정책 및 감사 가능한 활동 기록을 사용해 엔터프라이즈 시스템과의 상호 작용을 관리한다. 이 회사는 Meta Networks 뒤의 팀에서 온 보안 베테랑들에 의해 설립되었으며, Meta Networks는 2019년에 Proofpoint에 인수되었다. 2026년 7월, Hush는 Akamai Technologies가 전략적 투자자로 참여하고 Battery Ventures와 YL Ventures가 함께한 $30 million Series A 라운드를 진행했으며, 총 자금은 $41 million으로 늘어나 기업 AI 에이전트 및 비인간 인프라를 관리하는 기술을 확장하고 있다.

Hush Security를 설립하기 전, 당신은 Proofpoint에서 클라우드 보안을 포함한 보안 제품을 구축하고 이끌며 수년을 보냈습니다. 시장에서 무엇을 보고 Hush를 시작해야 한다고 확신했으며, 에이전시 AI의 급속한 부상에 따라 원래의 논제가 어떻게 발전했습니까?

Proofpoint에서 우리는 기업들이 인간 아이덴티티는 해결하면서 비인간 영역은 여전히 정적 비밀에 의존하는 모습을 보았습니다. 서비스 계정, 워크로드, 파이프라인 모두 아무도 소유하지 않고 만료되지 않는 키로 인증되고 있었습니다. 업계는 더 나은 볼트로 대응했지만, 이는 더 나은 금고일 뿐 해결책은 아닙니다.

창업 논제는 비인간 접근을 비밀에서 아이덴티티로 전환하는 것이었습니다. 검증 가능한 워크로드 아이덴티티, 필요 시 즉시 발급되는 단명 인증서, 인라인으로 적용되는 정책. 코드 재작성은 필요하지 않습니다.

Agentic AI가 이를 시급하게 만들었습니다. 에이전트는 실행 시 어떤 도구를 호출할지 판단하고 결정하는 NHI입니다. 정적 키를 제공하면 자동화된 소프트웨어에 프로덕션에 대한 지속적인 접근 권한을 부여한 것이며, 에이전트는 어떤 변경 프로세스에도 포함되지 않은 상태로 배포됩니다. 예를 들어 개발자가 화요일에 MCP 서버를 연결하면 금요일까지 고객 데이터에 접근하게 됩니다.

논제는 변하지 않았습니다. 범위만 바뀌었습니다. 아이덴티티 기반 접근은 워크로드에 대한 올바른 해답이었습니다. 에이전트에게는 유일한 실현 가능한 방법이기도 합니다: 존재하는 모든 에이전트를 파악하고, 기본적으로 최소한의 권한(least agency)을 부여하며, 모든 행동을 감사합니다. 인간에게는 IdP가 제공되었습니다. 에이전트도 필요하며, 그것이 바로 Hush입니다.

Hush는 기업 AI 에이전트가 인간 사용자의 접근 권한을 단순히 상속받는 것이 아니라 자체 아이덴티티와 위임된 권한을 가져야 한다고 주장합니다. 전통적인 Identity and Access Management (IAM) 시스템이 자율 에이전트를 다루기 어려운 이유는 무엇이며, 무엇이 변해야 합니까?

명백한 경우는 에이전트가 사용자를 대신해 행동하는 상황입니다. 더 어려운 경우는 전혀 사용자가 없는 에이전트, 예를 들어 예약 작업, 자율 SOC 응답자, 스스로 판단하고 실행하는 파이프라인입니다. 위임할 대상이 없기 때문에 팀은 넓은 권한을 가진 정적 서비스 계정과 영구 키라는 유일한 도구에 의존하게 됩니다. 이는 10년째 문제를 일으키고 있는 공유 비밀 모델과 동일하며, 이제는 즉흥적으로 동작하는 소프트웨어에 적용되고 있습니다.

반대편 시스템이 상황을 더욱 악화시킵니다. 대부분의 내부 API, 데이터베이스 및 MCP 서버는 실제 인가를 수행하지 않습니다. 이들은 사용자가 유효한 토큰을 보유하고 있는지만 확인하고, 토큰으로 무엇을 할 수 있는지는 검사하지 않습니다. 소유가 곧 권한이 되는 것입니다.

변경이 필요한 점: 인간이 있든 없든 모든 에이전트에 대해 암호적으로 발급된 고유 아이덴티티를 부여해야 합니다. 접근 권한은 작업 단위로 부여되며, 단명하고 범위가 지정된 형태로, 정책은 대상 시스템에 신뢰를 두는 것이 아니라 인라인으로 적용됩니다. 사용자가 존재할 경우, 에이전트의 권한은 사용자가 수행할 수 있는 범위와 해당 작업에 대해 에이전트가 허용된 범위의 교집합이 됩니다. 사용자가 없을 경우, 에이전트 자체의 아이덴티티와 정책이 전부가 됩니다. 인간에게는 최소 권한(least privilege)이 적용되었듯, 에이전트에게는 최소 권한(least agency)이 필요합니다.

AI 보안을 논할 때 \”least agency\” 개념을 사용합니다. least agency는 전통적인 사이버보안 원칙인 least privilege와 어떻게 다르며, 조직이 특정 작업에 대해 AI 에이전트에게 정확히 어떤 권한을 부여해야 하는지 어떻게 결정할 수 있습니까?

에이전트는 고정된 행동을 갖지 않습니다. 하나에게 CRM에 대한 읽기 권한과 이메일에 대한 쓰기 권한을 부여하면 두 개의 권한을 부여한 것이 아니라 그 사이의 모든 경로를 허용한 것이 됩니다. least privilege는 에이전트가 접근할 수 있는 범위를 제한하지만, 그 접근을 어떻게 활용해야 하는지는 규정하지 않습니다.

Least agency는 누락된 차원을 추가합니다: 어떤 작업을, 어떤 작업에 대해, 지금 바로. 티켓을 분류하는 에이전트는 읽고 댓글을 달아야 합니다. 토큰이 허용한다 하더라도 닫기, 삭제, 청구서에 접근할 필요는 없습니다. 작업이 끝나면 접근도 종료됩니다.

허용 범위를 결정하는 것은 추측이 아니라 관찰에서 시작됩니다. 에이전트를 실행하고 실제 호출을 관찰해 기준선을 정의하십시오. 그런 다음 세 가지 입력을 사용해 범위를 좁힙니다: 에이전트가 존재하는 작업, 에이전트가 행동하는 사용자(그들이 할 수 있는 것보다 더 많이 하지 않음), 그리고 각 행동의 파급 범위, 왜냐하면 댓글을 달고 결제를 연결하는 것이 동일한 승인 경로를 공유해서는 안 되기 때문입니다.

Least privilege는 누가 키를 가질지 결정합니다. Least agency는 내부에 들어갔을 때 무엇을 할 수 있는지를 결정합니다.

우리는 종종 에이전트에 우리의 신원을 ‘빌려주지만’, 에이전트가 우리와 동일한 수준의 권한을 갖게 하고 싶지는 않습니다—이것이 바로 least agency의 정의입니다.

Hush는 최근 3,000만 달러 규모의 시리즈 A를 유치해 총 자금 조달액을 $41 million으로 늘렸으며, Akamai가 Battery Ventures와 YL Ventures와 함께 전략적 투자자로 참여했습니다. Akamai의 참여가 자본 외에 어떤 가치를 제공하며, 파트너십이 Hush의 엔터프라이즈 AI‑agent 보안 확장에 어떻게 영향을 미칠 것으로 보십니까?

Akamai는 전 세계 대부분 기업의 트래픽 경로에 위치하고 있으며, 바로 그곳이 에이전트 보안이 존재해야 하는 자리입니다. 사후에 대시보드에서 에이전트를 관리하지 않습니다. 에이전트가 도구나 API를 호출하는 순간 인라인으로 관리합니다. Akamai는 이 모델을 기반으로 사업을 구축했습니다.

자본 외에 그들은 세 가지를 제공합니다: 이미 에이전트와 MCP 트래픽을 제어하는 방법을 묻는 CISO들에게 배포; 에이전트 신원이 실제 카테고리이며 기능이 아니라는 검증; 그리고 전 세계 규모의 머신‑투‑머신 트래픽을 보호한 수십 년의 경험, 이는 곧 에이전트‑투‑툴 트래픽이 될 것입니다.

Model Context Protocol (MCP)는 AI 에이전트를 도구 및 엔터프라이즈 데이터와 연결하는 중요한 계층으로 빠르게 자리 잡고 있습니다. 보안 관점에서 MCP가 도입하는 새로운 위험은 무엇이며, 조직은 에이전트, MCP 서버, 그리고 기본 리소스 간의 신원 및 권한 부여를 어떻게 고려해야 할까요?

MCP는 에이전트를 도구에 연결하는 일을 매우 간단하게 만들었습니다. 바로 그 점이 위험입니다. 개발자는 설정 파일에 서버를 추가하면 모델이 이제 Jira를 읽고, 데이터베이스를 조회하거나 이메일을 보낼 수 있게 됩니다. 검토도, 인벤토리도, 정책도 없습니다. 보안은 문제가 발생했을 때 비로소 알게 됩니다.

이제 세 가지 새로운 문제가 발생합니다:

1. Shadow MCP – 얼마나 많은 서버가 실행 중인지, 무엇에 접근하는지 아무도 모릅니다.
2. Credential sprawl – 대부분의 서버가 전체 표면을 허용하는 정적 토큰으로 인증하므로, 에이전트는 토큰이 할 수 있는 모든 작업을 얻게 됩니다.
3. The collapsed chain – 리소스는 MCP 서버의 자격 증명만을 보게 되므로, 어떤 에이전트가 어떤 사용자를 대신해 호출했는지 알 수 없습니다. 신원은 모든 상호 작용의 기반에 있어야 하며, 접근은 일시적이고, 범위가 지정되며, 에이전트와 사용자 권한에 기반해야 합니다.

Hush는 정적 비밀과 장기 인증 정보가 머신 접근을 위한 깨진 기반이라는 생각을 중심으로 처음 구축되었습니다. 대부분의 엔터프라이즈 인프라가 여전히 API 키, 토큰 및 기타 비밀에 크게 의존하고 있는 상황에서, 기업이 전체 기술 스택을 재구축하지 않고도 신원 기반의 단기 접근으로 현실적으로 전환하려면 어떻게 해야 할까요?

재구축하지 않습니다. 그렇다고 말하는 사람은 엔터프라이즈를 만나본 적이 없습니다. 우리가 보호하는 대부분은 ‘비인간 신원’이라는 용어가 나오기 전부터 존재했으며, 아직도 재작성되지 않고 있습니다.

그래서 우리는 그것을 요구하지 않습니다. Hush는 코드 변경 없이 배포되며 접근 경로에 자리 잡습니다. 첫 단계는 탐색입니다: 모든 비밀, 누가 사용하고 있는지, 무엇에 도달하는지, 런타임에서 실제로 무엇을 하는지. 대부분의 기업은 아직 그 그림을 본 적이 없습니다.

그 다음은 마이그레이션이 아니라 여정입니다. 탐색을 통해 죽은 비밀, 과도하게 범위가 지정된 비밀, 가장 위험한 비밀을 파악합니다. 먼저 그것들을 해결합니다. 그런 다음 정적 키를 단기, 신원 발급 인증 정보로 시스템별로 교체합니다. 애플리케이션은 여전히 키를 사용하고 있다고 생각하지만, 키는 더 이상 장기적이지 않으며 정책은 우리에게 이동합니다.

같은 모델이 15년 된 Java 서비스와 지난 주에 구축된 MCP 서버 모두에 적용됩니다. 위험이 있는 곳부터 시작하고, 증명하고, 계속 진행합니다.

AI 에이전트는 점점 더 인간을 대신해 작업을 수행하고, 많은 경우 다른 에이전트에게 작업을 위임합니다. 이러한 다중 에이전트 워크플로가 복잡해짐에 따라, 발생하는 모든 행동에 대해 신원, 권한 부여, 소유권 및 책임의 명확한 체인을 어떻게 유지할 수 있습니까?

실패 시나리오: 사용자가 오케스트레이터에 요청하고, 오케스트레이터가 두 번째 에이전트에 위임하며, 그 에이전트가 MCP 서버를 통해 도구를 호출하고, 그 도구가 서비스 계정으로 데이터베이스에 접근합니다. 네 번의 홉을 거친 뒤 로그에는 유효한 토큰 하나만 보입니다. 누가 요청했는지, 누가 결정했는지, 누가 책임이 있는지는 사라집니다.

해결책은 어느 홉에서도 신원이 무너지지 않도록 하는 것입니다. 모든 에이전트는 자체 암호화 신원을 가집니다. 위임 시 토큰을 넘겨주지 않고, 범위가 지정된 위임을 발행합니다: 이 하위 에이전트, 이 작업, 이 행동을 이 사용자를 대신해 수행합니다. 각 홉은 전체 체인과 자체 권한을 전달합니다.

책임은 인라인으로, 행동 지점에서 시행하고 로그를 남김으로써 확보됩니다. 게이트웨이는 허용된 작업, 호출한 내용, 그리고 그 뒤의 체인을 기록합니다.

멀티 에이전트 시스템은 이해하기가 점점 어려워질 것입니다. 각 행동에 대한 책임 사슬은 반드시 필요하지는 않습니다.

프롬프트 인젝션 및 기타 공격은 본래 정당한 AI 에이전트를 조작하여 운영자가 전혀 의도하지 않은 행동을 하게 만들 수 있습니다. 기본 AI 모델이 잘못 동작하더라도, 신원 기반 접근 제어가 손상되거나 조작된 에이전트로 인한 피해를 어느 정도 제한할 수 있을까요?

프롬프트 인젝션을 모델 수준에서 막을 수는 없습니다. 모델은 설계상 신뢰할 수 없는 콘텐츠를 읽습니다. 에이전트가 결국 잘못된 일에 설득될 것이라고 가정하십시오. 문제는 그런 상황에서 에이전트가 무엇을 할 수 있느냐입니다.

신원 기반 접근은 피해 범위를 제한합니다. 최소 권한을 가진 조작된 에이전트는 해당 작업을 위해 부여된 행동만 악용할 수 있습니다. 티켓을 읽고 댓글을 달 수 있다 하더라도, 어떤 인젝션도 고객 데이터베이스를 유출하게 만들지는 못합니다. 토큰은 그 범위에 도달하지 못합니다.

사용자 귀속은 체인을 온전하게 유지합니다: 어느 사용자, 어느 에이전트, 어느 작업, 모든 호출마다. 에이전트는 사용자가 할 수 있는 범위를 초과하지 않으며, 모든 행동은 추적됩니다.

이상 탐지는 정책이 허용하지만 의도가 아닌 경우를 포착합니다. 보통 다섯 개의 레코드를 읽는 에이전트가 갑자기 다섯 천 개를 가져오면, 각 호출이 승인되었더라도 비정상적인 행동입니다. 게이트웨이가 인라인에 위치하고 기준선을 알고 있기 때문에 실시간으로 이를 표시하거나 차단할 수 있습니다.

모델은 때때로 오류를 일으킬 수 있습니다. 범위가 지정된 신원, 귀속 및 행동 기준선은 오류가 발생해도 견딜 수 있게 합니다.

Hush는 주로 AI 보안에 집중하고 있지만, Hush 내부에서는 AI를 어떻게 활용하고 있나요? 비인간 신원 탐지, 접근 패턴 분석, 위험 우선순위 지정, 정책 시행 등 AI가 보안 플랫폼을 실질적으로 향상시킬 수 있는 영역이 있습니까?

우리는 그것이 가치를 입증하는 곳마다 사용합니다.

제품에서는 비밀을 찾는 것이 어려운 것이 아니라, 그 비밀을 이해하는 것이 어려운 부분입니다. 키가 트래픽에 나타납니다. 워크로드 신원, 벤더 통합, 개발 테스트 토큰, 사용되지 않는 자격 증명? LLM은 런타임 컨텍스트와 소유자 신호를 읽고 신뢰 점수와 함께 답변을 제안합니다. 그것은 신원이 실제로 수행하는 일을 평이한 인간 언어로 요약하여, 정책이 인간이 승인할 수 있게 합니다. 위험을 정적인 심각도가 아니라 실제 도달 범위와 피해 규모에 따라 순위 매깁니다. 시행은 결정론적이며 유지됩니다. AI는 정책 작성에 도움을 주지만, 런타임에서는 투표권을 갖지 않습니다.

Hush 내부에서는 에이전트 프로그래밍이 우리의 속도를 바꾸었습니다. 스프린트만에 개발하던 기능이 이제는 며칠이 걸리며, Series A 팀이 감당하기 어려운 속도로 통합을 제공합니다. LLM은 지원 티켓을 분류하고, 근본 원인을 클러스터링하며, 로드맵 논의를 위한 고객 요청을 도출합니다. 우리 자체 MCP 게이트웨이가 모든 앞에 위치해 고객이 NHI와 에이전트 위험을 이해하고 활용하도록 돕습니다.

Hush는 여러 Fortune 500 기업이 현재 자사의 기술을 사용하고 있으며, Kyndryl은 Hush를 내부에 배포하고 기업 고객에게 재판매를 시작했다고 말합니다. 이러한 대규모 배포를 통해 AI 에이전트가 실험 단계에서 실제 운영 단계로 전환될 때 기업이 직면하는 현실적인 거버넌스 문제에 대해 무엇을 배우고 있습니까?

누구도 자신이 무엇을 가지고 있는지 모릅니다. 모든 대규모 배포는 같은 방식으로 시작됩니다: 보안팀은 프로덕션에 약 열두 개의 에이전트가 있다고 생각하지만, 탐색 결과는 수백 개이며 이미 고객 데이터에 접근하고 있습니다. 거버넌스 문제는 정책이 아니라 먼저 인벤토리입니다.

자격 증명이 에이전트보다 더 문제입니다. 거의 모든 프로덕션 에이전트는 이전에 생성된 정적 서비스 계정으로 실행되며, 다른 용도로 수년간 누적된 권한을 가지고 있습니다. 이는 범위가 지정된 접근 권한을 부여받지 못했습니다.

소유권이 없습니다. 에이전트나 NHI에 대한 책임자를 물으면 최선의 경우 팀 이름, 떠난 계약자, 혹은 침묵만이 답입니다.

그리고 구매자가 바뀌었습니다. 이는 플랫폼 팀의 문제였습니다. 이제 이사회가 요구함에 따라 CISO가 소유하게 되었습니다. 이는 파일럿 단계에서 기업 전면 배포로 전환하게 했으며, Kyndryl이 재판매 전에 내부에 먼저 배포한 이유이기도 합니다.

에이전트가 새로운 거버넌스 문제를 만든 것은 아닙니다. 기업이 수십 년 동안 서비스 계정으로 무시해 온 문제들을 가져와 훨씬 악화시켰을 뿐입니다.

훌륭한 인터뷰에 감사드립니다. 더 알고 싶은 독자분들은 Hush Security를 방문하십시오.