유지보수자 테스트가 수정안을 평가하기 전까지는 강력해 보이는 Claude 취약점 패치

새 연구에서 Claude의 취약점 패치는 크래시 기반 검증의 90.2%를 통과했지만, 유지보수자가 작성한 테스트를 통과한 패치는 60.7%에 그쳤다. 29.5%포인트의 이 격차는 겉으로 드러난 성공의 의미를 바꾼다. 하나의 악성 입력이 프로그램을 크래시시키지 못하게 했다고 해서 근본 취약점이 올바르게 수정됐다는 뜻은 아니다.

Northwestern University의 Dang K Le, Wenxuan Shi, Xinyu Xing 연구진은 10월 7일 이 결과를 발표했다. 이들의 벤치마크 신뢰성 연구는 84개 오픈소스 프로젝트의 과거 버그 112건을 조사했다. 데이터세트는 C, C++, Go, Rust 소프트웨어를 포함했다.

이 논문은 AI 코딩 에이전트를 평가하는 데 사용되는 채점 체계에 의문을 제기한다. 많은 벤치마크는 개념 증명 코드, 즉 PoC가 더 이상 보고된 실패를 유발하지 않으면 패치를 보상한다. 하지만 유지보수자의 기대는 대체로 더 높다. 수정안은 의도된 동작을 보존하고, 근본 원인을 해결하며, 원래 보고서에서 테스트하지 않은 인접 입력에도 견뎌야 한다.

이 충돌은 모델 개발사, 벤치마크 설계자, 기업 보안팀에 압박을 가한다. Claude와 다른 코딩 에이전트는 눈에 보이는 테스트를 충족하는 능력이 향상되고 있다. 그러나 이 증거는 업스트림 유지보수자가 수용할 만한 패치에 대해서도 동등한 진전이 있었음을 보여주지는 않는다.

Claude 취약점 패치 점수는 서로 다른 두 결과를 감춘다

연구는 크래시 테스트 통과와 수용 가능한 보안 수정안 생성이 동등한 성과가 아니라는 점을 보여줬다.

연구진은 기반 Claude 모델만 바꾸면서 동일한 112개 사례를 OpenCode 에이전트로 실행했다. Claude Sonnet 4.0, Sonnet 4.5, Opus 4.7을 테스트했다. 각 실행에는 빌드와 테스트 지침이 제공됐지만 PoC 본문은 제공되지 않았다.

Sonnet 4.0은 제공된 PoC를 77.7%의 사례에서 막았다. Sonnet 4.5는 84.8%, Opus 4.7은 90.2%에 도달했다. 이 진행만 보면 자동화된 취약점 수정이 포화 수준에 접근하고 있는 듯 보인다.

유지보수자 관점의 결과는 다른 이야기를 들려준다. Sonnet 4.0은 개발자 테스트를 43.8%의 사례에서 통과했다. Sonnet 4.5는 48.2%, Opus 4.7은 60.7%에 도달했다.

따라서 Opus는 두 지표 모두에서 개선됐지만, 두 지표 사이의 간격은 여전히 컸다. PoC를 통과한 Opus 패치 중 32.7%는 여전히 개발자 테스트에 실패했다. 겉보기 성공 사례 세 건 중 약 한 건에 해당한다.

연구진은 기존에 테스트된 동작이 계속 작동하는지 확인하는 일반 회귀 테스트도 측정했다. Opus 4.7은 이 테스트를 94.6%의 사례에서 통과했다. 이 높은 결과도 훨씬 낮은 개발자 테스트 점수를 상쇄하지는 못했다.

이 차이는 중요하다. 기존 회귀 테스트 모음은 새 보안 수정안의 정확한 설계 결정을 드물게만 담기 때문이다. 익숙한 동작이 그대로 유지되는지는 확인할 수 있지만, 보고된 실패 지점 근처의 피상적인 수정은 놓칠 수 있다.

이 연구의 개발자 테스트는 업스트림 수정 커밋에서 가져왔다. 이는 각 프로젝트의 개발자가 버그를 수정할 때 작성한 단위 또는 통합 테스트였다. 연구진은 이 추가 테스트를 재구성해 AI 에이전트가 패치를 생성한 뒤 적용했다.

이 접근 방식은 생성된 코드가 취약점 주변에서 유지보수자의 의도대로 동작하는지를 묻는다. AI가 유지보수자의 패치 텍스트를 재현할 필요는 없다. 동작이 프로젝트가 수용한 의미론과 일치한다면 대안적 수정안도 통과할 수 있다.

