AI 앱이 Google Workspace 신뢰를 현대적 공격 경로로 바꾸다

Google Workspace 보안은 수년간 더 강력한 비밀번호, 다중 인증, 개선된 피싱 방어 체계를 도입했음에도 갈등 지점에 도달했다. 보안팀을 위한 최신 Google 뉴스는 공격자가 직접 훔칠 필요가 없는 접근 권한에 관한 것이다. 공격자는 승인된 AI 애플리케이션, 탈취된 브라우저 세션 또는 방치된 OAuth 토큰을 통해 이를 승계할 수 있다.

이 차이는 방어 과제를 바꾼다. 보안 프로그램은 전통적으로 로그인 화면에서 공격자를 막는 데 집중한다. 그러나 현대의 공격은 갈수록 Google이 이미 승인된 것으로 간주하는 접근 권한에서 시작된다.

AI 도구는 유용한 답변을 제공하고 작업을 수행하려면 광범위한 연결이 필요하므로 이러한 긴장을 심화한다. 한 어시스턴트는 Gmail을 읽고, Drive를 검색하며, Calendar를 확인하고, 그 결과를 다른 서비스로 전송할 수 있다. 각 연결은 비밀번호 변경 이후에도 유지되고, 뚜렷한 사용자 상호작용 없이도 활성 상태로 남을 수 있는 신뢰 관계를 만든다.

당면한 교훈은 모든 AI 도구가 악성이라는 것이 아니다. 승인 자체가 기업 경계의 일부가 되었다는 점이다. BleepingComputer를 통해 확산된 최근 Material Security 분석은 많은 조직이 여전히 이를 관리상 배경 소음처럼 취급한다고 지적한다.

2026년 4월 Vercel 사고는 왜 이러한 접근으로 더는 충분하지 않은지를 보여준다. 침해와 관련한 공개 내용에 따르면 공격자들은 먼저 서드파티 AI 제공업체를 침해했다. 이후 해당 업체의 승인된 연결을 이용해 Vercel 직원의 Google Workspace 계정에 접근했다.

이 공격은 누군가 Vercel의 로그인 방어 체계를 뚫었다는 익숙한 서사와는 달랐다. 신뢰는 사용자가 이전에 승인한 통합을 통해 조직 경계를 넘었다.

Google 뉴스의 초점, 탈취된 비밀번호에서 승계된 접근 권한으로 이동

중요한 변화는 새로운 Google 취약점이 아니라, 합법적 접근 권한을 더 효과적으로 악용하는 방식이다.

OAuth는 한 애플리케이션이 다른 서비스의 선택된 리소스에 접근하도록 하는 권한 부여 프레임워크다. 예를 들어 일정 관리 도구는 사용자의 Google 비밀번호를 받지 않고도 캘린더를 읽을 수 있다.

이러한 분리는 실질적인 보안 이점을 제공한다. 사용자는 연결되는 모든 서비스와 자격 증명을 공유할 필요가 없다. 관리자는 애플리케이션을 제한하고, 요청된 범위를 검토하며, 부여된 권한을 취소할 수도 있다.

동일한 모델은 가치 높은 공격 표적도 만든다. OAuth 토큰은 이미 승인 절차를 통과한 권한을 나타낸다. 해당 토큰을 탈취하거나 통제하는 사람은 부여된 범위 내에서 승인된 애플리케이션을 통해 행동할 수 있다.

Material Security의 OAuth 위험 보고서는 운영 중인 Google Workspace 환경을 조사해 크고 분산된 권한 부여 표면을 발견했다. 공개된 조사 결과에 따르면 기업당 OAuth 애플리케이션 연결의 중앙값은 1,807개다.

보고서는 또한 관찰된 권한 부여의 47.2%가 90일 이상 사용되지 않았다고 밝혔다. 이러한 휴면 권한 부여 가운데 1,526개는 여전히 전체 Gmail 접근 권한을 유지하고 있었다.

