AI workflow builder에 노출 위험이 생겼을 때, 왜 인증 정보 교체부터 하면 안 될까?

Larry

보안 알림을 하나 받았다고 해보자. 팀이 AI agent를 연결하는 데 쓰는 workflow builder가 예상하지 못한 신원에게 보였거나 실행되었을 가능성이 있다는 내용이다.

workflow는 먼저 “고정된 인수인계 단계가 이어지는 흐름”으로 이해하면 된다. 양식을 받고, 모델에게 요약을 시키고, CRM을 조회하고, 데이터베이스에 다시 쓰고, Slack으로 알림을 보내는 식이다. agent는 “몇 단계의 작업을 스스로 이어서 수행하는 AI 도우미”라고 볼 수 있다. 이 둘이 builder 안에 들어가면 화면에서는 예쁜 노드 몇 개처럼 보이지만, 그 아래에는 API key, 데이터베이스 token, CRM 권한, 내부 webhook(다른 시스템이 이 flow를 호출할 수 있는 알림 입구), 심지어 production 환경의 장기 자격 증명이 숨어 있을 수 있다.

이후 Langflow CVE-2026-55255는 CISA의 Known Exploited Vulnerabilities catalog에 추가되었다. 더 이른 Sysdig 분석은 이런 위험이 어떻게 움직이는지를 설명한다. 공격자가 flow ID를 얻으면 flow를 열거하고, endpoint를 호출하며, 프로세스가 API key를 내놓게 하려는 입력을 사용할 수 있다. 그렇다고 오늘 글을 특정 제품의 취약점 회고로만 읽을 필요는 없다. 더 오래 남는 교훈은 이것이다. AI workflow builder가 노출되었을 때 가장 위험한 것은 그 화면 자체가 아닐 수 있다. 더 위험한 것은 그 프로세스가 대신 보관하고, 호출하고, 넘겨주던 자격 증명이다.

첫 조치가 “전부 바꾸자”라면 두 가지 나쁜 결과가 쉽게 생긴다. 하나는 실제로 닿지 않은 열쇠만 잔뜩 바꾸고, 의심스러운 flow에서 실제로 실행된 token은 놓치는 경우다. 다른 하나는 rotation을 너무 빨리 진행해 로그를 보존하기 전에 증거가 사라지고, 나중에 어떤 데이터 소스가 읽혔는지 알 수 없게 되는 경우다.

하지만 rotation을 잠시 미룬다는 말이 아무것도 하지 않고 기다린다는 뜻은 아니다. 먼저 피를 멈춰야 한다. 공개 공유 링크, 의심스러운 webhook(다른 시스템이 이 flow를 호출할 수 있는 알림 입구), 외부 API route(외부 시스템이 직접 들어올 수 있는 경로)를 일시 중지하고, builder와 admin 접근을 VPN, allowlist(허용된 출처만 통과시키는 목록), 내부망으로 좁힌다. 고위험 connector(CRM, 데이터베이스, 클라우드 서비스와 연결되는 통로)가 있는 flow는 삭제하지 말고 실행만 막는다. 그런 다음 로그를 보존하고, 실제로 닿은 flow와 credential 범위를 좁힌 뒤 순서대로 rotation한다.

이번 미니 레슨의 핵심 질문은 이것이다. AI workflow builder나 agent builder가 노출되었을 때, 작은 팀은 먼저 실행과 외부 노출을 어떻게 막고, 프로세스 안에 숨어 있는 자격 증명을 어떻게 찾아내며, 그다음 rotation, 로그 보존, production token 경계 재설정을 결정할 수 있을까?

팀이 AI workflow 지도를 점검하고, 옆에 빈 열쇠 카드와 로그북, 안전 보관함이 놓인 따뜻한 손그림 책상 일러스트, 글자 없음.

이 수업에서 다루는 내용

먼저 피를 멈춘다. 공개 링크, 의심 webhook, 외부 route, admin 접근, 고위험 flow 실행을 잠시 막는다.
다음으로 판단한다. 이것이 “인터페이스가 스캔된 사건”인지, 아니면 “flow가 실행되었을 가능성이 있는 사건”인지 구분한다.
텍스트 의사결정 트리로 flow, token, 데이터 소스, 로그를 네 개의 점검 층으로 나눈다.
기억에 의존하지 않고 40분 안에 첫 번째 자격 증명 점검을 끝낸다.
결과 정리는 AI에게 맡기되, 비밀값은 prompt에 붙여 넣지 않는다.

