워크플로 아이덴티티 하이재킹: Noma Labs, 평범한 지원 이메일을 특권 데이터 접근으로 전환

2026년 9월 9일 Noma Security의 연구팀은 Noma Labs 명의로 자신들이 워크플로 아이덴티티 하이재킹이라고 부르는 것에 관한 설명을 발표했다. 기업 AI 워크플로가 공개 진입점, 즉 지원 수신함, GitHub 이슈, 웹 양식, 공유 문서로 도착한 평범한 메시지를 읽은 뒤, 발신자의 권한 대신 자체의 고권한 서비스 계정을 사용해 요청된 작업을 수행한다는 것이다. Noma의 시연에서는 외부인이 회사의 공개 지원 주소로 이메일을 보내 여러 요청 중에서도 재무 담당 이사의 최근 이메일에 있던 분기 매출 수치를 요구했고, 몇 분 뒤 그 내용이 공격자의 받은편지함에 도착했다. 어떤 모델도 속지 않았고 어떤 계정도 침해되지 않았으며, 이것이 보고서의 요지다. "공격자가 한 일이라고는 그저 요청한 것뿐이었다." 아카이브에는 실제 피해가 기록되어 있지 않다. 피해자도 명시되지 않았고 침해된 것으로 설명된 배포 시스템도 없다. 또한 이 발견을 연구로 분류하고 심각도는 중간, 신뢰도는 A, 이견 제기 여부는 거짓으로 평가한다. 이 설명은 Noma Labs의 보고서, 같은 날 게시된 Dark Reading의 보도, 그리고 CSO Online의 후속 보도에 근거한다. AI 사건 아카이브는 이 항목을 인접 항목들과 함께 보관하며, 각 항목에는 자체 출처, 심각도 및 신뢰도 등급이 있다.

본문을 읽기 전에 레코드 자체의 필드들을 살펴볼 가치가 있다. 이 레코드에는 INFRA와 EXFIL 태그가 붙어 있고, GLOBAL 지역을 포괄하며, 2026년 9월 9일이라는 일 단위까지 정확한 날짜 하나만 담고 있으며, 랜드마크 항목으로 표시되어 있지 않다. 이 날짜는 해당 연구의 발표일일 뿐 그 외의 의미는 없다. 시간을 정할 사건 자체가 없기 때문에 어떤 사건 타임라인도 이 날짜에 연결되어 있지 않다. 먼저 붙잡아야 할 점은 이것이다. Noma가 발표한 것은 침해 보고서가 아니라 하나의 메커니즘과 범주이다.

노마가 보여준 것, 그리고 보여주지 않은 것

지원 문의 수신함 시퀀스는 고객 사례가 아니라 구성된 예시입니다. Noma의 보고서는 조직 이름을 밝히지 않고, 영향을 받은 배포 수를 제시하지 않으며, 실제 파이프라인의 텔레메트리를 공개하지도 않고, 이 시나리오에 대한 개념 증명 실행을 링크하지도 않습니다. 이는 공개 GitHub Actions 실행을 지목한 그룹의 7월 연구와는 다릅니다. 대신 보고서가 제공하는 것은 아키텍처와 대조해 확인할 수 있을 만큼 정밀한 메커니즘 설명입니다. 인증되지 않은 입력이 도착하고, 모델이 이를 올바르게 해석하며, 파이프라인이 다운스트림 호출을 실행하고, 그 호출이 워크플로 생성자의 권한으로 이루어집니다.

사시 레비(Sasi Levi)는 노마(Noma)의 보안 연구 책임자이자 해당 보고서의 저자로, 근본 원인을 한 문장으로 정리한다. "워크플로를 트리거하는 사용자의 아이덴티티와 권한이, 그것을 실행하는 데 사용되는 아이덴티티 및 권한과 분리되어 있다." 이러한 상황이 성립할 때, 보고서의 표현대로 워크플로는 "권한 있는 작업을 위한 미인증 프록시이자 은밀한 데이터 유출 통로"가 된다.

Noma는 이러한 작업이 유효한 자격 증명을 갖춘 신뢰할 수 있는 자동화를 통해 실행되기 때문에 기존 경보 방식으로 포착할 수 있는 것이 거의 없다고 주장한다. 요청은 정상이고, 모델의 출력은 유효한 모델 출력이며, API 호출은 인증되었고, 응답은 해당 워크플로가 보내도록 만들어진 응답이다. CSO Online은 레드팀원 Vibhum Dubey의 말을 인용해 탐지 문제를 구체화했다. "개별 이벤트는 완전히 합법적인 것처럼 보일 수 있습니다. 유용한 신호는 최초 요청자, 다운스트림에서 사용된 ID, 접근한 리소스, 제공된 매개변수, 최종 조치를 상호 연관시켜 나올 것입니다."