이 수치는 모든 Workspace 테넌트를 대표하는 전수조사가 아니라 보안 업체의 고객 데이터셋에서 나온 것이다. 기업 규모, 산업, 기존 보안 성숙도는 모두 총계에 영향을 미칠 수 있다. 그럼에도 이 결과는 구조적 문제를 드러낸다. 과거의 권한 부여는 업무상 목적이 사라진 후에도 자주 유효한 상태로 남는다.

AI 도입은 이러한 축적을 가속한다. Material은 AI 및 자동화 범주에서 공개 애플리케이션 356개를 분류했다. 분석 대상 환경에서 이 중 325개가 2024년 1월 1일 이후 처음 나타났다고 밝혔다.

이는 관찰된 AI 애플리케이션 집단의 91%가 16개월 내에 유입됐다는 의미다. 이들 애플리케이션의 절반 이상은 민감하거나 제한된 범위를 보유한 것으로 알려졌다.

범위는 애플리케이션이 무엇에 접근하거나 변경할 수 있는지를 정의한다. 광범위한 범위는 앱이 이메일을 읽고, Drive 콘텐츠를 확인하며, 메시지를 보내거나 정보를 삭제하도록 허용할 수 있다.

따라서 조직은 어려운 분류 문제에 직면한다. Drive 접근 요청은 유용한 리서치 어시스턴트를 지원할 수 있다. 그러나 애플리케이션이 침해될 경우 동일한 권한이 계약서, 전략 문서, 자격 증명, 고객 기록을 노출할 수 있다.

위협은 처음부터 악성 애플리케이션일 필요가 없다. 합법적인 제공업체도 직원 기기, 개발자 계정, 서명 키 또는 클라우드 환경이 침해된 후 진입점이 될 수 있다.

이 가능성은 일상적인 앱 승인을 공급망 의사결정으로 바꾼다. 사용자는 동의 화면을 보지만, 조직은 제공업체의 향후 보안 실패를 함께 떠안는다.

하나의 침해된 AI 도구가 두 개의 보안 경계를 넘을 수 있다

Vercel 사고는 공격자가 최종 표적을 직접 공격하는 대신 AI 공급업체를 거쳐 이동할 수 있음을 보여준다.

Vercel은 2026년 4월 침해된 서드파티 AI 도구와 직원의 Google Workspace 계정이 연루된 보안 사고를 공개했다. 공개 보도는 해당 제공업체를 Context.ai로 지목했다.

공개된 내용에 따르면 Vercel 직원은 회사 신원을 사용해 Context.ai의 AI Office Suite를 연결했다. 이 연결에는 광범위한 Google Workspace 권한이 부여됐다.

이후 위협 행위자는 Context.ai가 보유한 관련 접근 권한을 통제하게 됐다. 이 접근 권한은 직원의 Workspace 계정으로 들어가고, 이후 Vercel의 내부 시스템으로 향하는 경로를 제공한 것으로 알려졌다.

이 과정은 연결된 두 개의 공급망 노출을 만들었다. Context.ai는 자체 직원 신원과 인프라에 의존했다. Vercel은 다시 Context.ai의 OAuth 애플리케이션 무결성에 의존했다.

독립 연구자들은 Context.ai의 초기 침해 원인을 인포스틸러 감염으로 추정했다. 인포스틸러는 비밀번호, 브라우저 쿠키, 토큰 및 기타 인증 정보를 수집하도록 설계된 악성코드다.

보도는 이 감염을 Roblox 익스플로잇으로 제시된 소프트웨어와 연관 지었다. 다만 초기 침해의 모든 세부 사항이 Vercel로부터 독립적인 확인을 받은 것은 아니다.

Vercel이 확인한 내용은 기업 계획 측면에서 더 중요하다. 서드파티 애플리케이션의 기존 권한 부여가 공격자가 직원의 기업 Workspace 계정에 도달하는 데 도움을 줬다.

공격자는 민감 정보로 지정되지 않은 환경 변수를 열람한 것으로 알려졌다. Vercel은 영향을 받은 고객에게 활동을 감사하고 노출된 자격 증명을 교체하라고 권고했다.

