제이콥 이데스코그, 커티티의 CTO – 인터뷰 시리즈

제이콥 이데스코그는 아이덴티티 전문가이자 커티티의 CTO입니다. 그는 대부분의 시간을 API와 웹 공간의 보안 솔루션에 작업하는 데 보냅니다. 그는 대규모 기업 배포와 작은 스타트업 모두에서 OAuth와 OpenID Connect 솔루션을 설계하고 구현하는 데 작업했습니다.

커티티는 커티티 아이덴티티 서버를 중심으로 구축된 현대적인 아이덴티티 및 액세스 관리(IAM) 플랫폼입니다. 이는 애플리케이션, API 및 디지털 서비스를 위한 인증 및 인가의 보안을 제공하기 위해 설계된 표준 기반 솔루션입니다. OAuth 2.0 및 OpenID Connect와 같은 프로토콜을 지원하여 로그인 흐름을 중앙화하고, 세분화된 액세스 정책을 적용하며, 인간 사용자와 API와 서비스를 포함한 기계 클라이언트 모두를 위한 보안 토큰을 발급합니다. 이 플랫폼은 유연성과 확장성을 위해 설계되어 조직이 클라우드, 하이브리드 또는 온프레미스 환경에 배포하고, 기존 시스템과 통합하며, 별도로 구축한 보안 인프라에 의존하지 않고 사용자에게 안전하고 원활한 경험을 제공할 수 있습니다.

당신은 아이덴티티 및 API 보안 시스템을 구축하는 데 대부분의 경력을 보냈습니다. 커티티의 공동 설립자에서 CTO로 이끌면서 클라우드와 지금 AI의 부상과 함께 어떻게 그 여정이 AI 에이전트를 인간과 같은 1차 디지털 아이덴티티로 다루어야 한다는 당신의 관점을 형성하게 되었나요?

저가 작업한 모든 기술 분야에서 하나의 문제가 계속해서 재현됩니다. 클라우드 컴퓨팅이나 지금 AI와 같은 경우, 소프트웨어가 사람이나 다른 시스템을 대신하여 작동할 때, 아이덴티티 문제가 발생합니다.

에이전트형 AI의 대규모 채택으로 인해 이 문제가 복잡해집니다. 에이전트의 행동은 더 이상 엄격하게 스크립트에 의해 정의되지 않으며, 이전에 기업이 본 적 없는 수준의 자율성을 가지고 작동합니다. AI 에이전트는 결정하고, API를 호출하고, 시스템 전반에서 작업을 연결하며, 직접적인 인간의 감독 없이 진행되는 경우가 많습니다. 이는 전통적인 소프트웨어와는 근본적으로 다른 아이덴티티 및 액세스 문제를 제기합니다.

AI 에이전트를 1차 디지털 아이덴티티로 다루는 것이 이 문제를 해결하는유일한 방법입니다. 조직이 에이전트를 단순히 또 하나의 프로세스 또는 서비스 계정으로 취급한다면, 조직은 가시성과 제어력을 빠르게 상실하게 됩니다. 이는 보안 위기를 초래할 수 있습니다.

많은 기업은 에이전트형 AI에 대해 흥미를 느끼고 있지만, 여전히 실험 단계에 머물러 있습니다. 실제 배포에서 보이는 것에 따르면, 에이전트를 안전하게 확장하는 것을 방해하는 가장 일반적인 아이덴티티 및 거버넌스 격차는 무엇인가요?

대부분의 실험은 에이전트가 실제로 작동하는 환경을 무시하는 격리된 샌드박스에서 발생합니다. 초기 테스트 기간에, 팀은 에이전트에 대한 광범위한 API 키, 공유 자격증명 또는 제한 없는 클라우드 권한을 제공하여 프로젝트를 시작합니다.

그러나 이 접근 방식은 에이전트가 테스트를 넘어 배포될 때 실패합니다. 이유는 보안 팀이 에이전트가 액세스한 데이터, 에이전트의 행동, 또는 에이전트가 의도한 권한 범위를 초과할 수 있는지 또는 이미 초과했는지, 그것이 우발적인지 악의적인지를 확인할 수 없기 때문입니다. 이러한 블라인드 스폿은 에이전트를 안전하게 거버넌스하는 것을 불가능하게 만듭니다. 이는 많은 조직이 테스트를 넘어 확장하는 것을 어려워하는 이유입니다.