데이터세트는 네 개의 연속 관문도 적용했다. 패치된 프로젝트는 빌드되고, 반복 실행에서 PoC를 차단하며, 기존 회귀 테스트 모음을 통과하고, 추가된 개발자 테스트도 통과해야 했다. 모든 단계를 통과한 경우에만 사례가 완전히 해결된 것으로 집계됐다.

공개된 채점 분석은 유지보수자 의도에 가장 가까운 테스트를 많은 수용 패치가 통과하지 못한다는 실무적 위험을 포착하기 때문에, 세 건 중 한 건의 실패율에 주목했다. 매력적인 헤드라인 점수는 수용된 패치 다수가 실패하더라도 유지될 수 있다.

이는 Opus 4.7이 보안 작업에 효과적이지 않다는 뜻은 아니다. 보고된 능력은 벤치마크가 성공을 무엇으로 정의하는지에 크게 좌우된다는 점을 보여준다. 모델이나 패치를 바꾸지 않고도 채점 규칙만으로 결론이 달라질 수 있다.

크래시를 막는 일은 버그를 수정하는 일과 다르다

PoC는 하나의 실패가 사라졌다는 증거일 뿐, 취약한 동작이 유효한 운영 범위 전반에서 수정됐다는 증명은 아니다.

개념 증명 코드는 일반적으로 취약점을 재현하는 입력을 제공한다. 메모리 안전성 버그에서는 sanitizer 크래시를 유발할 수 있다. 논리 결함에서는 유효하지 않은 상태나 금지된 작업을 보여줄 수 있다.

이 입력은 실패를 구체적이고 반복 가능하게 만든다는 점에서 가치가 있다. 그러나 프로그램을 통과하는 경로는 하나만 드러낸다. 에이전트는 영향을 받은 함수를 지배하는 더 넓은 계약을 이해하지 못한 채 그 경로만 차단할 수 있다.

Northwestern 논문은 range() 함수를 포함한 과거 PHP 버그로 이 문제를 설명한다. 혼합 입력 유형이 잘못 분류되면 PHP가 문자열이 아닌 값을 문자열인 것처럼 접근하게 될 수 있었다. 제공된 한 입력은 크래시를 일으켰다.

방어적 패치는 혼합 유형을 즉시 거부해 이 크래시를 막을 수 있다. 이는 PoC를 충족하고 기존에 테스트된 여러 동작도 보존한다. 하지만 PHP가 변환해야 했던 유효한 혼합 숫자 및 문자열 입력까지 거부하게 된다.

업스트림 수정안은 의도된 동작을 유지하면서 잘못된 분류 로직을 변경했다. 개발자는 인접한 유효 입력을 위한 테스트를 추가했고, 이를 통해 진짜 수정과 지나치게 제한적인 우회책을 구분했다.

이것이 채점의 핵심 문제다. 크래시를 일으킨 입력만 확인하는 벤치마크는 두 패치에 같은 점수를 부여한다. 반면 유지보수자 테스트는 지원되는 동작을 오류로 바꾸는 패치를 거부한다.

보안 에이전트는 평가자가 관찰할 수 있는 항목을 최적화할 강한 유인을 가진다. 크래시가 주요 오라클이라면, 크래시 지점 근처에 가드를 추가하는 것은 합리적인 대응일 수 있다. 오라클은 단순히 출력이 올바른지 결정하는 메커니즘이다.

그 패치는 긴급 완화책으로는 유용할 수 있다. 그러나 자동으로 완전한 수정이라고 분류해서는 안 된다. 이 운영상 차이는 코드 리뷰, 배포 결정, 자율 시스템에 부여하는 신뢰도에 영향을 미친다.

이 문제는 자동화된 프로그램 수정 분야에서 이미 익숙하다. 통계 모델이 훈련 데이터에 과적합할 수 있는 것처럼, 패치도 테스트 모음에 과적합할 수 있다. 근본 요구 사항을 포착하지 못한 채 제공된 예시만 충족하는 것이다.

보안에서는 이 실수의 비용이 더 크다. 피상적인 패치는 잘못된 안도감을 만들거나, 눈에 보이는 증상만 억제하거나, 결함을 테스트되지 않은 경로로 옮길 수 있다. 그러면 검토자는 자동화된 성공 라벨이 붙은 코드에 쓰는 시간을 줄일 수 있다.

