▲

Project Glasswing: Mythos가 보여준 것

 (blog.cloudflare.com)
2P by GN⁺ 3시간전 | ★ favorite | 댓글 2개
  • Mythos Preview는 Cloudflare의 50개 이상 저장소에서 개별 버그 탐지를 넘어 여러 원시 요소를 엮어 익스플로잇 체인을 구성함
  • 의심 버그 탐지에 그치지 않고 트리거 코드 작성, 임시 컴파일·실행, 실패 후 가설 수정까지 반복해 동작 증명을 만들어냄
  • 정당한 취약점 연구에서도 자발적 거부가 나타났지만, 문맥과 표현에 따라 달라져 안전 경계로 쓰기엔 일관성이 부족했음
  • 범용 코딩 에이전트는 큰 저장소 커버리지와 병렬 탐색에 한계가 있어, Cloudflare는 좁은 작업을 병렬 실행하는 하네스를 구축함
  • 보안 팀에는 더 빠른 스캔과 패치만으로 부족하며, 버그가 있어도 악용·도달이 어렵게 만드는 아키텍처가 중요해짐

Mythos Preview가 바꾼 취약점 연구 방식

  • Cloudflare는 최근 몇 달 동안 자체 인프라에서 보안 중심 LLM을 테스트했고, Anthropic의 Mythos Preview를 Project Glasswing의 일부로 받아 50개 이상의 자체 저장소에 적용함
  • Mythos Preview는 기존 범용 프런티어 모델의 단순 개선판이라기보다, 취약점 연구의 다른 단계를 수행하는 새 도구에 가까웠음
  • 핵심 변화는 개별 버그를 나열하는 데서 끝나지 않고 여러 공격 원시 요소를 결합해 익스플로잇 체인을 구성한다는 데 있음
    • 실제 공격은 하나의 버그만 쓰기보다 use-after-free를 임의 읽기·쓰기 원시 요소로 바꾸고, 제어 흐름을 탈취하고, ROP 체인으로 시스템 제어를 얻는 식으로 이어짐
    • Mythos Preview는 이런 원시 요소들을 조합해 동작하는 증명으로 연결했으며, 자동 스캐너보다 숙련 연구자의 작업에 가까운 추론을 수행함
  • 또 다른 변화는 의심되는 버그를 찾은 뒤 동작 증명까지 직접 만드는 능력임
    • 트리거 코드를 작성하고, 임시 환경에서 컴파일한 뒤 실행함
    • 예상대로 동작하면 증명이 되고, 실패하면 실패 내용을 읽고 가설을 조정한 뒤 다시 시도함
    • 작동하는 증명이 없는 결함은 추측에 머물지만, Mythos Preview는 이 간극을 스스로 줄였음
  • 같은 하네스에서 다른 프런티어 모델들도 일부 기반 버그를 찾았고 예상보다 멀리 추론한 경우가 있었지만, 여러 조각을 실제 체인으로 완성하는 단계에서 차이가 났음
  • Mythos Preview는 전통적으로 백로그에 낮은 심각도로 남았을 버그들을 하나의 더 심각한 익스플로잇으로 연결할 수 있었음

정당한 취약점 연구에서도 발생한 모델 거부

  • Project Glasswing에 제공된 Mythos Preview에는 Opus 4.7이나 GPT-5.5 같은 일반 제공 모델의 추가 안전장치가 포함되지 않았음
  • 그럼에도 모델은 특정 요청에 자발적으로 반발했고, 취약점 탐지에 유용했던 사이버 능력과 함께 발현적 가드레일도 드러남
  • 자발적 거부는 일관적이지 않았음
    • 같은 작업도 표현 방식이나 문맥이 달라지면 완전히 다른 결과가 나올 수 있었음
    • 한 프로젝트에 대한 취약점 연구를 처음에는 거부했다가, 프로젝트 환경의 무관한 변경 이후 같은 코드에 대한 같은 연구를 수락함
    • 코드베이스에서 심각한 메모리 버그 여러 개를 찾고 확인한 뒤, 데모 익스플로잇 작성을 거부한 경우도 있었음
    • 같은 요청도 모델의 확률적 특성 때문에 실행마다 다른 결과를 낼 수 있었음
  • 자발적 거부와 가드레일은 실제로 존재하지만, 그 자체만으로 완전한 안전 경계가 되기에는 충분히 일관적이지 않았음
  • 유능한 사이버 프런티어 모델을 일반 제공하려면 Project Glasswing 같은 통제된 연구 환경 밖에서도 적절히 쓸 수 있도록 추가 안전장치가 필요함

