TTESays

AI Workflow 도구는 어떻게 새로운 공격 허브가 되었는가

Donghwi Shin

Published: 08:30, 18 May 2026 (Updated: 14:15, 18 May 2026)

💡

Editor Pick
- Langflow 취약점 활용한 공격은 AI 시대의 ‘결제 권한’ 탈취 사건
- 서버보다 내부 AI 워크플로우와 자동화 구조를 이해할 수 있는 권한 탈취가 목표
- AI API Key는 단순 인증값이 아니라 기업의 AI 운영 구조에 접근할 수 있는 새로운 세션 토큰

AI 서버를 뚫은 것이 아닌, AI 사용권과 정보를 탈취

2026년 5월 공개된 Langflow의 CVE-2026-33017 취약점은 처음에는 비교적 익숙한 유형의 사건처럼 보였다. 인증 없이 코드 실행이 가능한 RCE(Remote Code Execution) 취약점이 발견되었고, 공격자들이 이를 실제 공격에 사용하기 시작했다는 내용이었다. 그러나 실제 공격 흐름을 들여다보면, 이번 사건은 단순한 서버 침해 사건으로 보기 어렵다.

공격자들이 가장 먼저 수행한 행동은 시스템 파괴나 데이터 암호화가 아니었다. 대신 공격자들은 Langflow 컨테이너 내부에 저장된 환경 변수(Environment Variable)를 읽어 AWS Access Key와 Secret Key를 수집했다. 이후 공격자는 sts:GetCallerIdentity API를 호출해 키의 유효성을 검증했고, 이어 AWS Bedrock 및 클라우드 리소스 접근 가능 여부를 탐색했다. 이 흐름에서 중요한 것은 공격자들의 관심이 서버 자체에 있지 않았다는 점이다. 공격자는 단순히 시스템을 장악하려고 했다기 보다는 기업이 AI를 어떻게 운영하고 있는지를 이해할 수 있는 권한을 확보하려 했다. 즉 공격자에게 중요한 것은 기업 내부 AI 워크플로우와 자동화 구조에 접근할 수 있는 실행 권한을 확보하고 다양한 키들이 어떤 모델과 연결되는지, 어떤 데이터 소스와 연동하는지, 어떤 자동화 흐름 안에서 사용되는지 파악하는 것이라 할 수 있다.

Langflow 취약점 활용한 공격 시나리오 by TheTechEdge(AI-generated)

AI API Key는 왜 단순 인증값이 아닌가

기존의 API Key는 비교적 단순한 의미를 가졌다. 특정 서비스에 접근하기 위한 인증값이었고, 주로 개발 편의성과 자동화를 위해 사용되었다. 그러나 생성형 AI 시대의 API Key는 훨씬 더 복잡한 의미를 갖는다. Langflow 같은 AI Workflow 도구는 단순한 시각화 플랫폼이 아니다. 실제 운영 환경에서 이러한 도구는 다양한 AI 서비스와 연결된다.

AWS Bedrock
OpenAI
Anthropic Claude
Hugging Face
Vector Database
S3 Storage
Internal Knowledge Base
Enterprise Data Pipeline

문제는 이 연결 구조 자체가 기업 내부의 AI 운영 방식을 그대로 반영한다는 점이다. 예를 들어 특정 API Key가 어떤 모델과 연결되어 있는지, 어떤 벡터 데이터베이스를 호출하는지, 어떤 Agent가 어떤 업무를 자동화하는지를 분석하면 기업이 AI를 어떻게 사용하고 있는지를 상당 부분 유추할 수 있다. 문제는 이러한 연결 구조 자체가 기업 내부 AI 운영 방식의 흔적을 그대로 담고 있다는 점이다. 어떤 모델을 선택했는지, 어떤 데이터베이스와 연결했는지, 어떤 업무 흐름을 자동화했는지가 Workflow 안에 함께 축적되어 있다.결국 이는 단순한 인증 정보 유출과는 다른 문제다. 공격자는 API Key를 통해 단순히 모델 호출 비용을 발생시키는 것 뿐만 아니라, 기업의 AI 자동화 구조와 내부 지식 흐름 자체를 관찰할 수 있는 것이다.