당시 보도는 공격자가 탈취한 데이터의 대가를 요구했다고 전했다. Vercel은 Mandiant를 투입하고, 법 집행기관에 통보했으며, 제한된 범위의 영향을 받은 고객에게 연락했다.

Vercel은 민감한 환경 변수는 저장 시 암호화돼 있었고 접근되지 않았다고도 밝혔다. Next.js와 Turbopack을 포함한 오픈소스 프로젝트 역시 영향을 받지 않은 것으로 알려졌다.

이 사고를 OAuth 자체가 실패했다는 주장으로 단순화해서는 안 된다. OAuth는 사용자와 관리자가 허용한 권한 부여를 수행했다.

실패는 전체 신뢰 사슬에서 발생했다. 제공업체가 침해됐고, 애플리케이션은 광범위한 접근 권한을 보유했으며, 그 접근 권한은 가치 있는 기업 신원으로 이어졌다.

기존 로그인 방어는 이 과정의 한 부분만 보호했다. 사용 가능한 권한 부여가 존재한 뒤에는 공격자가 원래의 동의 결정을 다시 거칠 필요가 없었다.

비밀번호를 변경해도 일부 애플리케이션 권한 부여는 그대로 남을 수 있다. 이는 대응이 자격 증명을 재설정하고 활성 브라우저 세션을 종료하는 것보다 더 복잡하다는 뜻이다.

팀은 어떤 토큰이 존재하는지, 어떤 범위를 보유하는지, 어떤 연결 애플리케이션이 여전히 행동할 수 있는지를 파악해야 한다. 이후 필수 업무 흐름을 중단하지 않으면서 접근 권한을 취소해야 한다.

이것이 현대적 공격 사슬의 핵심적인 역전이다. 비밀번호 공유를 줄이기 위해 설계된 애플리케이션이 비밀번호 중심 방어를 우회하는 지속적인 경로가 될 수 있다.

AI 에이전트는 익숙한 OAuth 기록의 정보 가치를 낮춘다

AI 에이전트는 권한 부여 로그에서 평범하게 보일 수 있지만, 기존 통합보다 훨씬 예측하기 어렵게 행동할 수 있다.

전통적인 애플리케이션은 보통 제한된 기능 집합을 수행한다. 문서 서명 서비스는 파일을 가져와 서명을 수집하고, 완료된 사본을 반환할 수 있다.

행동이 바뀔 수는 있지만, 관리자는 요청된 권한을 비교적 안정적인 목적과 대조할 수 있다. 이러한 유형의 서비스에 과도한 Gmail 또는 Calendar 접근 권한이 요청되면 의심스럽게 보여야 한다.

AI 에이전트는 동일한 행동 모델을 따르지 않는다. 다음 행동은 사용자 프롬프트, 검색된 콘텐츠, 사용 가능한 도구, 모델 출력, 외부 시스템이 전달한 지침에 따라 달라질 수 있다.

권한 부여 계층에서는 이런 차이가 사라질 수 있다. AI 어시스턴트에 부여된 읽기 전용 Drive 권한은 고정된 문서 유틸리티에 부여된 권한과 비슷하게 보일 수 있다.

Material의 에이전트 분석은 보안 신호가 권한 부여에서 권한 부여 이후의 행동으로 이동하고 있다고 주장한다. 제공업체 신원과 범위는 여전히 유용하지만, 범용 에이전트가 무엇을 할지 완전히 설명할 수는 없다.

일반적으로 MCP라고 불리는 Model Context Protocol은 이러한 불확실성을 키울 수 있다. MCP는 AI 시스템을 도구 및 외부 데이터 소스와 연결하기 위한 표준이다.

MCP에 연결된 에이전트는 Workspace를 검색하고, 선택한 콘텐츠를 다른 도구로 전달하며, 이를 요약하고, 후속 작업을 실행할 수 있다. 하나의 사용자 요청 안에서 워크플로가 여러 서비스를 가로지를 수 있다.

이는 동의 화면으로 답할 수 없는 여러 보안 질문을 만든다. 관리자는 에이전트가 실제로 어떤 정보에 접근했는지, 그 정보를 어디로 보냈는지, 활동이 사용자의 의도와 일치했는지를 알아야 한다.