관련 패치 검증 연구는 20개 프로젝트의 209개 사례를 활용한 PVBench를 도입했다. 연구진은 기본 테스트에서 수용된 패치의 40% 이상이 개발자 수정안에서 도출된 추가 테스트에는 실패한다는 사실을 발견했다.

두 데이터세트와 평가 설계는 다르지만, 이 독립적인 결과는 더 광범위한 우려를 뒷받침한다. 반복되는 교훈은 기본 기능 검증과 하나의 익스플로잇 입력이 중요한 동작을 측정하지 못한다는 점이다.

따라서 Claude 취약점 패치는 계층적인 능력으로 해석해야 한다. 모델은 원인을 찾아내고, 올바른 로직을 수정하며, 정당한 동작을 보존하고, 새로운 약점을 피해야 한다. 크래시가 멈췄다는 사실은 그 사슬의 일부만 검증한다.

벤치마크 설계는 패치를 개선하지 않고도 점수를 바꿀 수 있다

프롬프트 세부 정보, 도구 접근 권한, 테스트 표현 방식은 개발자 기준 품질이 거의 변하지 않아도 측정 성능을 끌어올릴 수 있다.

Northwestern 연구진은 빌드 지침이 동일한 모델과 데이터세트에 어떤 영향을 주는지 테스트했다. 상세한 빌드 및 테스트 명령이 있을 때 Sonnet 4.0은 PoC의 77.7%를 통과했다. 이 지침이 없을 때는 74.1%를 통과했다.

전체 차이는 크지 않아 보인다. 그러나 언어 수준 결과의 차이는 훨씬 컸다. C 및 C++ 사례에서는 지침 제공 시 PoC 통과율이 72%에서 92%로 상승했다.

이 그룹의 개발자 테스트 성능은 28%에서 36%로만 올랐다. 모든 언어에서는 41.1%에서 43.8%로 증가했다. 더 나은 지침은 주로 에이전트가 하니스를 실행하고 눈에 보이는 결과를 확인하는 데 도움을 줬다.

이 결과가 지침이 부당하다는 뜻은 아니다. 인간 엔지니어도 문서화된 빌드 명령에서 도움을 받는다. 이는 정보 예산이 공개되지 않는 한 서로 다른 벤치마크의 점수를 안전하게 비교할 수 없다는 뜻이다.

프로그래밍 언어 관례도 또 다른 변수다. Go와 Rust 프로젝트는 빌드와 테스트를 위한 예측 가능한 명령을 제공하는 경우가 많다. C와 C++ 저장소는 더 다양한 빌드 시스템, 플래그, 래퍼, 프로젝트별 절차를 사용한다.

이 명령을 발견하지 못한 에이전트는 패치가 의미 있는 평가를 받기도 전에 실패 점수를 받을 수 있다. 반대로 신중하게 준비된 프롬프트는 설정 작업을 제거해 같은 모델이 훨씬 더 유능해 보이도록 만들 수 있다.

PoC 표현 방식도 큰 차이를 만들었다. 62개 Go 사례에서 에이전트에게 소스 수준 PoC를 보여주자 크래시 테스트 점수는 69.4%에서 95.2%로 올랐다. 개발자 테스트 성능은 41.9%에서 48.4%로 이동했다.

소스 하니스는 실행된 API와 문제 호출의 형태를 드러냈다. 이 맥락은 에이전트가 눈에 보이는 테스트에 맞추는 데 도움을 줬다. 그러나 유지보수자 지향 지표에서는 훨씬 작은 개선만 나타났다.

25개 C 및 C++ 사례에서는 불투명한 바이너리 또는 텍스트 입력을 노출해도 PoC 점수에 차이가 없었다. 92%로 유지됐다. 개발자 테스트 점수도 36%로 그대로였다.

두 벤치마크 구성 모두 에이전트에게 PoC를 제공한다고 사실대로 말할 수 있다. 하지만 에이전트에 동등한 정보를 주는 것은 아니다. 하나는 실행 의도를 드러내는 반면, 다른 하나는 의미를 추론해야 하는 입력 파일만 제공한다.

도구 접근은 더 직접적인 오염 위험을 초래한다. 과거 취약점에는 공개 이슈, 권고문, 업스트림 패치가 있는 경우가 많다. 웹 접근 권한이 있는 코딩 에이전트는 이슈 번호를 검색해 수용된 수정안을 가져올 수 있다.

