Curity의 CTO인 Jacob Ideskog와의 인터뷰 시리즈

제이콥 이데스코그 Curity의 ID 전문가이자 CTO인 그는 주로 API 및 웹 환경의 보안 솔루션 개발에 주력하고 있습니다. 대규모 기업 환경은 물론 소규모 스타트업을 대상으로 OAuth 및 OpenID Connect 솔루션 설계 및 구현 경험을 보유하고 있습니다.

호기심 Curity Identity Server를 기반으로 구축된 최신 ID 및 액세스 관리(IAM) 플랫폼으로, 애플리케이션, API 및 디지털 서비스에 대한 인증 및 권한 부여를 대규모로 안전하게 보호하도록 설계된 표준 기반 솔루션입니다. OAuth 2.0 및 OpenID Connect와 같은 프로토콜을 지원하여 로그인 흐름을 중앙 집중화하고, 세분화된 액세스 정책을 적용하며, 사람 사용자와 API 및 서비스를 포함한 머신 클라이언트 모두에게 안전한 토큰을 발급합니다. 이 플랫폼은 유연성과 확장성을 고려하여 설계되었으므로, 조직은 클라우드, 하이브리드 또는 온프레미스 환경에 배포하고, 기존 시스템과 통합하며, 맞춤형 보안 인프라 구축 없이도 안전하고 원활한 사용자 경험을 제공할 수 있습니다.

Curity를 ​​공동 창립하고 클라우드 시대를 거쳐 현재 AI 시대에 이르기까지, 당신은 경력의 상당 부분을 신원 및 API 보안 시스템 구축에 바쳤습니다. 이러한 여정은 AI 에이전트를 단순한 소프트웨어가 아닌 일류 디지털 신원으로 취급해야 한다는 당신의 관점에 어떤 영향을 미쳤습니까?

제가 경험했던 모든 기술 분야에서 한 가지 문제가 계속해서 제기되었습니다. 클라우드 컴퓨팅이든 인공지능이든, 소프트웨어가 사람이나 다른 시스템을 대신하여 작동할 경우, 신원 확인 문제가 발생합니다.

에이전트형 AI가 대량 도입되면서 이러한 문제는 더욱 심화됩니다. AI 에이전트는 더 이상 엄격하게 스크립트화된 행동을 하지 않으며, 기업들이 이전에는 경험하지 못했던 수준의 자율성을 가지고 운영됩니다. AI 에이전트는 의사 결정을 내리고, API를 호출하고, 시스템 전반에 걸쳐 작업을 연쇄적으로 수행하는데, 이 과정에서 종종 인간의 직접적인 감독이 필요하지 않습니다. 이러한 행동 양식은 기존 소프트웨어와는 근본적으로 다른 신원 및 접근 관리 문제를 야기합니다.

AI 에이전트를 일류 디지털 신원으로 취급하는 것이 이 문제를 제대로 해결하는 유일한 방법입니다. 조직에서 AI 에이전트를 단순히 또 다른 프로세스나 서비스 계정으로 취급하면 가시성과 제어력을 매우 빠르게 잃게 되며, 이는 보안 위기로 이어질 수 있습니다.

많은 기업들이 에이전트형 AI에 큰 관심을 보이지만, 여전히 실험 단계에 머물러 있습니다. 실제 구축 사례를 보면, 조직이 에이전트를 안전하게 확장하는 데 가장 큰 걸림돌이 되는 ID 및 거버넌스 관련 문제점은 무엇인가요?

대부분의 실험은 실제 규모에서 발생하는 상황을 고려하지 않은 격리된 샌드박스 환경에서 이루어집니다. 초기 파일럿 단계에서는 팀이 시스템을 가동하기 위해 에이전트에 광범위한 API 키, 공유 자격 증명 또는 포괄적인 클라우드 권한을 부여하는 경우가 많습니다.

이러한 접근 방식은 파일럿 단계를 넘어 에이전트가 배포되는 순간부터 무너집니다. 보안 팀은 에이전트가 어떤 데이터에 접근했는지, 어떤 작업을 수행했는지, 또는 의도된 범위를 초과했는지 여부를 (의도적이든 악의적이든) 확인할 수 없기 때문입니다. 이러한 사각지대 때문에 에이전트를 안전하게 관리하는 것이 불가능해지며, 이것이 많은 조직이 파일럿 단계를 넘어서는 데 어려움을 겪는 이유입니다.