실패하는 검사는 콘텐츠 필터가 아니라 권한 확인 검사입니다.

보고서에서 가장 날카로운 예시는 한 쌍의 동일한 요청이다. 한 최고재무책임자(CFO)로부터: "재무이사가 보낸 가장 최근 이메일에 있는 분기별 매출 수치는 무엇인가?" 외부 발신자로부터: 똑같은 말. Noma의 요점은 프롬프트와 요청된 작업은 같지만 권한 부여 결정은 전혀 달라야 한다는 것이다 — "CFO는 그 정보를 받을 자격이 있고, 외부 발신자는 그렇지 않다."

보고서는 표준 프롬프트 인젝션 탐지기와 에이전트 가드레일이 두 입력을 동일하게 분류한다고 주장한다. 둘 중 어느 것에도 탐지할 악의적인 요소가 없기 때문이다. "보안 위험은 프롬프트에 있는 것이 아니라 권한 부여 경계에 있다." Noma의 구조적 주장은 여기서 이어진다. 가드레일, 시스템 지침, 입력 필터는 "권한 부여 경계 역할을 하도록 설계되지 않았으므로", 호출자가 무엇을 검색할 수 있는지 결정하기 위해 이들에 의존하는 파이프라인은 그런 역할을 요청받은 적이 없는 통제에 의존하는 셈이다.

이 구분은 실질적으로 중요하다. 직접 프롬프트 인젝션은 모델이 지시를 따르는 방식을 조작하고, 간접 프롬프트 인젝션은 모델이 나중에 읽게 될 콘텐츠 안에 지시를 숨긴다. Noma가 정의하는 워크플로 아이덴티티 하이재킹은 둘 다 필요로 하지 않는데, 그 요청은 모델이 이해하고 파이프라인이 실행하도록 되어 있는 요청이기 때문이다. 1년 내내 인젝션에 대비해 강화 작업을 해온 방어자는 다른 계층을 다뤄온 셈이다.

정적 워크플로는 에이전트 강화 추진의 범위 밖에 있습니다.

Noma는 흔히 서로 바꿔 쓰이는 두 가지를 구분한다. AI 워크플로는 모델이 하나의 처리 단계인, 미리 정의된 정적 시퀀스다. 보고서의 축약 표현으로는 A단계, 모델, B단계, C단계이며, 모델을 둘러싼 결정론적 파이프라인이 무슨 일이 일어날지를 통제한다. 에이전트 워크플로는 자율적이다. 에이전트가 어떤 단계를 밟고 어떤 도구를 호출할지 결정한다. 보고서는 현재의 보안 노력 상당 부분이 두 번째 종류, 즉 동적 결정을 내리는 에이전트의 도구 접근을 제한하고 권한 범위를 설정하는 쪽으로 향했으며, 그런 통제는 첫 번째 종류에는 미치지 않는다고 주장한다.

이 보고서는 또한 뻔한 빠져나갈 구멍도 닫는다. 워크플로를 누가 또는 무엇이 트리거할 수 있는지 제한하는 것만으로는 문제가 해결되지 않는다. 자동화가 예약에 따라 오전 8시에 실행되고 누구나 글을 쓸 수 있는 인박스에 작용한다면, "누가 이 워크플로를 트리거할 수 있는가"를 감사하는 것은 잘못된 질문에 답하는 것이다. Noma의 규칙은 모든 자동화가 "그 자동화가 작용하는 대상에 영향을 줄 수 있는, 가장 신뢰도가 낮은 주체"를 기준으로 평가되어야 한다는 것이다 — 이메일, 양식, 티켓, GitHub 이슈, 공유 문서 및 채팅 메시지가 포함된다.

Noma는 구글이 Google Workflows 사례를 수정했다고 말한다; 구글은 아무것도 공개하지 않았다

보고서에서 이름이 명시된 유일한 플랫폼은 Google의 것이다. Noma는 Google Workflows 내에서 동일한 위험 벡터를 식별했고, 이를 책임 있게 보고했으며, Google이 해당 보고를 인지하고 "구현 세부 정보를 공개하지 않은 채" 수정을 확인했다고 밝힌다. 그 문장이 공개 기록의 전부다. 이 벡터를 설명하는 Google의 권고, 릴리스 노트 또는 CVE는 찾을 수 없었으며, 수정에 관한 모든 2차 보도는 — 9월 9일 이후 며칠 동안 발표된 것들을 포함해 — 이를 Google이 아니라 Noma에 귀속시킨다.