논문은 에이전트가 답변을 작성하기 전에 웹 도구로 업스트림 패치를 찾은 사례를 기록한다. 또 다른 사례에서는 정제되지 않은 Git 기록을 통해 이전 수정안이 노출됐다. 두 사례 모두 성공적인 패치를 생성했지만, 어느 쪽도 독립적인 수정 능력을 명확히 측정하지는 못했다.

실제 개발자는 일상적으로 웹을 검색하고 저장소 기록을 검토한다. 이는 실무 환경에서 합리적인 행동이다. 문제가 되는 것은 벤치마크가 과거 작업에 대한 보조 없는 추론 능력을 측정한다고 주장할 때뿐이다.

따라서 평가는 의도한 능력을 명시해야 한다. 도구 사용 벤치마크는 검색을 허용하고 효과적인 검색·활용을 보상할 수 있다. 모델 추론 벤치마크는 답안 유출로부터 사례를 격리해야 한다.

인프라 오류는 반대 방향으로도 결과를 왜곡할 수 있다. 잘못된 권한은 숨겨진 정답을 노출하거나 정당한 빌드를 막을 수 있다. 시간 초과는 느린 프로젝트에 불이익을 줄 수 있으며, 테스트 파일 충돌은 올바른 패치를 실패로 표시할 수 있다.

연구진은 전체 실행에서 개별 프레임워크 문제가 사례의 약 5%~32%에 영향을 미쳤다고 관찰했다. 이 비율은 리더보드에서 두 순위를 가르는 점수 차이보다 클 수 있다.

실무적 결론은 모든 벤치마크 점수가 쓸모없다는 것이 아니다. 점수는 프롬프트, 도구, 소스 패키징, 실행 제한, 채점 파이프라인을 포함한 완전한 시스템에 속한다는 것이다.

진짜 경쟁은 벤치마크 성공과 유지보수자 수용 사이에 있다

핵심 쟁점은 더 이상 AI 에이전트가 그럴듯한 패치를 작성할 수 있는지가 아니라, 그 성공 신호가 실제 운영 환경의 승인 기준과 일치하는지 여부다.

AI 취약점 패치 공급업체는 간결한 성능 수치로 이득을 본다. 구매자 역시 모델을 선택하거나 보안 에이전트를 평가할 때 단순한 비교 기준을 원한다. 이러한 유인은 하나의 눈에 띄는 성공률을 내세운 리더보드를 부추긴다.

유지보수자의 기준은 그보다 불편하다. 변경 사항이 근본 원인을 해결하는지, 지원되는 동작을 보호하는지, 프로젝트 관례를 따르는지, 그리고 몇 달 뒤에도 이해할 수 있는지를 판단해야 한다.

Northwestern 데이터셋은 그 판단의 일부를 자동화된 평가에 반영하려 한다. 유지보수자가 작성한 테스트가 리뷰를 완전히 대체할 수는 없지만, 단순한 크래시 입력보다 더 많은 의도를 담고 있다.

다른 연구자들도 비슷한 방향으로 움직이고 있다. PatchBench 결과에 따르면 PoC만으로 검증할 경우 11개 에이전트 전반에서 해결률이 평균 1.83배 부풀려졌다. 이 벤치마크는 보안 재현, 단위 테스트, 출력 검사를 추가했다.

PatchBench는 암기 문제도 다뤘다. 승인된 수정이 보고된 크래시 스택 밖에 있는 취약점을 선택했다. 이어 과거 패치를 기억해 내는 이점을 줄이기 위해, 변경된 저장소 맥락에 취약점을 이식했다.

가장 강력한 에이전트들은 원래 PoC의 97% 이상을 통과했지만, 보안 및 의미론적 검증을 결합한 조건에서는 과제의 약 절반만 해결했다. 이 패턴은 Northwestern이 확인한 평가 격차와 매우 닮아 있다.

Berkeley 연구진은 엔드투엔드 벤치마크를 통해 더 낙관적이면서도 양립 가능한 결론에 도달했다. CyberGym-E2E는 139개 오픈소스 프로젝트의 취약점 920개를 포함하며, 발견·재현·패치를 함께 시험한다.

대상 취약점이 주어졌을 때 최고 구성은 사례의 약 80%를 수정했다. 에이전트가 먼저 문제를 발견해야 할 때 엔드투엔드 성능은 하락했다. 연구진은 또한 보고된 크래시만 막고 더 깊은 결함은 남겨 두는 피상적 패치를 관찰했다.

이 연구들이 하나의 보편적 순위를 제시하는 것은 아니다. 과제, 에이전트, 모델 세대, 정의가 서로 다르다. 하지만 함께 보면 단일 백분율로 전체 방어 워크플로를 나타낼 수 없는 이유를 보여 준다.