당신은 에이전트형 AI에 엄격한 가이드라인이 필수적이라고 주장해 왔습니다. 그렇다면 실제로 AI 에이전트를 위한 "좋은" 정체성 디자인은 어떤 모습일까요? 그리고 기업들은 일반적으로 어떤 부분에서 실수를 저지르나요?

효과적인 아이덴티티 설계는 최소 권한 원칙과 명확한 의도에 기반한 권한 부여에서 시작됩니다. 각 AI 에이전트는 고유한 아이덴티티, 제한된 범위의 권한, 그리고 명확하게 정의된 신뢰 관계(어떤 시스템과 상호 작용할 수 있는지에 대한 명확한 규칙)를 가져야 합니다. 근본적으로 접근 권한은 목적에 따라 제한되고, 시간적으로 제한되며, 쉽게 취소할 수 있어야 합니다.

기업들이 흔히 저지르는 실수는 기존 서비스 계정을 재사용하거나 내부 에이전트가 기본적으로 안전하다고 가정하는 데 있습니다. 이러한 가정은 현실 세계의 위협에 전혀 부합하지 않습니다. 악의적인 공격자들은 바로 이러한 취약점을 적극적으로 노리고 있으며, 특히 신원 확인 설계가 부실할 경우 AI 에이전트로 인해 잠재적인 피해 범위가 극적으로 확대됩니다.

Curity는 OAuth 및 OpenID Connect와 같은 표준을 오랫동안 사용해 왔습니다. 복잡한 기업 환경에서 에이전트형 AI의 상호 운용성과 보안을 확보하는 데 있어 개방형 ID 표준은 얼마나 중요할까요?

개방형 표준은 절대적으로 중요합니다. 기업들은 이미 클라우드 플랫폼, SaaS 서비스 및 내부 API를 아우르는 복잡한 ID 관리 시스템을 운영하고 있습니다. 에이전트 기반 AI는 이러한 복잡성을 더욱 가중시킬 뿐입니다.

표준이 없으면 모든 에이전트는 개별적인 통합 방식으로 작동하며 영구적인 보안 예외 사항이 됩니다. OAuth 및 OpenID Connect와 같은 표준을 사용하면 에이전트를 다른 워크로드와 마찬가지로 인증, 권한 부여 및 감사할 수 있습니다. 이것이 바로 실제 엔터프라이즈 환경 전반에 걸쳐 안전한 확장을 가능하게 하는 유일한 접근 방식입니다.

서비스 계정부터 기계 ID에 이르기까지 인간이 아닌 개체가 점점 더 보편화되고 있습니다. 보안 관점에서 AI 에이전트는 기존의 인간이 아닌 개체와 근본적으로 어떤 차이점이 있을까요?

현대 AI 에이전트와 기존의 비인간 신원(NHI)의 핵심적인 차이점은 자율성입니다. 전통적인 서비스 계정은 코드가 지시하는 대로 정확하게 수행하며, 주어진 작업에 엄격하게 구속됩니다. 반면 AI 에이전트는 명령을 해석하고, 행동을 조정하며, 명시적으로 스크립트되지 않은 행동까지 취할 수 있습니다. 이러한 모든 요소는 적절한 안전장치가 없다면 잠재적인 위험을 증가시킵니다.

신원 또는 접근 권한에 대한 사소한 오류가 순식간에 재앙으로 이어질 수 있습니다. 에이전트가 여러 시스템에 걸쳐 신속하게 작업을 수행할 수 있기 때문입니다. 보안 관점에서 이는 중대한 위험 요소입니다.

특히 규제 산업에서 에이전트형 AI를 관리하는 데 있어 감사 추적 및 신원 기반 로깅은 얼마나 중요한가요?

감사 추적은 "있으면 좋은 것"이 아니라 처음부터 구축되어야 합니다. 규제 환경에서 조직은 다음과 같은 간단하지만 중요한 질문에 답해야 합니다. 이 에이전트가 무엇에 접근했는지, 언제 발생했는지, 누가 승인했는지.

ID 기반 로깅은 그러한 수준의 책임성을 확보하는 유일하게 신뢰할 수 있는 방법입니다. 또한 사고 대응에도 핵심적인 역할을 합니다. 명확한 ID 컨텍스트가 없으면 문제가 에이전트의 오작동, ID 탈취 또는 단순히 잘못된 프롬프트에서 비롯되었는지 파악하기가 거의 불가능합니다.

조직이 과도한 권한을 부여받거나 제대로 모니터링되지 않는 AI 에이전트를 실제 운영 환경에 배포할 때 어떤 실질적인 위험이 발생할 수 있다고 생각하십니까?