프롬프트 인젝션은 또 다른 계층을 더한다. 프롬프트 인젝션은 신뢰할 수 없는 콘텐츠가 AI 시스템의 지침이나 도구 사용을 조작하는 상황을 뜻한다.

에이전트는 이메일, 공유 문서, 캘린더 항목 또는 웹페이지 안에서 적대적인 지시를 마주할 수 있다. 그 콘텐츠를 지침으로 취급한다면, 합법적인 권한이 유해한 활동을 위한 메커니즘이 될 수 있다.

이 위험은 고전적인 악성코드와 다르다. 실행 파일이 반드시 사용자의 기기에 내려받아지는 것은 아니며, AI 제공업체가 침해되지 않은 상태일 수도 있다.

대신 시스템은 적대적 콘텐츠를 처리하는 동안 유효한 도구를 오용할 수 있다. 보안 통제는 승인된 자동화와 위험하게 행동하는 승인된 자동화를 구분해야 한다.

이는 연결된 모든 에이전트에 프롬프트나 사적 콘텐츠를 제한 없이 감시해야 한다는 뜻은 아니다. 과도한 감시는 그 자체로 프라이버시, 규정 준수, 거버넌스 위험을 만든다.

이는 조직에 활동 수준의 증거가 필요하다는 뜻이다. 유용한 신호에는 비정상적인 다운로드 규모, 새로운 전달 행동, 빠른 사서함 열거, 예상치 못한 서비스 조합, 사용자의 일반적인 패턴 밖에서 발생한 접근 등이 포함된다.

AI는 검토가 필요한 연결 수 또한 늘린다. 직원들은 조달 또는 보안팀이 이를 평가하기도 전에 어시스턴트를 직접 도입할 수 있다.

잘 알려진 브랜드명이라고 해서 동의 화면의 애플리케이션이 해당 브랜드에 속한다는 보장은 없다. Material의 보고서는 합법적인 Gamma 프레젠테이션 서비스와 유사한 “gamma.com.ai”라는 애플리케이션을 설명한다.

Material에 따르면 해당 게시자는 Gamma와 무관했으며 여러 고객 환경에서 접근 권한을 요청했다. 보고서는 이 사례를 시각적 친숙함이 승인을 부추기는 OAuth 사칭으로 제시한다.

권한 부여 화면에는 여전히 도메인과 요청 권한이 표시됐다. 익숙한 이름이 검토를 약화시켰기 때문에 인간의 판단이 실패했다.

이 공격 경로에는 위조된 비밀번호 페이지가 필요하지 않습니다. 사용자가 잘못된 주체에 정당한 권한을 부여하도록 설득하는 방식입니다.

MFA는 로그인은 보호하지만, 그 이후의 모든 결정을 보호하지는 않는다

다단계 인증은 여전히 필수적이지만, 성공적인 로그인 이후 이어지는 모든 토큰, 애플리케이션, 브라우저 동작을 검증할 수는 없습니다.

MFA는 탈취한 비밀번호만으로는 충분하지 않기 때문에 많은 비밀번호 기반 공격을 차단합니다. 패스키와 하드웨어 보안 키를 포함한 피싱 방지 방식은 실시간 자격 증명 중계에 대해 더 강력한 보호를 제공합니다.

Google은 Workspace 전반에서 패스키 지원과 관리 제어 기능을 확대했습니다. 이러한 조치는 일반적인 계정 탈취에 대한 노출을 줄입니다.

그러나 OAuth 동의는 흔히 인증 이후에 이뤄집니다. 사용자는 올바르게 로그인하고 MFA를 완료한 뒤 애플리케이션을 승인합니다.

그 결과 생성된 토큰은 승인된 결정을 기록합니다. 해당 토큰을 재사용할 때 동일한 인증 요구가 다시 발생하지 않을 수 있습니다.

브라우저 세션 탈취도 유사한 공백을 만듭니다. 세션 쿠키는 서비스가 이전에 인증된 브라우저를 인식할 수 있게 하는 데이터입니다.