먼저 질문을 바꾸자: 찾아야 할 것은 제품명이 아니라 프로세스 안의 열쇠다

많은 팀은 workflow builder 사고를 보면 먼저 이렇게 묻는다. “우리 Langflow 쓰고 있나? 버전은 패치됐나?”

물론 이 질문은 필요하다. 하지만 첫 번째 층만 해결할 뿐이다. 더 중요한 것은 이어지는 네 가지 질문이다.

어떤 flow가 외부, 내부망, 테스트 계정, 또는 알 수 없는 사용자에게 열려 있었는가?
어떤 flow 안에 자격 증명, 환경 변수, 연결 문자열, 대입 가능한 secret이 들어 있는가?
어떤 flow가 고객 데이터, 내부 문서, CRM, ticket, 데이터베이스, 파일 시스템을 읽을 수 있는가?
어떤 flow가 실행, replay, export, 복사되었거나 접근하면 안 되는 사람이 본 적이 있는가?

이 질문을 던지기 전에 최소한의 containment를 먼저 적용해야 한다. 공개 공유 링크와 의심 webhook은 잠시 끄고, 외부에서 직접 호출되는 API route는 막거나 내부망으로 제한한다. builder 관리자 화면은 VPN, allowlist, 내부 네트워크에서만 접근하게 바꾼다. 고위험 flow는 삭제하지 말고 실행을 비활성화한다. 삭제하면 설정과 실행 흔적을 잃을 수 있기 때문이다.

예전에 CRM 연동 token 유출을 처리해본 적이 있다면 여기의 논리는 비슷하다. “어느 열쇠가 샜나”만 묻지 말고, 그 열쇠가 어떤 문을 열 수 있는지 먼저 그려야 한다. 가까운 상황으로는 이 글을 참고할 수 있다. CRM 연동 token 유출 후에는 먼저 데이터 경계를 그리자.

AI builder에는 추가로 성가신 점이 있다. 자격 증명이 설정 페이지 하나에만 있지 않을 수 있다. 노드 설정, 환경 변수, 테스트 input, prompt 예시, connector 설정, export된 JSON, 예전 버전의 flow, 복사본 flow, 또는 “일단 admin token으로 테스트하자”라고 만든 임시 노드 안에 숨어 있을 수 있다.

그래서 첫 단계는 어떤 token이 가장 위험한지 추측하는 일이 아니라, “프로세스가 실제로 어떻게 실행되었고 지금 어디를 통해 더 실행될 수 있는지”를 복원하는 일이다.

텍스트 의사결정 트리: 노출면에서 자격 증명 rotation까지

아래 의사결정 트리는 Langflow만을 위해 만든 것이 아니다. AI workflow builder, agent builder, low-code 자동화 플랫폼, 또는 모델, API, 데이터 소스를 flow로 연결하는 도구를 쓴다면 같은 순서로 적용할 수 있다.

시작점: builder, flow API, 공유 링크, 실행 endpoint 또는 관리 인터페이스가 노출되었을 가능성이 있다

0. 지금도 외부에서 실행되거나 관리될 수 있는 경로가 있는가?
   ├─ 공개 공유 링크가 있다: 링크를 일시 중지하고 접근 기록을 보존한다
   ├─ 의심스러운 webhook 또는 외부 API route가 있다: route를 막거나 내부망 / allowlist로 제한한다
   ├─ builder 또는 admin 화면이 인터넷에서 열려 있다: VPN, allowlist, 내부 네트워크로 접근 범위를 좁힌다
   └─ 고위험 flow가 계속 실행될 수 있다: flow를 삭제하지 말고 실행만 비활성화한 뒤 1번으로 간다

1. 예상하지 않은 신원으로 어떤 flow를 보거나 실행할 수 있었는가?
   ├─ 증거는 없지만 인터페이스가 외부에 열려 있었다: access log를 먼저 보존한 뒤 flow inventory를 만든다
   └─ 증거가 있거나 강하게 의심된다: 2번으로 간다

2. 의심 기간 동안 어떤 flow가 읽히거나, 열거되거나, export되거나, 복사되거나, 실행되었는가?
   ├─ metadata만 보였다: flow owner를 표시하고 이름과 설명이 시스템 정보를 누설했는지 확인한다
   └─ flow가 실행되었을 가능성이 있다: 3번으로 간다