흔히 발생하는 위험 중 하나는 은밀한 데이터 수집입니다. 과도한 권한을 가진 에이전트는 여러 시스템(고객 기록, 내부 문서, 로그)에서 민감한 정보를 추출한 후 프롬프트, 요약 또는 외부 통합을 통해 해당 데이터를 노출할 수 있습니다.

또 다른 위험은 관리자 권한을 가진 에이전트가 기계 속도로 주요 변경 작업을 수행하여 사람이 단기간에 일으킬 수 있는 것보다 훨씬 더 큰 피해를 초래할 수 있다는 것입니다. 여기에는 클라우드 리소스 수정, 보안 제어 비활성화 또는 감독 없이 자동화된 워크플로 실행 등이 포함될 수 있습니다.

이러한 사건들은 악의적일 수도 있지만, 반드시 그런 것은 아닙니다. 과도한 권한을 가진 에이전트나 제대로 관리되지 않는 에이전트가 오래되거나 잘못된 가정에 기반하여 작동하면서, 누군가가 알아차리기 전에 여러 시스템에 걸쳐 오류를 증폭시킬 수도 있습니다.

하지만 공격자의 관점에서 볼 때, 탈취된 에이전트 ID는 매우 귀중한 자산입니다. 이를 통해 API와 서비스를 넘나들며 자유롭게 이동할 수 있으며, 일반적인 사용자에게는 절대 부여되지 않는 수준의 접근 권한을 얻을 수 있습니다. 강력한 ID 관리 및 모니터링 시스템이 없다면, 조직은 이미 상당한 피해가 발생한 후에야 이러한 보안 취약점을 발견하는 경우가 많습니다.

파일럿 단계를 거쳐 실제 에이전트 기반 배포로 전환하는 기업의 경우, 나중에 비용이 많이 드는 재설계를 피하기 위해 초기에 어떤 ID 및 액세스 관련 결정을 내려야 할까요?

조직은 에이전트에게 ID를 발급하는 방법, 권한을 승인하는 방법, 그리고 시간이 지남에 따라 액세스 권한을 검토하는 방법을 조기에 결정하고 ID 경계를 사전에 정의해야 합니다.

사후에 신원 제어를 도입하는 것은 거의 항상 문제가 됩니다. 에이전트는 공유 자격 증명이나 광범위한 역할을 사용하여 워크플로에 깊숙이 통합되는 경우가 많으므로, 사후에 접근 권한을 강화하면 시스템이 의존하는 기본 가정이 무너지게 됩니다. 이는 결국 워크플로 실패를 초래하고 기술에 대한 신뢰를 약화시킵니다. 처음부터 적절한 신원, 범위 및 접근 경계를 설계하는 것이 훨씬 저렴하고 안전합니다.

에이전트형 AI를 도입할 때 신원 통합이 가장 흔히 병목 현상을 일으키는 부분은 어디이며, 이러한 마찰을 줄이는 데 도움이 되는 모범 사례는 무엇일까요?

ID 관리는 병목 현상을 초래할 수 있지만, 이는 ID 관리를 나중에 고려할 사항으로 여길 때만 발생합니다. 팀은 먼저 뛰어난 에이전트 기능을 구축하는 데 집중하지만, 나중에 진정한 보안을 위해서는 IAM 시스템, API 게이트웨이 및 로깅 플랫폼과 통합해야 한다는 사실을 깨닫게 됩니다.

최선의 접근 방식은 ID 플랫폼을 명확하게 이해하고 제대로 구현한 다음, 그 플랫폼에 맞춰 에이전트를 설계하는 것입니다. 조직은 기존 표준과 인프라를 재사용해야 하며, 이를 우회해서는 안 됩니다. 이러한 편법을 사용하면 필연적으로 향후 문제가 발생합니다. ID를 처음부터 구축하면 배포 속도가 빨라집니다.

에이전트형 AI를 도입하고 싶지만 거버넌스와 위험 관리에 대해 우려하는 보안 및 엔지니어링 리더들에게 로드맵을 계획할 때 어떤 조언을 해주시겠습니까?

기초를 제대로 다질 수 있도록 속도를 늦추세요. AI 에이전트는 하나의 개체로 취급되어야 하므로 인간에게 적용하는 것과 동일한 거버넌스를 적용하고 처음부터 투명성을 확보해야 합니다. 조직이 이러한 원칙을 따른다면 에이전트 기반 AI의 확장은 맹목적이고 위험한 모험이 아니라 보안을 확보하는 작업이 될 것입니다.

훌륭한 인터뷰 감사합니다. 자세한 내용을 알고 싶은 독자는 방문하세요. 호기심.