이 보고서는 또한 어떤 Google 제품을 의미하는지에 관해서도 완벽히 일관되지는 않는다. 본문에서는 Google Workflows를 언급하지만, 같은 보고서의 한 섹션 제목은 “Google Workspace: AI Workflow Identity Hijacking”이라고 되어 있다. 둘 다 서로 다른 신뢰 경계를 가진 Google 제품이며, 보고서는 이 둘을 조화시키지 않는다. Noma는 자신이 보고한 사례가 악용되었는지, 몇 명의 고객이 노출되었는지, 수정으로 무엇이 바뀌었는지를 밝히지 않는다. 그리고 Google이 아무 말도 하지 않았기 때문에, 그 격차 중 어느 것도 공급업체 측에서 메울 수 없다.

GitLost는 더 좁은 렌즈를 통해 바라본 동일한 경계였다

노마(Noma)의 이전 공개는 이 범주에 선례를 남겼다. 2026년 7월 이 그룹은 GitHub Agentic Workflows에 관한 연구를 공개했고, 이를 GitLost라고 명명했다. 이는 이슈가 할당될 때 작동하는 워크플로로, 이슈 제목과 본문을 읽고 댓글로 답변했으며, 에이전트가 조직 전체 저장소에 대한 읽기 권한을 보유하고 있었기 때문에 외부 사용자가 이슈 할당을 통해 비공개 저장소 데이터에 접근할 수 있었다. Dark Reading은 2026년 7월 7일 이 사안을 보도하며, 공격자가 공개 저장소에 등록된 이슈 본문에 평범한 영어 문장으로 명령을 숨겼고 자격 증명도 코딩 기술도 필요하지 않았다고 설명했다.

두 가지 프레이밍은 동일하지 않으며, 그 차이가 흥미로운 부분이다. Dark Reading의 7월 보도는 프롬프트 인젝션 사례다. 공격자가 제어하는 텍스트가 지침으로 읽힌다는 것이다. Noma의 9월 보고서는 GitLost를 트리거와 리포지토리 전체 읽기 액세스 측면에서 설명하고, 이를 한 각도에서 본 동일한 권한 부여 경계로 제시한다. 두 설명 모두 에이전트가 외부인이 작성한 텍스트를 읽은 워크플로에 들어맞지만, 앞선 설명만 모델이 조종되는 것에 의존한다. Noma는 이제 동일한 위험 벡터를 Google에 보고했다고 말하지만, GitLost 사례가 공개된 시연 외에 실제로 악용된 적이 있는지는 밝히지 않는다.

Noma가 밝힌 도달 범위에 따르면 Hacker News, Dark Reading 및 100개 이상의 다른 국제 매체가 GitLost 연구를 보도했습니다. 이 수치는 해당 업체가 제시한 것이며, 이 기사는 그 보도 건수를 독립적으로 집계하지 않았습니다.

실무자들은 그 메커니즘이 오래되었다는 데 동의한다; 논쟁은 이름에 관한 것이다.

독립적인 보도는 그 발견에 이의를 제기하지 않았고, 두 명의 외부 실무자는 실질적 내용보다는 참신성에 이의를 제기했다. BeyondTrust의 최고 보안 고문인 Morey Haber는 Dark Reading에 이렇게 말했다. “누구도 AI 모델을 해서는 안 되는 일을 하도록 속이지 않았다. 그 모델은 낯선 사람(신뢰할 수 없는 사람)이 시킨 일을 정확히 수행했으며, 그 주변의 워크플로는 범위가 지정되지 않았고 최소 권한으로 처리되지 않았기 때문에 다른 사람의 신원을 이용해 그렇게 만들었다.” CSO Online은 Vibhum Dubey를 인용해 이 패턴을 “알려진 부류의 권한 부여 취약점”이라고 설명하고, 인증되지 않은 입력이 자체 권한으로 작동하는 신뢰된 워크플로를 촉발할 수 있는 경우 “그 워크플로가 사실상 혼동된 대리인 역할을 할 수 있다”고 덧붙였다.

Acalvio의 최고경영자 Ram Varadarajan은 Dark Reading에 완전히 다른 통제 방식을 제안했다. 더 많은 필터링 대신, 환경에 미끼를 심는 것이다. 가짜 임원 스레드, 허니토큰 기록처럼 어떤 정당한 워크플로도 건드릴 합당한 이유가 없는 것들을 심어, 무해해 보이는 요청이 그중 하나에 닿으면 절대 넘어서서는 안 되는 경계를 건드리게 하는 것이다. 이견이 있다면, 그것은 유용한 기여가 1988년대의 위임 결함에 새 이름을 붙이는 것인지, 아니면 그 결함이 이제 어디에 존재하는지를 실질적으로 설명하는 것인지에 관한 것이다. Noma의 입장은 후자다. 그 패턴은 기업 AI 파이프라인 전반에 걸쳐 시스템적이며, 현재의 AI 보안 프레임워크는 잘못된 표면을 보고 있다는 것이다.