3. 해당 flow 안에는 어떤 종류의 자격 증명이 있는가?
   ├─ 테스트 token이고 sandbox만 호출할 수 있다: 먼저 폐기한 뒤 공식 데이터와 연결되지 않았는지 확인한다
   ├─ production token이지만 권한이 단일 저위험 서비스에 한정된다: 호출 기록을 보존하고 우선 rotation한다
   ├─ production token이며 고객, 재무, 신원, 내부 문서를 읽거나 쓸 수 있다: 즉시 격리하고 사건 등급을 올린다
   └─ token 권한을 모른다: owner의 기억을 기다리지 말고 production 고위험으로 취급한다

4. flow가 데이터를 외부로 내보내거나 내부 시스템에 다시 쓸 수 있는가?
   ├─ 읽기만 가능하고 출력이 플랫폼 안에 남는다: 출력 기록과 실행 파라미터를 보존한다
   ├─ webhook, email, Slack, 외부 API를 호출할 수 있다: 모든 outbound call을 추적한다
   └─ 데이터베이스, CRM, ticket, 파일에 쓸 수 있다: 데이터 변조 사건에 준해 rollback 필요성을 확인한다

5. 앞의 네 질문을 마친 뒤 credential rotation 순서를 정한다
   ├─ 먼저 바꿀 것: 의심 flow 안에 있었고, production에서 쓸 수 있으며, 고민감 데이터를 읽거나 쓸 수 있는 token
   ├─ 다음에 바꿀 것: 권한은 낮지만 의심 flow에서 호출된 token
   └─ 마지막으로 정리할 것: 노출되지는 않았지만 이름이 혼란스럽고, 권한이 과하며, owner가 없는 오래된 token

이 트리의 핵심은 “취약점이 있었나”라는 질문을 “어느 프로세스가 어느 열쇠를 잡았나”로 바꾸는 데 있다. 전자는 모두가 CVE 점수와 패치 버전에만 매달리게 만든다. 후자라야 실제로 폐기, rotation, 권한 축소, 증거 보존이 필요한 지점을 찾을 수 있다.

40분 첫 번째 점검: 단체 채팅방의 기억에 의존하지 말자

팀이 엔지니어 두세 명, 제품 책임자 한 명, 시스템 연동을 아는 사람 한 명 정도라면 첫 번째 점검을 큰 war room으로 만들 필요는 없다. 40분이면 실행 가능한 버전을 만들 수 있다.

1단계: 증거를 바꿀 수 있는 행동부터 멈춘다

먼저 다섯 가지를 한다.

공개 공유 링크, 의심스러운 webhook, 외부에서 호출 가능한 flow API route를 일시 중지한다.
builder와 admin 접근을 VPN, allowlist, 내부 네트워크로 제한한다.
고위험 flow의 신규 생성 또는 수정을 일시 중지하고, 의심 flow는 삭제하지 않은 채 실행만 막는다.
현재 flow 목록, connector 목록, 환경 변수 이름, 권한 페이지를 export하거나 스크린샷으로 보존한다.
builder access log, flow execution log, API gateway log, outbound webhook log를 보존한다.

여기서 조심할 점이 있다. secret이 보인다고 모든 화면을 공유 문서에 붙여 넣으면 안 된다. 공유 문서에는 “token 유형, 권한 범위, owner, 마지막 사용 시간”을 적고, token 원문은 적지 않는다.

API는 “시스템과 시스템이 데이터를 주고받는 인터페이스”로 이해하면 된다. builder 뒤에 API gateway나 reverse proxy가 있다면 그쪽 로그도 함께 보존하자. builder 화면 안의 기록만으로는 충분하지 않은 경우가 많다.

2단계: 사용 중인 flow만이 아니라 모든 flow를 나열한다

flow를 네 그룹으로 나누자.

production에서 실행 중: 고객, 내부 운영, 공식 데이터에 영향을 준다.
staging / sandbox: 원칙적으로 테스트 데이터만 다루지만, 실제 production token을 갖고 있을 수 있다.
archived / disabled: 꺼져 있지만 설정은 남아 있어 복사되거나 export될 수 있다.
personal / experiment: 개인 테스트, demo, 임시 PoC이며 이름 없는 token이 가장 자주 숨어 있다.

많은 사고에서 누락되는 지점은 뒤의 두 그룹이다. 모니터링 대시보드에도 없고 공식 아키텍처 문서에도 적혀 있지 않지만, 당시 테스트를 빠르게 하려고 권한 있는 key를 그대로 붙여 넣었을 수 있다.

3단계: 각 flow에 네 개의 필드를 표시한다