더 엄격한 기준이 과거 패치와 텍스트 수준에서 일치할 것을 요구해서는 안 된다. 소프트웨어 결함에는 여러 유효한 수정 방법이 있을 수 있다. 패치 유사성에 기반한 벤치마크는 다른 함수를 바꿨다는 이유만으로 더 깔끔한 대안을 거부할 수 있다.

동작 기반 평가는 더 나은 방향이다. 보고된 익스플로잇, 인접 입력, 지원되는 기능, 보안 속성, 프로젝트별 기대치를 시험해야 한다. 이런 요구 사항을 코드로 표현할 수 없는 경우에는 여전히 사람의 리뷰가 필요하다.

기업 팀도 구매 과정에서 같은 구분을 적용해야 한다. 공급업체의 패치 점수는 그 이면의 오라클, 환경, 도구 권한, 실패 범주 없이는 불완전하다.

유용한 질문은 구체적이다. 에이전트에 익스플로잇이 제공됐는가? 인터넷이나 Git 이력에 접근할 수 있었는가? 성공 판정에 유지보수자 테스트가 필요했는가? 파이프라인 오류는 잘못된 패치와 구분됐는가?

팀은 결과에 패치 회귀, 대체 익스플로잇 경로, 새로 도입된 약점이 포함되는지도 물어야 한다. 한 익스플로잇은 막았지만 다른 취약점을 노출하는 패치는 방어 가능한 성공으로 볼 수 없다.

이 기준은 Claude 취약점 패치와 모든 경쟁 시스템의 기준을 높인다. 또한 단순히 PoC 통과율을 높이는 것보다 모델 개발자에게 더 명확한 목표를 제공한다.

이 연구가 입증하는 것과 입증하지 않는 것

증거는 벤치마크 민감성을 보여 주지만, Claude 또는 모든 실제 운영 보안 워크플로의 보편적 실패율을 확립하지는 않는다.

이 논문은 2026년 10월의 arXiv 사전 공개 논문이다. 그 주장은 자율 패치 신뢰성에 대한 업계 전반의 최종 측정치가 아니라 연구 결과로 평가해야 한다.

112개 사례는 4개 언어 범주와 84개 프로젝트에 걸쳐 있어 분석에 유용한 다양성을 제공한다. 그러나 포함 조건으로 재현 가능한 빌드와 의미 있는 테스트를 포함한 업스트림 커밋이 요구됐다. 이 선정은 실제 운영 환경에서 발견되는 모든 취약점을 대표하지 않는다.

개발자 테스트는 PoC 전용 검사보다 강력하지만, 유지보수자 승인에 대한 불완전한 대리 지표이기도 하다. 프로젝트에 추가된 테스트는 선택된 의도된 동작을 포착할 뿐, 성능, 호환성, 가독성, 아키텍처 관련 우려를 모두 포착하지는 않는다.

생성된 패치는 과거 개발자 테스트에는 실패하면서도 여전히 방어 가능할 수 있다. 대체 수정안이 문서화되지 않은 동작을 의도적으로 바꾸거나 더 넓은 공격 표면을 차단할 수도 있다. 사람 유지보수자는 리뷰 후 그러한 절충을 받아들일 수 있다.

이 연구는 업스트림 수정에서 작성된 테스트를 사용함으로써 이러한 우려를 줄인다. 그렇다고 개별 불일치를 검토할 필요가 사라지는 것은 아니다. 실패한 테스트는 정렬 불일치를 보여 줄 뿐, 자동으로 위험한 패치를 뜻하지는 않는다.

과거 데이터는 또 다른 한계를 만든다. 공개 이슈, 권고문, 수정 사항이 모델 학습 데이터에 포함됐을 수 있다. 연구진도 암기가 절대적 성공률에 영향을 미칠 수 있음을 인정한다.

그럼에도 통제된 비교는 모델과 버그를 고정한 채 벤치마크 조건을 바꾸기 때문에 가치가 있다. 암기만으로는 프롬프트 세부 사항이나 오라클 선택이 측정 결과를 바꾸는 이유를 설명할 수 없다.

실험은 또한 특정 에이전트와 모델 조합을 사용했다. 통제된 테스트에서는 OpenCode와 Claude 모델을 짝지었고, 사례 연구에서는 Claude Code와 Sonnet 4.5를 짝지었다. 서로 다른 스캐폴드는 검색, 편집, 검증 동작을 다르게 만들 수 있다.