유효한 쿠키를 탈취한 공격자는 그 인증 상태를 이어받을 수 있습니다. Google은 의심스러운 세션을 조사하고 강제 로그아웃을 수행하기 위한 세션 쿠키 대응 절차를 문서화하고 있습니다.

애플리케이션 토큰과 브라우저 세션은 동일하지 않습니다. 하지만 둘 다 로그인 이벤트가 보안 경계 전체를 정의할 수 없는 이유를 보여줍니다.

공격자는 AiTM으로 알려진 적대자-중간자 피싱도 사용합니다. 이는 실시간 위조 세션을 통해 자격 증명과 2차 인증 요소를 중계하는 방식입니다. 이 기법은 MFA가 성공한 뒤 생성된 인증 세션을 탈취할 수 있습니다.

피싱 방지 인증은 자격 증명이 정상 사이트와 암호학적으로 연결되어 있기 때문에 공격 난도를 높입니다. 그럼에도 조직은 멀웨어, 침해된 애플리케이션, 탈취된 토큰이 다른 경로를 만들 수 있다고 가정해야 합니다.

Microsoft는 신뢰할 수 있는 ID 공급자 URL과 관련된 OAuth 리디렉션 악용 사례를 문서화했습니다. 해당 캠페인은 프로토콜 매개변수 또는 연결된 애플리케이션을 조작해 피해자를 공격자 제어 목적지로 유도합니다.

더 넓은 패턴은 Google에만 국한되지 않습니다. Microsoft 365, Salesforce, 클라우드 개발 플랫폼, 데이터 서비스는 모두 토큰과 타사 통합에 의존합니다.

여러 대규모 캠페인이 이러한 관계를 표적으로 삼았습니다. Salesloft Drift 관련 사고는 탈취된 통합 토큰이 고객 환경에 대한 하류 접근 권한을 제공할 수 있음을 보여줬습니다.

이 비교는 Google만의 문제라는 설명을 배제한다는 점에서 중요합니다. 엔터프라이즈 소프트웨어는 점점 위임된 신뢰의 그래프로 작동하고 있습니다.

방어자는 MFA를 유지하면서 보안 모델을 확장해야 합니다. 인증은 신원이 로그인 요구 사항을 충족했는지에 답합니다. 권한 부여는 그 신원 또는 연결된 애플리케이션이 이후 무엇을 할 수 있는지에 답합니다.

보안팀은 지속성도 고려해야 합니다. 하나의 브라우저 세션을 폐기한다고 해서 애플리케이션 권한 부여까지 반드시 폐기되는 것은 아닙니다. 사용자를 정지하더라도 별도 조사가 필요한 연결된 접근 권한이 남을 수 있습니다.

사고 대응 계획에는 이러한 조치를 명시적으로 나열해야 합니다. 그렇지 않으면 팀은 비밀번호를 재설정하고 세션을 종료한 뒤 접근이 끝났다고 잘못 판단할 수 있습니다.

이 확장된 대응은 운영상 부담이 큽니다. 대규모 조직에는 수천 개의 권한 부여, 서비스 계정, 위임 권한, 자동화 워크플로가 있을 수 있습니다.

모든 권한을 철회하는 것은 신뢰할 수 있는 장기 정책이 아닙니다. 생산성을 저해하고 직원들이 눈에 덜 띄는 대안을 찾도록 부추길 수 있습니다.

방어 가능한 목표는 선택적 신뢰입니다. 팀은 애플리케이션을 식별하고, 게시자를 검증하며, 범위를 제한하고, 동작을 모니터링하고, 목적이 만료되면 접근 권한을 제거해야 합니다.

핵심 절충점은 유용한 AI와 측정되지 않은 신뢰 사이에 있다

모든 통합을 차단하면 엔터프라이즈 AI를 유용하게 만드는 연결된 워크플로를 파괴함으로써 하나의 위험을 줄이게 됩니다.

AI 어시스턴트가 일반적인 응답을 넘어가려면 맥락이 필요합니다. 고객 업데이트를 작성하는 어시스턴트는 이메일, 회의 메모, 계정 이력, 프로젝트 문서가 필요할 수 있습니다.