공격자는 왜 Bedrock 접근 여부를 확인했는가

이번 사건에서 특히 중요한 부분은 공격자들이 AWS Bedrock 접근 가능 여부를 확인했다는 점이다. 표면적으로 보면 이는 단순한 클라우드 리소스 탐색처럼 보일 수 있다. 그러나 실제 의미는 훨씬 더 크다. AWS Bedrock 같은 서비스는 단순한 AI API 플랫폼이 아니다. 기업 내부에서는 다음과 같은 작업과 연결되는 경우가 많다.

문서 요약 자동화
고객 데이터 분석
내부 검색 시스템(RAG)
보안 로그 분석
코드 생성 및 검토
업무 자동화 Agent

즉 Bedrock 접근 권한은 단순한 모델 호출 권한이 아닌, 기업 내부 AI 자동화 흐름에 접근할 수 있는 권한에 가깝다. 공격자는 이를 통해 기업이 어떤 종류의 AI 자동화를 운영하고 있는지, 어떤 데이터 흐름이 AI 환경과 연결되어 있는지, 어떤 모델과 워크로드가 반복적으로 사용되는지를 추론할 가능성을 갖게 된다. 이 지점에서 API Key는 단순 인증값이 아니라 AI 시대의 새로운 세션 토큰(Session Token)에 가까워진다.

“LLM Jacking”의 핵심은 비용이 아니라 관찰 가능성

최근 보안 업계에서는 “LLM Jacking”이라는 표현이 등장하기 시작했다. 일반적으로는 훔친 API Key를 사용해 무단으로 AI 모델을 호출하거나 비용을 발생시키는 행위를 의미한다. 그러나 실제 위험은 단순 비용 문제에 머물지 않는다. 오히려 더 중요한 문제는 공격자가 피해 기업의 AI 환경 내부를 조용히 관찰할 수 있게 된다는 점이다.

과거 랜섬웨어는 즉각적으로 드러났다. 파일 암호화가 발생하고 시스템 장애가 발생하며 기업은 침해 사실을 즉시 인지했다. 그러나 AI API 기반 침해는 훨씬 더 은밀하다. 이러한 활동은 대부분 정상적인 API 호출과 구분하기 어렵다. 공격자는 정상 트래픽 안에서 움직이면서 기업의 AI 사용 패턴과 자동화 흐름을 장기간 관찰할 가능성을 갖게 된다. 이러한 구조는 기존 침해와 근본적으로 다르다. 과거의 침해가 “데이터 탈취” 중심이었다면, AI 시대의 침해는 “운영 구조 관찰”로 확장되기 시작한다.

이 흐름은 이미 오래전부터 시작됨

사실 이번 사건은 완전히 새로운 흐름이라기보다, 기존 클라우드 Credential 탈취 흐름의 연장선에 가깝다. 대표적인 사례가 2021년 Codecov 공급망 공격이다. 공격자는 Codecov Bash Uploader를 변조해 CI/CD 환경 변수들을 외부 서버로 전송했다. 이 과정에서 다수 기업의 클라우드 키와 인증 토큰이 유출되었다. 2023년 JetBrains TeamCity 취약점 역시 비슷한 흐름을 보여준다. 공격자들은 TeamCity 서버를 침해한 뒤 CI/CD 환경에 저장된 Credential과 Cloud Access Token을 확보하려 했다. 당시 공격 대상은 CI/CD 환경이었지만, 지금은 동일한 흐름이 AI Workflow 환경으로 확장되었다는 점이 다를 뿐, 구조는 동일하다.

이 사건들을 통해 공격자들이 더 이상 단순 사용자 PC나 파일 서버만 노리지 않는 다는 것을 이해할 수 있다. 이제는 권한이 집중되는 자동화 플랫폼을 노린다. 그리고 이제 생성형 AI 시대에는 Langflow 같은 AI Workflow 도구가 바로 그 위치에 놓이기 시작했다. 바로 이 지점이 Langflow와 같은 도구들을 잘 살펴야하는 이유가 되는 것이다.

Attack Surface로 활용되는 AI Workflow Platform by TheTechEdge(AI-generated)

