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

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

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

당신은 아이덴티티 및 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와 서비스 전체에 걸쳐 횡단 movement을 가능하게 하며, 인간 사용자가 받을 수 있는 것보다 더 높은 수준의 액세스를 제공합니다. 강력한 아이덴티티 컨트롤과 모니터링이 없으면, 조직은 실제로 손상을 입은 후에야 이러한 실패를 발견합니다.

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

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

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

에이전트형 AI를 롤아웃할 때 아이덴티티 통합이 가장 souvent 병목 현상을 일으키는 곳은 어디이며, 이러한 마찰을 줄이는最佳實踐은 무엇인가요?

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

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

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

기초를 제대로 설정하기 위해 충분히 시간을 들여야 합니다. AI 에이전트는 아이덴티티로 취급되어야 하며, 초기부터 가시성을 요구해야 합니다. 조직이 그렇게 한다면, 에이전트형 AI를 확장하는 것은 보안의 연습이 아니라,盲目적인 위험한 도약이 되지 않습니다.

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