당신은 에이전트형 AI에 대해 엄격한 가드레일이 필수적이라고 주장했습니다. 에이전트형 AI의 경우 “좋은” 아이덴티티 디자인은 어떻게 보이고, 회사들은 일반적으로 어디에서 잘못된 선택을 하나요?

좋은 아이덴티티 디자인은 최소한의 권한과 명시적인 의도에 따른 권한을 시작점으로 합니다. 각 AI 에이전트는 자신의 아이덴티티, 협소한 권한 및 명확하게 정의된 신뢰 관계(어떤 시스템과 상호작용할 수 있는지에 대한 명시적인 규칙)를 가져야 합니다. 기본적으로, 액세스는 목적에 바인딩되어야 하며, 시간 제한이 있어야 하며, 쉽게 취소할 수 있어야 합니다.

회사들이 잘못된 선택을 하는 곳은 기존의 서비스 계정을 재사용하거나 내부 에이전트가 기본적으로 안전하다고 가정하는 곳입니다. 이 가정은 실제 위협에 대처하지 못합니다. 악의적인 행위자는 이러한 약점을 찾으려고적극적으로 노력하며, AI 에이전트는 아이덴티티 디자인을 느슨하게 할 때 잠재적인 위험 영역을 크게 증가시킵니다.

커티티는 오랫동안 OAuth 및 OpenID Connect와 같은 표준을 작업해 왔습니다. 복잡한 기업 환경에서 에이전트형 AI를 상호 운용성과 보안을 제공하는 데개방형 아이덴티티 표준이 얼마나 중요한가요?

개방형 표준은 절대적으로 중요합니다. 기업은 이미 클라우드 플랫폼, SaaS 서비스 및 내부 API를 아우르는 복잡한 아이덴티티 패브릭을 실행하고 있습니다. 에이전트형 AI는 더 많은 복잡성을 추가합니다.

표준이 없으면, 각 에이전트는 자체적인 통합이 되며, 영구적인 보안 예외가 됩니다. OAuth 및 OpenID Connect와 같은 표준을 사용하면, 에이전트는 다른 워크로드와 마찬가지로 인증, 인가 및 감사가 가능합니다. 이는 실제 기업 환경에서 안전한 확장을 제공하는유일한 접근 방식입니다.

비인간 아이덴티티(Non-human identities)가 더 일반적으로 되고 있습니다. 서비스 계정, 머신 아이덴티티 등이 있습니다. 보안 관점에서 이전의 비인간 아이덴티티와 에이전트형 AI를 구분하는 핵심 차이는 무엇인가요?

현대적인 에이전트형 AI와 이전의 비인간 아이덴티티(NHIs) 간의 핵심 차이는 자율성입니다. 전통적인 서비스 계정은 코드가 지시하는 바를 정확히 수행하며, 엄격하게 작업에 바인딩되어 있습니다. 에이전트형 AI는 지시를 해석하고, 행동을 적응시키며, 명시적으로 스크립트되지 않은 작업을 수행합니다. 적절한 보호 장치가 없다면 이러한 특성 모두가 잠재적인 위험을 키웁니다.

작은 아이덴티티 또는 액세스 오류는 빠르게 재앙으로 변할 수 있습니다. 왜냐하면 에이전트는 속도와 여러 시스템에서 작동할 수 있기 때문입니다. 이는 주요한 위험을 나타냅니다.

에이전트형 AI를 거버넌스하는 데 감사 트레일과 아이덴티티 기반 로깅이 얼마나 중요한가요? 특히 규제 산업의 경우?

감사 트레일은 “좋은 것”으로 남겨둘 수 없습니다. 그것은 처음부터 구축되어야 합니다. 규제 환경에서, 조직은 간단하지만 중요한 질문에 답해야 합니다. 이 에이전트는 무엇에 액세스했나요? 언제 발생했나요? 그리고 누가 승인했나요?

아이덴티티 기반 로깅은 이러한 책임을 얻는유일한 신뢰할 수 있는 방법입니다. 또한 사고 대응에서 핵심적인 역할을 합니다. 아이덴티티 컨텍스트가 명확하지 않으면, 문제가 에이전트의 잘못된 행동, 침해된 아이덴티티, 또는 단순히 나쁜 프롬프트에서 발생했는지 여부를 알 수 없습니다.

조직이 생산 환경에서 과도한 권한을 가진 에이전트 또는 부적절하게 모니터링된 에이전트를 배포할 때 실제로 발생하는 위험은 무엇인가요?