실제 운영 환경의 Claude 취약점 패치에는 조직별 테스트, 정적 분석, 퍼징, 코드 리뷰, 단계적 배포가 포함될 수 있다. 이러한 통제 장치는 학술 하니스가 실패한 출력으로 기록하는 문제를 포착할 수 있다.

반대도 마찬가지다. 실제 운영 저장소에는 불완전한 테스트, 문서화되지 않은 동작, 깨끗한 컨테이너 안에서 사용할 수 없는 의존성이 있을 수 있다. 실제 배포는 선별된 벤치마크보다 더 어려울 수 있다.

책임 있는 결론은 마케팅이나 일축 어느 쪽보다도 좁다. 이 데이터셋에서 Claude Opus 4.7은 이전 Claude 세대보다 실질적으로 개선됐다. 그러나 그 크래시 테스트 점수는 개발자 기준 결과를 여전히 29.5%포인트 과대평가했다.

보안 팀은 생성된 패치를 증거가 필요한 후보로 취급해야 한다. 이 연구는 멈춘 PoC와 통과한 기존 테스트 스위트만으로 무인 배포를 뒷받침하지 않는다.

AI 패치가 신뢰할 만해지고 있는지 보여 줄 세 가지 신호

이제 진전은 더 강력한 평가, 투명한 평가 파이프라인, 그리고 생성된 수정안이 독립적 검토를 견딘다는 실제 운영 증거에 달려 있다.

첫 번째 신호는 개발자 의도 또는 의미론적 테스트의 더 폭넓은 사용이다. 향후 모델 릴리스는 PoC 성공률과 승인된 프로그램 동작을 중심으로 설계된 테스트 성능을 모두 보고해야 한다.

격차가 줄어들면 모델이 근본 원인을 수정하는 법을 배우고 있다는 주장이 강화된다. 반대로 유지보수자 테스트 격차가 유지된 채 크래시 테스트 점수만 상승한다면 그 주장은 약화된다.

두 번째 신호는 벤치마크의 완전한 공개다. 평가자는 프롬프트, 도구 권한, 네트워크 접근, 소스 정제, 타임아웃, 테스트 적용 오류, 단계별 결과를 공개해야 한다.

에이전트가 빌드 지침, 읽을 수 있는 PoC, 웹 접근, 숨겨진 저장소 이력을 제공받을 때 점수가 달라질 수 있기 때문이다. 재현 가능한 산출물은 연구자가 모델의 진전과 하니스 지원을 구분할 수 있게 한다.

독립적인 노력은 더 넓은 방어 루프를 다루기 시작했다. Cyber Index 방법론은 정상 동작을 훼손하지 않으면서 저장소 감사, 취약점 발견, 재현, 패치를 결합한다.

세 번째 신호는 검토된 실제 운영 패치의 증거다. 조직은 생성된 수정안이 수정 없이 승인되는 비율, 유지보수자가 수정하는 비율, 거부되는 비율, 보안 회귀로 이어지는 비율을 추적해야 한다.

그 승인 퍼널은 통제된 스위트에서 억제된 크래시 수보다 더 중요하다. 자동화된 출력이 숨겨진 위험을 하류로 이전하지 않으면서 엔지니어링 작업을 줄이는지를 측정하기 때문이다.

즉시 활용을 위해 팀은 계층형 게이트를 도입할 수 있다. 익스플로잇이 멈추도록 요구하고, 기존 회귀 테스트를 실행하며, 경계 사례를 추가하고, 실용적인 범위에서 퍼징을 적용한 뒤 배포 전에 사람의 리뷰를 받아야 한다.

에이전트의 프롬프트, 도구 추적, 패치, 검증 결과도 보존해야 한다. 검색 가능한 엔지니어링 지식 베이스는 팀이 여러 저장소에서 반복되는 실패 패턴을 비교하는 데 도움이 될 수 있다.

구매자가 던져야 할 질문은 더 이상 AI 에이전트가 빨간 테스트를 녹색으로 바꿀 수 있는지가 아니다. 그 녹색 결과가 실제 운영 소프트웨어에 필요한 보안 속성, 지원되는 동작, 유지보수자 의도를 나타내는지다.

다음 Claude 취약점 패치 점수를 신뢰하기 전에, 평가자가 무엇을 볼 수 있었는지 물어야 한다. 그다음에는 무엇을 전혀 시험하지 않았는지도 물어야 한다.