이를 빈 채팅 창으로 제한하면 노출은 줄어듭니다. 그러나 직원들이 엔터프라이즈 AI에서 기대하는 가치의 상당 부분도 사라집니다.

따라서 조직이 마주한 것은 이분법적 보안 결정이 아니라 절충점입니다. 권한 부여가 무기한 누적되지 않도록 하면서 유용한 접근은 허용해야 합니다.

첫 단계는 가시성입니다. 관리자는 애플리케이션, 권한 부여, 사용자, 범위, 게시자, 최근 활동에 대한 도메인 전체 인벤토리가 필요합니다.

인벤토리는 공개 타사 애플리케이션과 내부 도구를 구분해야 합니다. 또한 퇴사자, 계약직, 테스트 계정, 비활성 프로젝트와 연결된 권한 부여도 식별해야 합니다.

이름만 검토해서는 충분하지 않습니다. 팀은 게시자 신원, 애플리케이션 도메인, 리디렉션 위치, 요청된 범위, 그리고 해당 도구가 관련 플랫폼 검증을 완료했는지를 확인해야 합니다.

검증이 영구적인 보증은 아닙니다. 합법적인 제공업체도 승인 후 침해를 입거나, 인수되거나, 변경될 수 있습니다.

범위 제어는 또 다른 계층을 제공합니다. 애플리케이션에는 정의된 워크플로에 필요한 최소 권한만 부여해야 합니다.

명확한 요구 사항 없이 전사 서비스에 전체 Gmail 접근 권한을 부여해서는 안 됩니다. 선택된 Drive 폴더만 검색하는 어시스턴트가 모든 파일에 자동으로 접근해서도 안 됩니다.

시간도 중요합니다. 평가를 위해 부여된 접근 권한은 평가가 끝나면 만료되어야 합니다. 조직은 일시적인 실험이 영구 자격 증명으로 바뀌지 않도록 해야 합니다.

Google 관리자는 타사 애플리케이션 접근을 제한하고 서비스를 신뢰됨, 제한됨 또는 차단됨으로 분류할 수 있습니다. 이러한 제어 기능은 직원의 업무 속도에 맞춰 작동할 수 있는 승인 절차가 뒷받침될 때 가장 효과적입니다.

몇 주가 걸리는 검토 시스템은 도입을 지하화할 것입니다. 권한을 검토하지 않고 익숙한 이름만 승인하는 시스템은 권한 난립을 초래할 것입니다.

행동 모니터링은 승인만으로 예측할 수 없는 부분을 다룹니다. 팀은 애플리케이션이 갑자기 훨씬 많은 데이터를 읽거나, 비정상적인 사용자에게 접근하거나, 새로운 작업을 수행하기 시작하는 경우를 탐지해야 합니다.

이는 특히 AI 에이전트에서 중요합니다. 범용 기능 때문에 정적인 설명은 예상 동작을 보여주는 지표로서의 힘이 약합니다.

Cloud Security Alliance의 연구는 AI SaaS OAuth 체인을 체계적인 엔터프라이즈 공격 표면으로 규정합니다. 이 신뢰 체인 분석은 Context.ai 사고를 다른 하류 토큰 침해와 연결합니다.

이 보고서는 기업이 OAuth 수명주기 관리를 핵심 보안 기능으로 다뤄야 한다고 주장합니다. 여기에는 발급, 인벤토리 관리, 모니터링, 교체, 철회, 사고 대응이 포함됩니다.

보안팀은 공급업체 통계도 신중하게 다뤄야 합니다. Material은 Workspace 보안 제품을 판매하며, 해당 연구는 자사 플랫폼이 해결하는 문제를 뒷받침합니다.

그럼에도 이 데이터셋은 모든 조직이 검증할 수 있는 질문을 제공합니다. 관리자는 자체 권한 부여 수, 휴면 비중, 민감한 범위, AI 애플리케이션 증가율, 철회 공백을 측정할 수 있습니다.

가장 강력한 대응은 회사 자체 테넌트에서 수집한 증거입니다. 로컬 감사는 보고된 패턴이 실제로 적용되는지와 고위험 연결이 어디에 있는지를 확인할 수 있습니다.