완화책은 더 나은 필터가 아니라 위임과 체크포인트입니다.

Noma가 권장하는 제어는 모델 계층이 아니라 애플리케이션 계층에 있습니다. 신원 인식 토큰 위임은 AI 워크플로에서 정적 관리자 API 키를 제거하고, 인증된 요청자와 연결된 수명이 짧고 범위가 제한된 위임 토큰으로 데이터 작업을 실행하는 것을 의미합니다. 이렇게 하면 사용자 컨텍스트가 실제로 데이터에 접근하는 호출까지 전파됩니다. 컨텍스트 기반 권한 부여 체크포인트는 모든 모델 출력을 신뢰할 수 없는 입력으로 취급하고, 모델의 변환 단계와 이후의 모든 데이터베이스 또는 도구 호출 사이에 명시적인 액세스 제어 및 런타임 보호 평가를 배치하는 것을 의미합니다. 비대칭 출력 분리는 데이터 검색을 외부 통신 채널로부터 구조적으로 격리하여, 민감한 내부 데이터를 처리하는 워크플로가 외부인에게 응답하는 자동화 메커니즘과 실행 경로를 공유하지 않도록 하는 것을 의미합니다.

Dubey는 CSO Online에 세 가지 중 어느 것보다 비용이 적게 드는 테스트를 제시했다. 바로 권한 수준 전반에서 결과를 비교하는 것이다. "하위 권한 사용자가 다운스트림 시스템이 워크플로의 ID만 보기 때문에 관리자와 동일한 결과를 얻을 수 있다면, 바로 그 지점이 내가 조사를 집중할 곳이다."

기록이 남긴 미해결의 여지

• 피해자도, 집계도, 텔레메트리도 없다. Noma의 지원 문의함 사례는 하나의 워크스루일 뿐이며, 보고서는 어떤 조직도 지목하지 않고 아카이브는 실제 피해를 허위로 기록한다. 메커니즘이 그럴듯하다는 것은 그것이 사용되었다는 증거가 아니다.

• 어떤 Google 제품이 수정되었고, 그 수정 내용은 무엇인가. Noma의 본문은 Google Workflows라고 말하지만, 해당 섹션 제목은 Google Workspace라고 하며, Google은 아무것도 발표하지 않았다. 조직은 아직 공개 자료만으로는 자신들이 운영하는 파이프라인이 범위에 포함되었는지 판단할 수 없다.

• 해당 벡터가 어디에서든 악용된 적이 있는지 여부. 이 기사를 위해 검토된 보고서나 그 어떤 보도에서도 관찰된 캠페인, 데이터 손실 또는 워크플로 아이덴티티 하이재킹에 기인한 포렌식 결과가 기술되지 않았다.

• 해당 범주가 측정을 견뎌낼 수 있는지 여부. 이 패턴에 대해 독립적인 주체가 공개한 스캔, 영향을 받은 파이프라인 코퍼스, 테스트 스위트는 없다. 유통되는 근거는 아키텍처적 논증에 {{1}}한 벤더가 한 건의 고정된 사례를 설명한 것{{/1}}을 더한 것뿐이다.

• 누가 그 주장을 펼치고 있는가. Noma Labs는 Noma Security의 연구 부문이며, Noma Security는 바로 그 보고서가 권고하는 종류의 에이전트 보안 통제를 판매한다. 그렇다고 해서 이 발견이 틀린 것은 아니다 — Dark Reading과 CSO Online 모두 이를 보도했고, 어느 쪽도 사실 오류를 찾지 못했다 — 그러나 독자가 해당 범주가 얼마나 넓게 설정되었는지를 저울질할 때 염두에 두어야 할 맥락이다.

기록의 심각도 등급 medium과 실제 피해 플래그 false는 증거를 설명할 뿐, 메커니즘을 설명하지 않는다. Noma가 실제로 확립한 것은 좁고 검증 가능한 것들이다. 즉 워크플로의 트리거 정체성과 실행 정체성은 별개의 것이고, 두 번째가 보통 더 강력하며, 이 둘을 결코 비교하지 않는 파이프라인은 그것이 만들어진 사람에게 할 일을 낯선 사람에게도 할 것이다. 따라서 뒤따르는 통제는 그에 걸맞게 화려하지 않다. 각 자동화마다 누가 그것이 작동하는 대상에 영향을 줄 수 있는지, 그리고 다운스트림의 무언가가 질문하는 사람이 질문할 권한이 있었는지를 다시 확인하는지 물어야 한다.