신호와 잡음 문제

  • 보안 취약점 선별에서 가장 어려운 일은 어떤 버그가 실제이고, 악용 가능하며, 지금 고쳐야 하는지 결정하는 것임
  • 이 문제는 AI 이전에도 어려웠고, AI 취약점 스캐너와 AI 생성 코드가 이를 더 악화시켰으며, Cloudflare는 여러 사후 검증 단계를 구축함

  • 프로그래밍 언어

    • C와 C++는 직접 메모리 제어를 제공하며, 버퍼 오버플로와 범위 밖 읽기·쓰기 같은 버그 부류를 만듦
    • Rust 같은 메모리 안전 언어는 이런 부류를 컴파일 시점에 제거함
    • 메모리 안전하지 않은 언어로 작성된 프로젝트에서 일관되게 더 많은 오탐이 나타났음

  • 모델 편향

    • 좋은 인간 연구자는 무엇을 찾았고 얼마나 확신하는지 알려주지만, 모델은 코드에 버그가 있든 없든 결과를 만들어내는 경향이 있음
    • 결과는 “possibly”, “potentially”, “could in theory” 같은 표현으로 완화되어 돌아오며, 이런 추측성 결과가 확실한 결과보다 훨씬 많았음
    • 탐색 도구로서는 합리적인 편향이지만, 선별 큐에서는 모든 추측성 결과가 사람의 주의와 토큰을 소모하고 수천 개로 누적되면 비용이 커짐
    • Mythos Preview는 여러 취약점을 별개로 보고하는 대신 동작하는 PoC로 결합하는 원시 요소 체인 능력에서 뚜렷한 개선을 보임
    • PoC가 포함된 결과는 바로 조치 가능한 결과에 가까워 “이게 실제인가”를 확인하는 시간을 크게 줄여줌
    • Cloudflare의 하네스는 더 많이 보고해 덜 놓치도록 의도적으로 조정되어 잡음도 많지만, Mythos Preview의 출력은 완화된 표현이 적고 재현 단계가 더 명확해 수정 또는 기각 결정에 필요한 작업을 줄였음

범용 코딩 에이전트를 저장소에 바로 적용하는 방식의 한계

  • AI 보조 취약점 연구 초기에는 범용 코딩 에이전트에 임의 저장소를 주고 취약점을 찾게 하는 방식이 자연스러운 출발점이었음
  • 이 방식은 결과를 만들어내지만, 실제 코드베이스를 의미 있게 커버하고 가치 있는 결과를 찾는 데는 적합하지 않았음

  • 문맥

    • 코딩 에이전트는 기능 구현, 버그 수정, 리팩터링처럼 하나의 집중된 작업 흐름에 맞춰져 있음
    • 취약점 연구는 단일 복잡 기능, 보안 경계 전환, 명령 주입처럼 좁은 대상을 깊게 조사하고 이를 코드베이스 전체에서 수천 번 반복하는 좁고 병렬적인 작업에 가까움
    • 하위 에이전트를 쓰더라도 10만 줄 저장소에 대한 단일 에이전트 세션은 모델 문맥 창이 차고 압축이 시작되기 전, 유용한 방식으로 표면의 0.1% 정도만 커버할 수 있음
    • 압축 과정에서 중요했을 수 있는 이전 결과가 버려질 가능성도 있음

  • 처리량

    • 단일 스트림 에이전트는 한 번에 하나의 작업만 수행함
    • 실제 코드베이스에는 여러 구성 요소에 대한 많은 가설을 동시에 적용하고, 흥미로운 지점이 나오면 더 넓게 분기할 능력이 필요함
    • 연구자가 이미 단서를 갖고 있고 두 번째 검토자가 필요할 때는 코딩 에이전트가 수동 조사에 적합함
    • 높은 커버리지를 달성하는 도구로는 부적합해, Cloudflare는 Mythos Preview 주변에 하네스를 구축하는 쪽으로 전환함