한 가지 일반적인 위험은 조용한 데이터 수집입니다. 과도한 권한을 가진 에이전트는 여러 시스템에서 고객 기록, 내부 문서, 로그 같은 민감한 정보를 수집한 뒤 프롬프트, 요약 또는 외부 통합을 통해 노출할 수 있습니다.

또 다른 위험은 관리자 권한을 가진 에이전트가 기계 속도로 중요한 변경을 수행해 짧은 시간에 인간이 할 수 있는 것보다 훨씬 큰 피해를 일으키는 것입니다. 여기에는 클라우드 리소스 수정, 보안 제어 비활성화, 감독 없는 자동화 워크플로우 실행이 포함될 수 있습니다. 이러한 사건은 악의적일 수 있지만, 반드시 그럴 필요는 없습니다. 과도한 권한을 가진 에이전트 또는 부적절하게 모니터링된 에이전트는 단순히 구식 또는 잘못된 가정에 따라 작동할 수 있으며, 누군가 알아차리기 전에 여러 시스템에서 오류를 증폭시킬 수 있습니다.

그러나 공격자의 관점에서 보면, 침해된 에이전트 아이덴티티는 매우 가치가 있습니다. 이는 API와 서비스 전반에 걸친 측면 이동을 가능하게 하며, 어떤 인간 사용자에게도 부여되지 않을 수준의 접근 권한을 제공하는 경우가 많습니다. 강력한 아이덴티티 컨트롤과 모니터링이 없으면, 조직은 실제로 손상을 입은 후에야 이러한 실패를 발견합니다.

실제 에이전트 배포로 넘어가는 회사에서, 비싼 재설계를 피하기 위해 초기에 어떤 아이덴티티 및 액세스 결정이 있어야 하나요?

조직은 에이전트가 아이덴티티를 발급받는 방법, 권한이 승인되는 방법, 액세스가 시간의 경과에 따라 검토되는 방법을 결정해야 합니다. 아이덴티티 경계를사전에 정의해야 합니다.

아이덴티티 컨트롤을사후적으로 도입하는 것은 거의 항상 문제가 됩니다. 에이전트는 공유 자격증명 또는 광범위한 역할을 사용하여 워크플로우에 깊숙이 내장되어 있으므로,사후적으로 액세스를 강화하면 워크플로우가 중단되고, 기술에 대한 신뢰가 훼손됩니다. 초기에 적절한 아이덴티티, 범위 및 액세스 경계를 설계하는 것이 훨씬 더 저렴하고, 또한 훨씬 더 안전합니다.

에이전트형 AI를 롤아웃할 때 아이덴티티 통합이 가장 자주 병목 현상을 일으키는 곳은 어디이며, 이러한 마찰을 줄이는모범 사례은 무엇인가요?

아이덴티티 관리는사후적으로 처리될 때 병목 현상을 일으킬 수 있습니다. 팀은 먼저 에이전트의 인상적인 기능을 구축한 다음, 나중에 그것을 IAM 시스템, API 게이트웨이 및 로깅 플랫폼과 통합하여진정으로 안전하게 만들 필요가 있습니다.

최선의 접근 방식은 아이덴티티 플랫폼에 대한 명확한 이해와 적절한 구현에서 시작하는 것입니다. 그런 다음 에이전트를 이러한 플랫폼 내에서 설계해야 합니다. 기존의 표준과 인프라를 재사용해야 하며, 이를 우회하면 나중에 문제가 발생할 수 있습니다. 아이덴티티가 처음부터 구축되면, 배포를 지연시키는 대신 가속화합니다.

보안 및 엔지니어링 리더들이 에이전트형 AI를 채택하고 싶지만 거버넌스 및 위험에 관해 우려하는 경우, 그들이 로드맵을 계획할 때 어떤 조언을 드리겠나요?

기초를 제대로 설정하기 위해 충분히 시간을 들여야 합니다. AI 에이전트는 아이덴티티로 취급해야 하며, 인간에게 기대하는 것과 동일한 거버넌스를 적용하고 처음부터 가시성을 요구해야 합니다. 그렇게 한다면 에이전트형 AI의 확장은 맹목적이고 위험한 도약이 아니라 보안 원칙을 적용하는 과정이 됩니다.

이번 인터뷰에 감사드립니다. 더 많은 정보를 배우고 싶은 독자들은 커티티를 방문하십시오.