여기서는 표 하나면 충분하다. 점검을 표 더미로 만들지 말자.

점검 필드	무엇을 채우나	구체적 판단 기준	채울 수 없다면
flow 노출 상태	공개된 적이 있는지, 공유되었는지, 예상 밖의 계정이 봤는지, API로 호출되었는지	access log에 알 수 없는 IP, 알 수 없는 계정, 비정상 user-agent가 있거나 execution log에 예약되지 않은 시간의 실행이 있다	“알 수 없지만 추적 필요”로 표시하고 안전하다고 표시하지 않는다
자격 증명 유형	API key, OAuth token, 데이터베이스 연결, webhook secret, cloud role	production 읽기/쓰기 가능, workspace 간 접근 가능, 만료일 없음, admin 권한 포함 중 하나라도 있으면 고위험	owner를 찾지 못하면 구두 확인을 기다리지 말고 먼저 비활성화하거나 복사본 권한을 줄인다
데이터 소스와 출력	어디를 읽고, 어디에 쓰며, 외부 전송이 가능한지	고객 데이터, 신원 데이터, 재무 데이터, 내부 문서를 읽을 수 있거나 CRM / DB / ticket에 쓸 수 있으면 등급을 올린다	prompt를 보고 추측하지 말고 connector 설정과 최근 30회 실행 출력 요약을 먼저 확인한다
로그와 증거	누가 실행했는지, 어떤 파라미터를 넣었는지, 어떤 외부 서비스에 닿았는지 증명할 위치	최소한 시간, 실행자 또는 token, flow ID, 대상 endpoint, 결과 상태가 있어야 한다	로그가 7일 미만이거나 outbound log가 없으면 gateway / SIEM(여러 시스템의 보안 로그를 모아 검색하고 알림을 주는 도구) / cloud service 기록을 즉시 보강한다

이 표에는 두 가지 쓰임이 있다. 첫째, 엔지니어가 기억만으로 “그건 테스트 flow였어요”라고 말하지 않게 한다. 둘째, 비엔지니어 owner도 왜 어떤 token을 먼저 바꾸고 어떤 flow를 먼저 멈춰야 하는지 이해하게 해준다.

팀이 이미 agent 권한 설계를 하고 있다면 이 내용을 더 이른 단계의 점검표와 연결할 수도 있다. AI agent 권한 부여 네 가지 질문: 신원, 권한, 이유, 결과. 그 글은 사전 설계에 가깝고, 이 글은 사후 점검에 가깝다. 둘을 함께 써야 agent가 “로그인된 것처럼 보인다”는 이유만으로 과도한 권한을 받는 일을 막을 수 있다.

4단계: 보이기만 한 flow보다 실행 가능한 flow를 먼저 처리한다

모든 노출이 같은 심각도를 갖지는 않는다. 다음 순서로 queue를 만들 수 있다.

의심 기간에 실행되었고 production token을 포함한 flow.
의심 기간에 읽히거나 export되었으며 설정 안에 secret 이름, connector, 내부 endpoint가 보이는 flow.
실행 증거는 없지만 공개 공유된 적이 있거나, 권한이 과하거나, owner가 불명확한 flow.
비활성화되었지만 여전히 복사, export, 또는 admin 계정으로 재활성화할 수 있는 flow.

queue는 처리 대기 목록, 즉 줄 서 있는 작업이라고 이해하면 된다. 여기서 queue에 “token 교체”라고만 쓰지 말자. 각 항목을 어느 flow, 어느 credential, 어느 owner, 어느 시스템, 어떤 검증 방식인지로 쪼개야 한다.

예를 들어 이렇게 쓰지 않는다.

Salesforce token 교체.

대신 이렇게 쓴다.

Flow lead-summary-prod가 사용하는 Salesforce OAuth app(flow가 허가된 Salesforce 신원으로 접근하게 해주는 연결 설정): refresh token을 일시 중지하고 최소 권한 app으로 재발급한다. 최근 100회 flow execution에 알 수 없는 실행자가 없는지 확인한다. owner: RevOps. 검증: Salesforce Login History + builder execution log.

이런 식으로 써야 추적하기 쉽고, 나중에 인수인계하기도 쉽다.

자격 증명을 rotation하기 전에 세 가지 로그를 먼저 보존한다