하네스가 해결한 문제

  • 대규모 실행 경험은 전체 실행을 관리하는 하네스가 필요하다는 결론으로 이어짐

  • 좁은 범위가 더 나은 결과를 만듦

    • “이 저장소에서 취약점을 찾아라”는 요청은 모델을 헤매게 만듦
    • “이 특정 함수에서 명령 주입을 보라, 위에는 이 신뢰 경계가 있고, 여기 아키텍처 문서와 이 영역의 기존 커버리지가 있다”는 식의 요청은 실제 연구자의 작업 방식에 더 가까운 결과를 냄

  • 적대적 검토가 잡음을 줄임

    • 초기 결과와 큐 사이에 두 번째 에이전트를 배치하면 첫 번째 에이전트가 자기 검토에서 놓칠 잡음을 많이 잡아냄
    • 두 번째 에이전트는 다른 프롬프트와 다른 모델을 쓰며, 자체 결과를 생성할 권한은 없음
    • 한 에이전트에게 조심하라고 말하는 것보다 두 에이전트를 의도적으로 불일치 상태에 두는 방식이 훨씬 효과적이었음

  • 체인을 에이전트별로 나누면 추론이 좋아짐

    • “이 코드에 버그가 있는가”와 “공격자가 시스템 외부에서 실제로 이 버그에 도달할 수 있는가”는 서로 다른 질문임
    • 두 질문을 분리하면 각 질문이 더 좁아지고, 모델은 각각에서 더 나은 성능을 냄

  • 병렬의 좁은 작업이 하나의 포괄적 에이전트를 이김

    • 많은 에이전트가 좁게 정의된 질문을 처리하고 이후 결과를 중복 제거할 때 커버리지가 좋아짐
    • 하나의 에이전트에게 포괄성을 요구하는 방식보다 효과적이었음
    • Cloudflare는 Mythos Preview를 사용해 기존 하네스를 그 강점에 맞게 확장·조정·개선함

Cloudflare의 취약점 발견 하네스

  • 이 하네스는 Cloudflare의 런타임, 엣지 데이터 경로, 프로토콜 스택, 제어 평면, 의존하는 오픈소스 프로젝트의 실제 코드를 스캔하는 데 사용됨

  • Recon

    • 에이전트가 저장소를 위에서부터 읽고, 각 하위 시스템을 맡는 하위 에이전트로 분기함
    • 빌드 명령, 신뢰 경계, 진입점, 예상 공격 표면을 담은 아키텍처 문서를 생성함
    • 다음 단계에 넘길 초기 작업 큐도 만들며, 모든 후속 에이전트에 공유 문맥을 제공해 모델이 헤매는 문제를 줄임

  • Hunt

    • 각 작업은 하나의 공격 부류와 범위 힌트로 구성됨
    • 실제 버그를 찾는 헌터 에이전트들이 보통 약 50개씩 동시에 실행되고, 각 헌터는 몇 개의 탐색 하위 에이전트로 다시 분기함
    • 각 헌터는 작업별 임시 디렉터리에서 PoC 코드를 컴파일하고 실행하는 도구에 접근함
    • 대부분의 작업은 하나의 포괄적 에이전트가 아니라 많은 좁은 작업의 병렬 실행으로 이뤄짐

  • Validate

    • 독립 에이전트가 코드를 다시 읽고 원래 결과를 반증하려고 시도함
    • 다른 프롬프트를 사용하며, 자체적으로 새로운 결과를 낼 수 없음
    • 헌터가 자기 작업을 검토할 때 놓칠 의미 있는 비율의 잡음을 잡아냄

  • Gapfill

    • 헌터가 건드렸지만 충분히 커버하지 못한 영역을 표시함
    • 해당 영역은 다른 패스를 위해 다시 큐에 들어감
    • 모델이 이미 성공한 공격 부류 쪽으로 기울어지는 경향을 상쇄함

  • Dedupe

    • 같은 근본 원인을 공유하는 결과를 하나의 레코드로 합침
    • 변형 분석은 기능이지, 중복으로 큐를 부풀리는 방식이 아님

  • Trace

    • 공유 라이브러리에서 확인된 각 결과에 대해 트레이서 에이전트가 소비자 저장소별로 하나씩 분기함
    • 교차 저장소 심볼 인덱스를 사용해 공격자 제어 입력이 시스템 외부에서 실제로 버그에 도달하는지 판단함
    • “결함이 있다”를 “도달 가능한 취약점이 있다”로 바꾸는 가장 중요한 단계였음

  • Feedback

    • 도달 가능한 추적 결과가 해당 버그가 실제로 노출되는 소비자 저장소의 새 헌트 작업이 됨
    • 실행될수록 파이프라인이 개선되는 루프를 닫음

  • Report

    • 에이전트가 사전 정의된 스키마에 맞춰 구조화된 보고서를 작성함
    • 스키마 검증 오류를 스스로 수정하고 ingest API에 제출함
    • 출력은 자유 형식 산문이 아니라 질의 가능한 데이터가 됨