보안팀이 다음으로 주시해야 할 사항

세 가지 신호는 Workspace 방어 체계가 AI 시대의 권한 부여에 적응하고 있는지, 아니면 또 하나의 대시보드만 추가하는지를 보여줄 것입니다.

첫 번째 신호는 Google과 보안 공급업체가 제공하는 권한 부여 이후 가시성의 개선입니다. 관리자는 애플리케이션이 특정 범위를 받았다는 기록만으로는 충분하지 않습니다.

애플리케이션의 이후 활동에 관한 실용적인 답이 필요합니다. 여기에는 어떤 리소스에 접근했는지, 패턴이 어떻게 바뀌었는지, 데이터가 연결된 서비스 간에 이동했는지가 포함됩니다.

Google은 이미 조사 및 접근 제어 기능을 제공하지만, 적용 범위는 에디션, 구성, 사용 가능한 텔레메트리에 따라 달라집니다. 핵심 검증 기준은 팀이 서로 관련 없는 여러 콘솔에서 증거를 모으지 않고도 AI 에이전트의 행동을 추적할 수 있는지입니다.

활동 수준 조사가 더 명확해진다면 여기서 설명한 보안 모델은 실질적인 뒷받침을 얻게 됩니다. 로그가 초기 동의에 계속 집중된다면 방어자는 동적인 에이전트를 정적인 메타데이터로 계속 판단하게 될 것입니다.

두 번째 신호는 AI 제공업체가 권한을 얼마나 세분화하고 관리하는지입니다. 성숙한 제품은 각 범위가 왜 필요한지 설명하고, 더 작은 권한 부여 범위로도 유용한 워크플로를 제공해야 합니다.

선택적 데이터 소스, 가능한 경우 단기 접근, 신속한 철회, 도구 활동에 대한 투명한 기록을 지원해야 합니다. 또한 사용자 대상 자동화와 고위험 관리 작업을 분리해야 합니다.

광범위한 기본 범위는 시장이 최근 사고에서 교훈을 얻고 있다는 주장을 약화시킬 것입니다. 더 세분화된 제어는 공급업체가 권한 부여를 제품 설계 문제로 인식하고 있음을 보여줄 것입니다.

세 번째 신호는 조직이 일상적인 보안 업무에서 OAuth 노출을 측정하는지입니다. 연간 한 번의 검토로는 직원들이 AI 도구를 도입하는 속도를 따라갈 수 없습니다.

팀은 휴면 권한 부여, 신규 게시자, 민감한 범위, 퇴사 처리된 사용자, 애플리케이션 동작의 급격한 변화를 추적해야 합니다. 이러한 지표는 반복적인 ID 및 클라우드 보안 검토에 포함되어야 합니다.

사고 훈련은 타사 토큰 침해도 검증해야 합니다. 대응 담당자는 영향을 받은 사용자를 식별하고, 권한 부여를 철회하고, 세션을 종료하고, 하류 비밀 정보를 교체하며, 증거를 보존하는 방법을 알아야 합니다.

최근 google news는 Workspace가 본질적으로 안전하지 않게 되었다는 점을 입증하지는 않습니다. 이는 로그인 보호를 중심으로 구축된 보안 가정이 더 이상 엔터프라이즈 데이터로 가는 전체 경로를 포괄하지 못한다는 점을 보여줍니다.

비밀번호와 MFA는 여전히 필요합니다. 직원이 이메일, 파일, 캘린더, 연결된 시스템 전반에서 작동하도록 애플리케이션에 권한을 부여한 뒤에는 더 이상 최종 통제 수단일 뿐입니다.

더 어려운 질문은 유용한 업무를 막지 않으면서 조직이 그 위임된 활동을 파악하고 관리할 수 있는지입니다. 보안 리더는 직접적인 측정에서 시작해야 합니다. 지금 이 순간 회사 데이터에 접근할 수 있는 연결된 애플리케이션은 몇 개이며, 각 결정의 소유자는 여전히 누구입니까?