많은 팀은 token을 빨리 rotate하고 싶어 한다. 그 직감은 이해할 수 있다. 하지만 최소한 세 가지 기록은 먼저 보존하자. 동시에 외부 실행 경로는 닫아야 한다. rotation 순서를 정하는 동안에도 공개 링크, webhook, 외부 API route, admin 화면이 그대로 열려 있으면 같은 flow가 다시 실행될 수 있다.

첫 번째는 builder 자체의 access log와 execution log다. 누가 로그인했는지, 누가 flow를 봤는지, 누가 run을 눌렀는지, 어떤 flow ID가 호출되었는지, 입력 파라미터가 대략 어떤 형태였는지 알아야 한다.

두 번째는 대상 시스템의 호출 기록이다. flow가 CRM, 데이터베이스, cloud storage, ticket 시스템을 호출한다면 그 시스템에 비정상 요청이 들어왔는지 봐야 한다. builder log만 보면 “flow는 밖으로 호출에 성공했지만 builder에는 완전한 출력이 남지 않은” 상황을 놓칠 수 있다.

세 번째는 outbound channel이다. 많은 AI workflow는 결과를 Slack, email, webhook, 외부 API, 문서 도구로 보낸다. 이런 출구는 모델 자체보다 더 위험할 수 있다. 데이터가 원래의 권한 경계를 벗어나기 때문이다.

로그가 충분하지 않아도 완벽할 때까지 기다릴 필요는 없다. 방법은 이렇다. 고위험 flow 실행은 멈추고, 고위험 token은 먼저 일시 중지하거나 권한을 줄이며, 동시에 incident note에 “로그 부족으로 데이터 읽기를 배제할 수 없음”이라고 표시한다. 이 문장은 중요하다. 이후 통지, 법무 판단, 고객 커뮤니케이션에 영향을 주기 때문이다.

production token 경계는 재설정해야 한다. 같은 열쇠로 바꾸기만 해서는 부족하다

credential rotation에서 흔한 실수는 기존 token을 같은 권한을 가진 새 token으로 바꾸는 것이다. 단기적으로는 처리한 것처럼 보이지만 장기 위험은 줄지 않는다.

rotation할 때는 다음 네 가지를 함께 하자.

계정 분리: production token을 개인 계정에서 service account로 옮긴다.
권한 분리: 읽기와 쓰기 권한을 분리한다. 요약 flow가 데이터 삭제 권한까지 동시에 가져서는 안 된다.
만료일 지정: 만료일과 owner를 설정한다. owner가 없는 token은 production에 넣지 않는다.
이름 정리: builder에서 사용할 secret 이름을 용도 중심으로 바꾼다. 예를 들어 crm_read_contacts_prod처럼 짓고, admin_key나 test_key라고 부르지 않는다.

owner는 마지막 판단과 마무리를 책임지는 사람이다. 여기서 owner는 “처음 flow를 만든 사람”이 아니라, 이 credential을 유지할지, 권한을 줄일지, rotation할지, 비활성화할지 결정할 수 있는 사람이다.

rotation만 끝내고 경계를 다시 설정하지 않으면 다음에 builder, agent, connector에서 사고가 날 때 팀은 같은 질문으로 돌아오게 된다. 도대체 어느 flow가 어느 과도한 열쇠를 잡고 있었나?

마지막에는 입구와 오래된 열쇠가 정말 닫혔는지 확인한다

rotation이나 권한 축소가 끝났다고 해서 단체 채팅방에 “처리 완료”라고 쓰고 멈추면 안 된다. owner는 같은 inventory로 세 가지를 다시 확인한다.

입구가 닫혔다: 공개 공유 링크, 의심스러운 webhook, 외부 API route, 알 수 없는 계정, 외부에서 접근 가능한 admin 입구가 꺼졌거나 통제된 범위로 제한되었다.
오래된 자격 증명이 무효다: 고위험 token, refresh token, service account key로 production 시스템 호출이 더는 성공하지 않는다.
새 경계를 감사할 수 있다: 새 credential에는 owner, 만료일, 최소 권한, 로그 위치, 다음 월간 점검일이 있다.

이 단계는 형식적인 마무리가 아니다. 입구가 다시 열리거나 오래된 token이 계속 작동하는 흔한 사고 반동을 막기 위한 확인이다.

첫 번째 최소 시작 행동

지금 한 가지만 할 수 있다면 “AI flow credential inventory” 문서를 열기 전에 외부로 열린 실행 경로부터 잠시 막자. 공개 공유 링크, 의심 webhook, 외부 API route를 멈추고, builder와 admin 화면을 VPN, allowlist, 내부망으로 제한한다. 고위험 flow는 삭제하지 말고 실행만 비활성화한다.