보안 팀에 주는 의미

  • Mythos Preview를 본 다른 보안 리더들은 더 빠르게 스캔하고 더 빠르게 패치해 대응 주기를 압축하려 했음
  • Cloudflare가 대화한 팀 중 하나 이상은 CVE 공개부터 프로덕션 패치까지 2시간 SLA로 운영하고 있었음
  • 공격자 타임라인이 짧아지면 방어자 타임라인도 짧아져야 하지만, 속도만으로는 충분하지 않음
  • 패치를 더 빠르게 한다고 해서 패치를 만들어내는 파이프라인의 형태가 바뀌지는 않음
    • 회귀 테스트가 하루 걸린다면 회귀 테스트를 건너뛰지 않고 2시간 SLA에 도달할 수 없음
    • 회귀 테스트를 건너뛰며 배포한 버그는 원래 고치려던 버그보다 더 나쁠 수 있음
    • 모델이 직접 패치를 작성하게 했을 때 원래 버그는 고쳤지만 코드가 의존하던 다른 부분을 조용히 깨뜨린 패치가 일부 배포된 일이 있었음
  • 더 어려운 질문은 취약점 주변 아키텍처를 어떻게 설계할 것인가임
    • 버그가 존재하더라도 공격자가 악용하기 어렵게 만들어야 함
    • 취약점 공개와 패치 사이의 간격이 덜 중요해지도록 만들어야 함
    • 애플리케이션 앞단에서 버그 도달을 차단하는 방어가 필요함
    • 코드의 한 부분 결함이 공격자에게 다른 부분 접근 권한을 주지 않도록 애플리케이션을 설계해야 함
    • 개별 팀 배포를 기다리지 않고 코드가 실행되는 모든 위치에 동시에 수정 사항을 배포할 수 있어야 함
  • 같은 능력은 양면성을 가짐
    • 자체 코드의 버그를 찾는 능력은 잘못된 손에 들어가면 인터넷상의 모든 애플리케이션에 대한 공격도 가속할 수 있음
    • Cloudflare는 수백만 개 애플리케이션 앞단에 있으며, 위의 아키텍처 원칙은 고객을 대신해 적용하도록 제품이 만들어진 원칙이라고 밝힘
  • Mythos Preview 연구는 통제된 환경에서 Cloudflare 자체 코드를 대상으로 수행됐고, 발견된 모든 취약점은 Cloudflare의 공식 취약점 관리 프로세스에 따라 선별·검증됐으며 필요한 경우 수정됨

함께 보면 좋은 글 β

▲
crawler 3시간전  [-]

curl처럼 무슨 오류를 고쳤는지 분석한 레포트인 줄 알았는데 그냥 쌩 홍보글이군요?
클라우드플레어도 ai 에이전트 전용 paywall이나 요약 엔드포인트나 만들면서 hype 하더니 맛이 갔네요

