엔터프라이즈 AI를 무너뜨릴 수 있는 권한 부여 문제
Source: VentureBeat
AI 에이전트 정체성 및 새로운 프레임워크 과제
AI 에이전트가 CRM에 로그인하고, 데이터베이스에서 레코드를 가져오며, 당신을 대신해 이메일을 보낼 때, 어떤 정체성을 사용하고 있을까요? 그리고 그 답을 아무도 모를 때는 어떻게 될까요?
Alex Stamos(Corridor 최고 제품 책임자)와 Nancy Wang(1Password 최고 기술 책임자)이 VB AI Impact Salon Series에 참여해 에이전시 AI의 이점과 함께 등장하는 새로운 정체성‑프레임워크 과제에 대해 파헤쳤습니다.
“높은 수준에서 보면, 이 에이전트가 어느 조직에 속해 있는가가 아니라 이 에이전트가 행동하고 있는 권한이 무엇인가가 핵심이며, 이는 곧 인증 및 접근 권한으로 이어집니다,” 라고 Wang이 말했습니다.
1Password가 에이전트 정체성 문제의 중심에 서게 된 과정
Wang은 1Password가 자체 제품 역사를 통해 이 영역에 들어서게 된 과정을 추적했습니다.
- 이 회사는 소비자용 비밀번호 관리자로 시작했습니다.
- 기업용 발자국이 자연스럽게 성장했는데, 이는 직원들이 이미 신뢰하던 도구를 직장에 도입하면서 이루어졌습니다.
“그 사람들이 인터페이스에 익숙해지고, 우리가 고객에게 보장하는 보안 및 프라이버시 표준을 정말 만족하게 되면, 그들은 이를 기업 환경에 도입하게 됩니다,” 라고 그녀는 말했습니다.
같은 역학이 이제 AI에서도 일어나고 있습니다.
“에이전트도 인간처럼 비밀이나 비밀번호를 가지고 있습니다.”
내부적으로 1Password는 고객이 관리하도록 돕는 동일한 긴장을 겪고 있습니다: 엔지니어가 빠르게 움직이면서도 보안 혼란을 만들지 않는 방법.
- 회사는 Claude Code와 Cursor 같은 도구를 엔지니어가 사용할 때 AI‑생성 코드 대비 사고 비율을 적극적으로 추적합니다.
- “우리는 품질 높은 코드를 생성하고 있는지 확인하기 위해 이 지표를 면밀히 추적합니다,” 라고 Wang이 덧붙였습니다.
개발자들이 초래하는 주요 보안 위험
Stamos는 Corridor에서 관찰된 흔한 위험 행동을 강조했습니다:
- 개발자들이 자격 증명을 프롬프트에 직접 붙여넣는다 – 이는 큰 보안 위험입니다.
“표준적인 경우는 API 키나 사용자 이름·비밀번호를 바로 프롬프트에 붙여넣는 것이죠,” 라고 그는 말했습니다. “우리는 프롬프트를 잡아내면서 이런 상황을 자주 발견합니다.”
Wang은 1Password의 접근 방식을 설명했습니다:
- 코드가 작성되는 즉시 스캔하고 평문 자격 증명이 지속되기 전에 금고에 보관합니다.
- 사용하기 어려운 보안 도구는 회피될 수 있기 때문에 마찰을 최소화합니다.
“사용하기 너무 어렵다면, 부트스트랩하거나 온보딩하는 과정 자체가 보안에 취약해집니다. 솔직히 사람들은 그냥 우회하고 사용하지 않을 겁니다,” 라고 그녀는 말했습니다.
코딩 에이전트를 기존 보안 스캐너처럼 다룰 수 없는 이유
- 거짓 양성은 친절하고 순응적인 LLM에서 큰 문제입니다.
- 거짓 양성 하나가 전체 코딩 세션을 방해할 수 있습니다.
“‘이게 결함이다’라고 알려주면, 에이전트는 ‘네, 맞습니다. 완전한 결함입니다!’라고 반응합니다,” 라고 Stamos가 말했습니다. “하지만 거짓 양성을 내면 안 됩니다. 왜냐하면 잘못 알려주면 에이전트가 올바른 코드를 작성하는 능력을 완전히 망가뜨리기 때문입니다.”
정밀도와 재현율 사이의 트레이드‑오프는 전통적인 정적 분석 도구와 구조적으로 다르며, 수백 밀리초 수준의 지연을 달성하기 위한 엔지니어링이 필요합니다.
인증은 쉽지만, 권한 부여가 어려운 이유
“에이전트는 환경 내 다른 어떤 소프트웨어보다 훨씬 많은 접근 권한을 가집니다,” 라고 Spiros Xanthos(Resolve AI 창립자 겸 CEO)가 이전 세션에서 언급했습니다.
- 이는 보안 팀이 매우 우려하는 부분을 설명합니다: 손상된 에이전트는 데이터 유출을 일으키고 공격자를 대신해 행동할 수 있습니다.
범위 지정, 감사 가능, 시간 제한된 정체성
- Wang은 SPIFFE와 SPIRE(컨테이너화된 환경을 위한 워크로드 정체성 표준)를 에이전시 컨텍스트에서 시험 중인 후보로 꼽았지만, 적합성이 완벽하지 않다고 인정했습니다:
“우리는 마치 정사각형 못을 원형 구멍에 억지로 끼우는 느낌입니다.”
- A
인증은 이야기의 절반에 불과합니다. 에이전트가 자격 증명을 갖게 되면, 실제로 무엇을 할 수 있나요?
- 역할이 아닌 작업에 최소 권한 원칙을 적용합니다.
- 사람에게 전체 건물에 대한 키 카드를 주지 마세요; 마찬가지로, 에이전트에게 영구적인 API 키를 주지 마세요.
- 접근은 시간 제한이 있고 특정 작업에 한정되어야 합니다.
기업 환경에서는 범위가 지정된 접근 권한을 부여하는 것만으로는 충분하지 않으며, 조직은 다음을 알아야 합니다:
- 어떤 에이전트가 행동했는가
- 어떤 권한 하에였는가
- 어떤 자격 증명이 사용되었는가
Stamos는 표준 논의에서 현재 선두주자인 OIDC 확장을 지목하면서, 수많은 독점 솔루션을 일축했습니다:
“그들의 독점 특허 솔루션이 승자가 될 것이라고 믿는 스타트업이 50개나 있습니다. 그 중 어느 것도 승리하지 않을 것이니, 저는 추천하지 않습니다.”
수십억 사용자를 대상으로 하면 엣지 케이스는 더 이상 엣지 케이스가 아니다
소비자 측면에서 Stamos는 신원 문제는 소수의 신뢰할 수 있는 제공자를 중심으로 통합될 것이라고 예측합니다. 이는 이미 소비자 인증을 담당하고 있는 플랫폼일 가능성이 높습니다.
그는 Facebook에서 CISO로 일하면서 하루에 약 700,000건의 계정 탈취를 처리한 경험을 바탕으로, 규모가 커질 때 엣지 케이스가 어떻게 변하는지를 재정의했습니다:
“10억 명의 사용자를 보유한 회사의 CISO라면, 코너 케이스는 실제 인간에게 해를 끼치는 경우를 의미합니다.”
“따라서 일반 사람과 에이전트를 위한 신원은 앞으로 거대한 문제가 될 것입니다.”
궁극적으로, 에이전트 측면에서 CTO들이 직면하는 도전 과제는 에이전트 신원에 대한 불완전한 표준, 즉흥적인 도구, 그리고 기업이 프레임워크가 마련되기 전에 에이전트를 빠르게 배포하는 데서 비롯됩니다. 앞으로 나아가는 길은 인간을 위해 구축된 것을 인간이 만든 에이전트에 맞추는 것이 아니라, 에이전트가 실제로 무엇인지를 중심으로 신원 인프라를 처음부터 구축하는 것입니다.