그다음 production flow와 최근 30일 안에 실행된 flow부터 inventory에 적자.

각 flow에는 다섯 칸만 채운다.

flow 식별: flow 이름과 ID.
owner 지정: owner.
시스템 연결: 연결된 외부 또는 내부 시스템.
credential 기록: 사용하는 credential 이름. secret 원문은 쓰지 않는다.
로그 위치: 마지막 실행 시간과 로그 위치.

이 inventory는 사고가 나야만 만드는 문서가 아니다. 평소에 매달 한 번 업데이트해두면, 사고가 났을 때 바로 incident response의 출발점이 된다.

AI 정리 카드

아래 내용을 AI에게 넘기기 전에 token 원문, 고객 데이터, 내부 endpoint의 전체 경로, 외부로 나가면 안 되는 log를 먼저 제거하자. AI는 점검 정리를 도울 수 있지만, 비밀을 보관해서는 안 된다.

당신은 보안팀과 엔지니어링팀이 AI workflow builder 노출 사건을 정리하도록 돕는 분석 보조자입니다. 내가 제공하는 flow inventory를 바탕으로 incident triage 요약을 작성해 주세요.

제한:
- API key, token, password, private endpoint 원문을 제공하라고 요구하지 마세요.
- 필드가 부족하면 “사람이 추가 확인 필요”라고 표시하고, 안전하다고 임의로 가정하지 마세요.
- 제안을 즉시 containment, 즉시 격리, 24시간 내 rotation, 7일 내 권한 축소, 사후 개선으로 나누어 주세요.

각 flow를 아래 필드로 분석해 주세요:
1. flow 이름과 ID
2. owner
3. 노출 상태: 공개, 내부, 알 수 없음, 의심 실행 이력 있음
4. credential 유형: API key, OAuth token, DB connection, webhook secret, cloud role, 알 수 없음
5. credential 권한: production read, production write, sandbox only, admin, 알 수 없음
6. 데이터 소스와 출력: 읽기 시스템, 쓰기 시스템, 외부 전송 채널
7. 로그 위치: builder log, API gateway log, 대상 시스템 log, outbound log
8. 마지막 실행 시간
9. 현재 containment 상태: 공유 링크 중지, webhook 중지, 외부 route 제한, admin 접근 제한, flow 실행 비활성화 여부

다음을 출력해 주세요:
- 지금도 열려 있을 수 있는 노출 경로
- 고위험 flow 목록과 이유
- 권장 credential rotation 순서
- 먼저 보존해야 할 로그
- owner가 결정해야 할 질문
- 비엔지니어 임원을 위한 150자 요약

이 카드의 목적은 AI가 침입 여부를 판정하게 하는 것이 아니다. flow, token, log, owner, containment 사이에 흩어진 정보를 논의 가능한 순서로 정리하게 하는 것이다. 마지막에 비활성화, 통지, rotation, 사건 등급 상향 중 무엇을 할지는 여전히 사람 owner가 마무리해야 한다.

생활 4컷 만화

네 컷 만화: 팀이 먼저 노출된 workflow 입구를 닫고, 로그를 보존한 뒤, flow 안의 자격 증명을 따라가고, 실제로 위험했던 열쇠만 처리한다.

팀은 AI workflow 입구가 열려 있는 것을 보고, 모든 열쇠를 급히 바꾸기 전에 멈춘다.
입구를 통제된 범위로 돌려놓고 로그와 설정은 지우지 않는다.
어떤 connector, 데이터 소스, token을 flow가 실제로 건드릴 수 있었는지 따라간다.
영향을 받은 열쇠만 교체하거나 비활성화하고, 입구가 닫혔는지와 오래된 자격 증명이 더는 작동하지 않는지 확인한다.

참고 자료

CISA：CISA Adds Three Known Exploited Vulnerabilities to Catalog — https://www.cisa.gov/news-events/alerts/2026/07/07/cisa-adds-three-known-exploited-vulnerabilities-catalog（2026-07-07）

Sysdig：Understanding Langflow CVE-2026-55255, and why higher CVSS vulnerabilities aren’t always the most exploited — https://www.sysdig.com/blog/understanding-langflow-cve-2026-55255-and-why-higher-cvss-vulnerabilities-arent-always-the-most-exploited（2026-06-26）

NVD：CVE-2026-55255 Detail — https://nvd.nist.gov/vuln/detail/CVE-2026-55255（2026-06-23）