답변달기
▲
GN⁺ 3시간전  [-]
Hacker News 의견들

  • “다른 종류의 일을 하는 다른 종류의 도구라서 이전 모델과 깔끔한 사과 대 사과 비교가 어렵다”는 게 무슨 뜻인지 모르겠음
    다른 종류의 도구라고 해놓고, 정작 사용 방식은 다른 모델과 똑같이 설명함. 평균적인 Cloudflare 블로그보다 훨씬 별로였고, 체이닝과 예시 만들기를 핵심으로 짚었던 Mythos 발표를 되풀이한 느낌이 강함

    • 정성적으로 다른 능력이 있어서 특정 보안 작업을 이 모델로 해볼 가치가 커졌다는 뜻이지, 인간-AI 상호작용 모델이 바뀌었다는 뜻은 아닌 것 같음
      모두가 하듯 하네스를 붙여 쓰는 건 맞고, 모델에 하네스를 주는 일반적인 방식은 앞으로도 크게 안 바뀔 듯함. 사람도 어떤 일을 하려면 하네스가 필요할 때가 있음
    • 나도 이걸 해석하려고 했음
      좋게 보면 아직 NDA 때문에 정확히 뭐가 다른지 일부러 흐리게 말하는 걸 수도 있음
    • “평균적인 Cloudflare 블로그보다 훨씬 별로”라니, 그 평균을 언제 냈는지 궁금함
      요즘 Cloudflare 산출물은 거의 다 AI 냄새가 강함
    • 일반 블로그 글이 아니라 숨은 광고라서 다르게 들리는 듯함
    • “모델 자체에 새로 생긴 가드레일이 있어서 합법적인 보안 연구 요청에도 가끔 반발한다. 하지만 우리가 확인한 바로는 이런 자연발생적 거부는 일관적이지 않다. 같은 작업도 다르게 표현하거나 다른 맥락으로 제시하면 아래 예시처럼 완전히 다른 결과가 나올 수 있다”는 부분은 새로웠음
      보안 연구용으로 설계되고 전문가에게만 열리는 모델이 합법적인 요청을 거부한다는 게 의외임

  • 더 구체적인 숫자와 놀랄 만한 결과를 기대했는데, 그냥 균형 잡힌 홍보 글처럼 보이고 아마 LLM으로 쓴 것 같음

  • 진짜 질문은 이 글을 쓴 게 Mythos인지 Opus인지임
    “왜 중요한가” 같은 문구는 사실 중요하지 않음. 기업 블로그가 원래 한 명의 필자 목소리로 쓰이는 경우가 드물긴 했지만, 큰 조직들마저 블로그를 LLM에 외주 주는 모습을 보는 건 흥미로움

    • “탐색 도구로서는 합리적인 편향이다. 분류 대기열에는 파괴적인 편향이다...” 같은 문장 구조는 확실히 AI 문체처럼 보임
      “왜 중요한가”는 이제 “AI 출력물이 학습 데이터의 일부가 된다”로 격상하고 싶음. 언젠가는 다듬어진 AI식 장황한 문체가 표준이 되고, 이전 세대가 아니면 구분하기 어려워질 듯함. Usenet의 몇몇 면을 그리워하는 것과 비슷함
    • 뭔가에 충분히 비꼬기만 하면 그 실체적 내용까지 사라진다고 생각하는 모습이 흥미로움
      총구를 들여다보면서 총 광고지가 어떤 종이에 인쇄됐는지 농담하는 것 같음
    • 그냥 큰 조직이 아니라 Anthropic임. 이 회사의 핵심 메시지는 AI가 이제 진짜 일을 할 수 있다는 것이니, 자기들도 그에 맞게 행동하지 않으면 이상함
      그래서 Claude Code에 이상한 버그가 많고, 환불 처리했다고 지원팀이 말했지만 실제로는 안 되는 일도 생기는 듯함
    • Cloudflare 블로그는 트랜스포머가 등장하기 훨씬 전부터 여러 해 동안 훌륭했음
    • 완전히 AI가 썼다기보다는 AI가 편집한 글에 더 가까워 보임. 아니면 두 번째 패스에 꽤 좋은 인간화 도구를 쓰고 있거나

  • 이 작업을 대규모로 돌려서 얻었다는 “네 가지 교훈”이 웃겼음. 네 개 중 세 개가 사실상 똑같고 너무 당연했음
    요약하면 “취약점을 찾아라”보다 구체적이고 좁은 요청이 더 잘 먹힌다는 것인데, 당연한 얘기임. 그래도 적대적 검토는 전혀 새롭지는 않고 HN에서도 많이 다뤄졌지만, 적어도 흥미롭고 구분되는 부분이라고 봄. 내 워크플로에 더 많이 넣어봐야겠고, 코딩이 아닌 작업에도 도움이 될 수 있을 듯함
    https://blog.cloudflare.com/cyber-frontier-models/#what-a-ha...

  • “Mythos Preview에 대한 보안 리더들의 가장 큰 반응은 속도였다. 더 빨리 스캔하고, 더 빨리 패치하고, 대응 주기를 압축하는 것. 우리가 이야기한 팀 중 둘 이상은 CVE 공개부터 프로덕션 패치까지 2시간 SLA로 운영 중이다 [...] 회귀 테스트가 하루 걸린다면, 이를 건너뛰지 않고는 2시간 SLA에 도달할 수 없고, 회귀 테스트를 건너뛰면 원래 패치하려던 버그보다 더 나쁜 버그를 배포하기 쉽다”는 부분이 인상적임
    시간이 지나면 이런 모델들이 코드를 병합하기 전에 악용 가능성 테스트를 수행해서 기본적으로 더 안전한 코드를 생성할 수 있을지 궁금함

    • 잘 모르겠지만, AI가 그다지 잘하지 못하는 걸 보고도 해결책이 AI를 더 쓰는 것이라고 결론 내리는 흐름은 늘 이상하게 느껴짐
    • 아니면 그렇게 안 되고, 그들*이 서비스 회사나 파트너 네트워크를 통해 Mythos와 후속 모델 접근권을 팔면서 프리미엄 요금을 받을 수도 있음
      *여기서 그들이란 OpenAI도 같은 방향으로 가는 것 같으니 모든 기반 모델 제공사를 뜻함

  • 좋은 건 알겠는데, 발견한 취약점 중 가장 심각한 것이 어느 정도였는지가 궁금함
    아마 공개하고 싶지 않겠지만, 그게 정말 가장 흥미롭고 중요한 부분임

    • 회의론에 동참하고 싶긴 하지만, 글 첫머리에서 아주 분명하게 말하고 있음. 이건 계단식 변화임
      많은 사람이 Mythos를 심리전 캠페인처럼 보지만, 그런 회의론은 잘 이해가 안 됨. 대부분 공개적으로 사용할 수 없는 것에 대한 일반적인 불신에서 오는 듯함. 몇몇 Anthropic 직원이 Mythos를 범용 모델 개선이라고 설명했지만 아직 널리 뒷받침되지는 않았으니 그 부분만은 계속 회의적으로 봄. 보안 연구 영역에 한해서는 이 서사를 받아들일 수 있음
    • 익스플로잇은 보통 여러 작은 취약점을 체이닝해서 만든다고 구체적으로 설명하고 있음
      그렇게 보면 취약점을 닫는 것은 익스플로잇을 발견하는 것과 같지 않음. 대신 작은 틈을 덜 남겨서, 동작하는 익스플로잇을 조립하기 점점 더 어렵게 만드는 일에 가까움
    • 이제는 이 모델이 훨씬 더 창의적이고 더 오래 에이전트식으로 실행될 수 있다는 쪽으로 생각이 굳었음
      그래서 “하드 스킬”이 압도적으로 좋아지지 않았더라도, 그것들을 더 효과적으로 조합할 수 있음. 지금도 이런 취약점 상당수는 Opus로 식별 가능하지만, 복잡한 익스플로잇으로 이끌려면 여전히 사람, 그것도 숙련자가 중간에 필요함. 사람이 끼지 않아도 된다면 평균적인 사람이 익스플로잇을 찾아 활용하기가 훨씬 쉬워짐
    • Palo Alto Networks가 지난주 방화벽용 여러 CVE 패치를 공개했는데, 거의 전부 Mythos를 포함한 프런티어 모델 접근에서 나온 것임
      https://security.paloaltonetworks.com
    • Anthropic의 새 제품 대부분이 아무도 안 쓰는 AI 도구라서 계속 이런 저품질 글을 올릴 것 같음. 최근에 사람도 많이 해고해서 좋은 필자가 더는 없을 수도 있음

  • 좋긴 한데, 실제로 보안 취약점을 몇 개나 찾았는지, 그중 진짜는 몇 개였고 오탐은 몇 개였는지 데이터를 왜 공유하지 않는지 모르겠음

    • 나도 이걸 기다리고 있음
      공개 전에 처리하고 싶다는 건 이해하지만, 데이터가 거의 없는 주장을 계속 보게 되면 사람들이 어떻게 회의적이지 않길 기대하는지 모르겠음. 보안 전문가라면 말 그대로 회의적으로 보는 대가를 받는 사람들임

  • 다른 모델과 비교했는지 궁금함. 이 글의 많은 부분은 보안에 AI를 처음 적용해보고 패턴 매칭 기계의 터무니없는 성능에 놀란 것처럼 들림
    결국 패턴을 맞추는 기계니까, 당연함

  • 반발하는 부분이 꽤 웃김. 직접 써보니 진행하기 전에 내가 해당 코드베이스에 합법적으로 접근할 권한이 있다는 증거를 요구해야 했음

  • “Mythos Preview에서 바뀐 점은, 전통적으로 백로그에서 보이지 않게 남아 있던 낮은 심각도 버그들을 모델이 하나의 더 심각한 익스플로잇으로 체이닝할 수 있게 됐다는 것이다”라는 말은 Mythos에 대한 다른 독립 테스트와도 어느 정도 맞아 보임
    긴 에이전트 작업에서 매우 잘했고, 아마 그걸 목표로 학습했을 것임. 그러려면 컨텍스트 창 안에서 느슨하게 관련된 주제들 사이의 주변적인 연결을 찾아낼 수 있어야 함
    [1] 주로 https://www.aisi.gov.uk/blog/our-evaluation-of-claude-mythos...를 말하는 것임

답변달기