AI Workflow 도구는 새로운 공격 허브

과거의 개발·자동화 도구는 비교적 제한된 역할을 수행했다. 특정 프로그램을 빌드하거나, 로그를 처리하거나, 내부 업무를 자동화하는 수준이었다. 물론 이러한 시스템에도 중요한 권한은 존재했지만, 대부분은 개별 기능 단위에 가까웠다. 하나의 시스템이 기업 전체 운영 구조를 직접 연결하는 경우는 상대적으로 드물었다. 그러나 생성형 AI 환경에서는 상황이 달라지기 시작한다.

Langflow 같은 AI Workflow 도구는 단순한 시각화 인터페이스가 아니다. 실제 운영 환경에서 이러한 도구는 다양한 시스템 사이를 연결하는 중심 역할을 수행한다. 하나의 Workflow 안에는 LLM API 호출, 벡터 데이터베이스 검색, 사내 문서 접근, 클라우드 스토리지 연결, Agent 실행 로직, 업무 자동화 흐름이 함께 포함된다. 즉 AI Workflow 도구는 단순히 모델을 실행하는 플랫폼이 아닌, 기업 내부의 데이터 흐름과 자동화 구조를 연결하는 Orchestration Layer에 가까워진다.

문제는 이 과정에서 권한 역시 한곳으로 집중되기 시작한다는 것이다. AI Workflow가 복잡해질수록 시스템은 더 많은 API Key와 클라우드 Credential, 데이터 접근 권한을 필요로 한다. AWS Bedrock, OpenAI, Anthropic, Vector DB, S3 Storage, 내부 Knowledge Base가 하나의 Workflow 안에서 동시에 연결되기 시작하면, 결국 Workflow 도구 자체가 기업 내부 AI 운영 구조의 중심 허브가 된다.

이 지점에서 공격 표면의 성격 역시 바뀐다. 과거 공격자가 개별 서버나 데이터베이스 권한 탈취를 위해 노력했다면, 이제는 AI Workflow 도구 하나만 침해해도 기업 내부 AI 자동화 구조 전체를 관찰할 가능성이 생긴다. 어떤 데이터를 검색하는지, 어떤 Prompt가 반복적으로 사용되는지, 어떤 Agent가 어떤 업무를 자동화하는지, 어떤 모델이 특정 업무에 연결되는지를 하나의 플랫폼 안에서 파악할 수 있기 때문이다.

바로 이것이 Langflow 사건이 단순한 API Key 유출 사건으로 보기 어려운 이유다. 중요한 문제는 공격자가 단순한 인증 정보를 확보한 것이 아닌, 기업 내부 AI 운영 구조 전체를 들여다볼 수 있는 위치에 접근했다는 점이다.

공격자는 비용이 아니라 ‘AI 실행 권한’을 노린다

Langflow 취약점을 이용한 공격은 단순한 API 비용 남용 사건으로 축소해서 보기 어렵다. 진짜 문제는 공격자가 기업의 AI 운영 구조 안으로 들어갈 수 있었다는 점이다. API Key는 더 이상 단순한 인증 문자열이 아니다. 그것은 기업의 AI 자동화 흐름에 접근할 수 있는 실행 권한이며, 내부 지식 흐름을 이해할 수 있는 관찰 권한이고, AI Agent 구조를 추적할 수 있는 새로운 세션 토큰이다.

우리는 지금까지 AI 보안을 주로 모델 안전성이나 Prompt Injection 문제 중심으로 논의해왔다. 그러나 Langflow 취약점은 다른 질문을 던진다.

기업은 과연 자신들의 AI 운영 구조 자체를 얼마나 보호하고 있는가?

공격자는 서버만을 공격하기 위해 노력하지 않는다. 이제 기업이 AI를 사용하는 방식 자체를 이해하려 한다. AI Workflow 도구가 기업 내부 자동화의 중심이 되는 순간, 공격자는 더 이상 개별 서버를 침해할 필요가 없어질 수 있다. 대신 기업이 AI를 통해 어떻게 사고하고, 분류하고, 자동화하는지를 이해할 수 있는 구조 자체가 새로운 공격 표면이 되기 시작한다.