bdg9412/artex-ko-plus

★ 166⑂ 142

ARTEX 한국어판 ·AI 기반 침해사고 대응 기능 추가 (upstream: Autumn-27/ARTEX, AGPL-3.0)

Open on GitHub ↗

About bdg9412/artex-ko-plus

bdg9412/artex-ko-plus is an open-source project on GitHub, mainly written in Go. ARTEX 한국어판 ·AI 기반 침해사고 대응 기능 추가 (upstream: Autumn-27/ARTEX, AGPL-3.0) It currently holds 166 stars and 142 forks with 0 open issues, and was last pushed on an unknown date (repository created unknown).

Project Overview

AI Homed tracks it on the Today's Trending board, currently at rank #74 with 0 new stars today.

GitHub Repository Details

Repository bdg9412/artex-ko-plus · default branch - · size 0 KB · watchers 0 · source: GitHub REST API and repository README

README

AegisLoop: ARTEX 기반 공격·방어 검증

취약점 진단·독립 사건 조사·탐지 규칙 개선 평가를 연결하는 프로젝트

license: AGPL-3.0

ARTEX의 한국어판 artex-ko를 기반으로 확장했습니다. 기존 취약점 점검 기능과 Go·Next.js·PostgreSQL 구조를 유지하면서, 점검 이후의 탐지·차단 확인, 취약점 없이 시작하는 사건 조사와 탐지 규칙 개선 평가를 하나의 웹앱으로 연결합니다. 원본과 한국어판의 저작권 표시 및 AGPL-3.0 라이선스를 유지합니다. 기반 프로젝트의 중국어 문서와 영문 문서는 참고용으로 보존하며, 이 확장의 실행 방법은 아래 안내를 따릅니다.

실제 웹 화면

2026-10-11 현재 실행 중인 AegisLoop에서 직접 캡처한 화면입니다. 하나의 웹앱에서 통합 현황, Offensive, Defensive, Closed-loop로 이동합니다. 화면의 저장된 실습 기록은 새 설치에 포함되지 않습니다.

통합 현황

공격 진단·독립 사건 조사·탐지 개선의 진입점과 저장된 기록을 한 화면에서 확인합니다. 카드의 숫자는 작업·사건·평가 기록 수이며 탐지 성능 지표가 아닙니다.

AegisLoop 통합 현황: Offensive·Defensive·Closed-loop를 연결하는 최신 웹 화면

Offensive · 취약점 진단

기존 ARTEX의 작업·자산·취약점·트래픽과 모델 사용 현황을 유지했습니다. API · 소스 코드 진단에서는 사용자 API 주소를 탐색하거나 OpenAPI 명세·HAR·소스 ZIP을 등록해 Schemathesis·Semgrep으로 후보·근거를 수집하고, 후보별 AI 판정을 저장하며 남은 후보를 이어서 검토할 수 있습니다. crAPI·Benchmark도 예제 대상으로 선택할 수 있습니다. 환경 준비와 웹 사용법은 API · 소스 코드 진단 안내를 참고하세요. 아래는 별도 로컬 실습에서 저장한 진단 이력입니다.

Offensive 진단 현황: 작업·취약점·자산과 활동 기록

API · 소스 코드 진단 확장

Offensive → API · 소스 코드 진단에서 입력 방식을 선택합니다. 명세가 없어도 URL이나 실제 HAR 요청 기록으로 API 후보를 준비하고, 검사할 경로를 직접 고를 수 있습니다.

| 입력 | 검사 내용 | |---|---| | OpenAPI JSON/YAML | 선택한 GET/HEAD의 명세 기반 입력·응답 계약·서버 오류 검사 | | URL | 같은 출처·경로의 HTML·연결된 JavaScript에서 후보 발견 → 선택한 GET/HEAD 서버 오류 검사 | | HAR | 실제 요청 기록에서 경로 추출 → 선택한 GET/HEAD 서버 오류 검사 | | 소스 ZIP | Java·Python·JavaScript·TypeScript를 제한된 Semgrep 규칙으로 정적 분석 |

웹에서 명세·URL·HAR 입력 방식과 진단 주소를 선택

실제 crAPI 홈페이지에서 GET 후보 9개를 찾고, 그중 두 경로의 웹 진단을 확인했습니다. 아래 URL·HAR 실행은 무인증 요청이므로 각각 401 응답 2건과 인증 제한을 표시합니다. 별도 인증 검사에서는 같은 두 경로에서 200 응답을 확인했습니다. 소스 ZIP은 Benchmark Java 30파일에서 정적 후보 12건을 수집했습니다.

URL · HAR · 소스 ZIP 실제 결과 화면 보기 URL 탐색 후 선택한 두 API의 진단 결과 HAR 업로드 후 선택한 두 API의 진단 결과 Benchmark 소스 ZIP 30파일의 정적 분석 결과

URL·HAR는 요청 목록을 만드는 방식으로, 명세의 응답 계약을 추정하거나 API 전체를 발견하지는 않습니다. 후보는 확정 취약점이 아니며, 필요하면 후보별 AI 검토 · 이어하기로 저장된 근거를 검토합니다. 원본 HAR의 인증 헤더·쿠키·쿼리값·본문은 보관하거나 자동 재사용하지 않습니다. crAPI·Benchmark는 선택형 실습 대상으로 기본 설치에 필수는 아닙니다.

짧은 사용 순서 · 상세 안내 · URL·HAR 검증 기록 · 명세·소스 ZIP 검증 기록

후보별 검토는 한 건씩 판정을 저장하며 중지·새로고침 후에도 남은 후보를 이어갈 수 있습니다. 실제 crAPI 14건·Benchmark 소스 12건의 판정 저장과 이어하기를 검증 기록에 남겼습니다. 정적 판정과 실제 재현 성공은 구분합니다.

실제 API 후보별 판정 저장 완료

Defensive · 로그에서 시작하는 조사

취약점이 없어도 파일 또는 Splunk 로그에서 사건을 시작합니다. 로그 근거 준비 → 사건 저장 → AI 조사 시작 → 근거·실행 기록 확인 순서이며, 아래는 로그를 준비하는 입력 화면입니다.

Defensive 경보·침해 조사: 로그 근거부터 준비하는 최신 화면

Closed-loop · 실제 탐지 개선과 변형 재검증

별도 AWS Windows·Splunk 실습에서 PowerShell → 예약 작업 → 지연 실행을 검증했습니다. 공통 공격은 개선 전후 모두 탐지됐고 정상 업무 오탐은 1건 → 0건, 개선 후 별도 변형 공격도 탐지됐습니다. 아래 수치는 제한된 실습 표본의 판정 건수이며 운영 환경 전체의 정확도·오탐률을 의미하지 않습니다.

Closed-loop 실제 AWS 결과: 공통 공격 탐지 유지·정상 오탐 감소·독립 변형 탐지

실행·다중 로그·규칙 적용 상세 증적 · 전체 화면과 증적의 범위

이 프로젝트에서 할 수 있는 일

| 단계 | 동작 | 결과 | |---|---|---| | 취약점 점검 | 기존 ARTEX 에이전트가 허가된 대상을 점검 | 취약점과 재현 근거 | | API·소스 진단 | 명세·URL·HAR 또는 소스 ZIP 등록 → 대상·경로 선택 → Schemathesis·Semgrep 실행 | 요청·응답 또는 파일·줄 단위 후보, 근거·해시, 후보별 AI 판정 저장·이어하기 | | 방어 검증 | 취약점을 재검증하고 해당 실행의 감사·경보 파일 또는 Splunk 결과를 대조 | 탐지·차단 상태, 근거 부족과 확인할 원인, 개선 전후 비교 | | 침해 조사 | 파일 또는 Splunk로 과거 로그 근거를 준비한 뒤 AI 조사를 명시적으로 시작 | 가설·로그 조회·원문 확인·후속 계획, 관측/추정/자료 부족, 조사 이력과 원문 내보내기 | | 독립 Defensive 사건 | 취약점 없이 대상·기간을 지정하고 파일/Splunk 로그에서 사건 생성 | 불변 로그 근거와 타임라인, 같은 읽기 전용 Planner/Worker 조사 | | 실제 실행 루프 | 기존 취약점의 실제 ARTEX 재검증 → 파일/Splunk 근거 수집 → 후보 규칙 저장 → 새 검증 ID로 실제 재실행 | 실행별 기존 경보 판정, 같은 재실행 로그에서 기준·후보 규칙 비교, 규칙 revision·원본 해시·이력 | | 선택형 AWS Windows 루프 | PowerShell·예약 작업 체인과 정상 업무 실행 → 다중 로그·실제 경보 분석 → 규칙 개선 → 변형 재실행. 기존 Atomic 탐색도 지원 | 공통 표본의 탐지·오탐 전후 비교, 별도 변형 결과, 단계별 근거와 원본 내보내기 | | 로그 규칙 평가 | 개선용·평가용 라벨 로그를 분리하고 기준·후보 규칙을 오프라인 비교 | TP/FP/TN/FN·precision·recall·오탐률, 누락 필드와 평가 이력 |

웹앱 하나에서 통합 개요 → Offensive / Defensive / Closed-loop로 업무를 나눕니다. Closed-loop의 기본 실제 실행 루프 탭에서 사용자가 기준 공격과 새 재실행을 시작하고 근거를 수집합니다. 기존 로그 규칙 평가 탭도 유지합니다. 사용 순서·API·현재 한계와 소스 분석에서 연결 구조를 확인할 수 있습니다.

실제 경보와 후보 규칙의 그림자 일치는 별도 결과입니다. 그림자 평가는 실제 감사 로그에서 조건을 계산하며, SIEM 경보 발화나 정책 배포를 의미하지 않습니다. 실제 루프는 두 공격만으로 정확도·오탐률·MTTD·MTTR을 만들지 않습니다. 운영 SIEM 규칙·차단 정책의 자동 적용은 제공하지 않습니다. 선택형 AWS Windows 연결은 고정 실습 Splunk의 전용 규칙 실제 적용 경로를 별도로 제공하며, 일반 검색 연결의 권한은 유지합니다.

Splunk 없이 파일 업로드로 시작할 수 있습니다. 방어 검증은 재검증 UUID와 실행 시간에 연결된 로그를 사용합니다. 침해 조사는 UUID가 없는 과거 로그도 다루며, 사용자가 지정한 자산·기간·경로 안에서 읽기 전용으로 조사합니다.

로그 근거 준비와 기초 분석에는 LLM이 필요하지 않습니다. 취약점 점검·재검증과 AI 조사에는 사용자가 설정한 LLM 연결이 필요하며, AI 조사 시작 시 선택된 취약점 근거와 로그 발췌가 그 공급자에 전송됩니다. 에이전트가 조사 범위를 넓히거나 운영 탐지 규칙·차단 정책을 자동 배포하지는 않습니다.

처음 실행하기

Docker Desktop 또는 Docker Engine과 Compose v2가 필요합니다. 현재 소스를 컨테이너 안에서 빌드하므로 호스트에 Go·Node.js를 따로 설치할 필요가 없습니다. 최초 빌드에는 이미지·의존성 다운로드를 위한 인터넷 연결이 필요합니다.

아래 URL을 이 저장소의 GitHub URL로 바꿉니다.

git clone https://github.com/YOUR_ACCOUNT/YOUR_REPOSITORY.git artex-defense
cd artex-defense
./scripts/local-start.sh

1. 로컬 초기 설정에서 본인의 관리자 비밀번호를 만듭니다. 공유 로그인이나 기본 비밀번호는 제공하지 않습니다. 2. 취약점 점검이나 AI 조사를 사용할 때 시스템 → LLM 설정에 본인의 연결을 설정합니다. 저장소에는 공급자 API 키가 포함되지 않습니다. 3. 본인이 소유하거나 점검 허가를 받은 대상을 등록합니다. 기본 배포는 ARTEX와 PostgreSQL만 시작하며, 실습 대상 앱이나 Splunk를 설치하지 않습니다.

스크립트가 DB 비밀번호와 로그인 서명 키를 로컬에서 생성합니다. 앱은 http://localhost:8787에 열리며, 앱·기록 프록시 포트는 기본적으로 127.0.0.1에만 공개됩니다. 이미 사용 중인 포트 변경과 운영 명령은 로컬 실행 안내에 있습니다.

이 확장의 기본 진입점은 ./scripts/local-start.sh입니다. 루트의 기존 docker-compose.yml이나 install.sh는 상류 설치 경로를 보존한 파일이며, 현재 확장을 실행하는 기본 명령으로 사용하지 않습니다.

실행과 테스트

# 현재 소스 빌드 및 실행
./scripts/local-start.sh

별도 임시 PostgreSQL과 모의 모델·Splunk로 확장 통합 테스트

./scripts/local-test.sh

실제 앱만 중지: 로컬 데이터는 보존

docker compose --env-file .env.local -f docker-compose.local.yml stop

통합 테스트는 artex-purple-test 프로젝트의 임시 DB를 사용하며 종료 후 테스트 컨테이너를 정리합니다. 실제 LLM 키나 운영 Splunk 계정 없이 실행할 수 있습니다. local-start.sh는 UI 정적 빌드와 Go 빌드를 수행합니다. 배포·새 체크아웃 검증 절차에는 비밀·운영 데이터 제외 기준과 재현 명령을 정리했습니다.

사용 안내와 실제 실습 증적

최신 통합 UI와 AWS 전후 비교는 위 실제 웹 화면에서 볼 수 있습니다. 아래는 기능 확장 과정에서 남긴 이전 방어 검증·침해 조사 화면입니다. 전체 캡처와 판정 한계는 증적 안내에 정리했습니다.
이전 방어 검증·침해 조사 화면 보기

파일로 방어 검증: 감사 2건·경보 2건에서 탐지 기록을 확인했지만, 차단 여부는 근거 부족으로 판단 불가입니다.

파일 근거 기반 방어 검증의 탐지·차단 판정

로그 근거부터 준비: 파일 또는 Splunk로 대상·기간·경로를 지정하고 저장한 뒤 AI 조사를 시작합니다.

침해 조사의 로그 근거 준비 화면

실제 AI 실행 이력: 모델 호출 2회 뒤 사용자 중지한 실행입니다. 로그 조회는 0회이며, 아래 가설은 분석 완료 결과가 아닙니다.

사용자 중지된 AI 조사와 보존된 가설

공개 증적의 Juice Shop은 기능을 확인하기 위해 별도로 띄운 실습 대상이며 제품의 설치 구성에 포함되지 않습니다. AWS 역시 임시 시연·증적을 위한 별도 환경이며 장기 서비스 인프라 구축이 프로젝트의 목표는 아닙니다. 운영 DB, 원본 로그, LLM 키, JWT 키는 배포하지 않습니다. 모의 Splunk 테스트는 연결·범위 제한·증거 보존을 검증합니다. 실제 기업 Splunk 연결이나 탐지 정확도를 입증한 것은 아닙니다. 공개한 실제 AI 조사 이력은 사용자 중지 또는 실행 한도 도달 상태이므로 완주·침해 확정 성공 사례로 제시하지 않습니다.

기반 프로젝트 문서

아래는 기존 ARTEX 한국어판의 설명과 참조 문서입니다. 링크와 주요 절 제목을 보존했습니다. 현지화 이전의 데모 화면, 모델별 평가, 상류 설치 방식은 이 확장의 검증 결과나 권장 실행 경로와 구분해서 읽어 주세요.

---

## 🚨 보안·오남용 경고: 반드시 먼저 읽어 주세요
> 이 저장소는 권한을 받은 환경에서, 방어와 탐지 역량을 기르기 위한 목적으로만 쓰도록 공개합니다.
> ARTEX 는 사람이 거의 개입하지 않아도 정찰부터 침투, 자료 반출까지 공격 과정을 스스로 수행할 만큼 강력한 자율 공격 도구입니다. 그만큼 오남용이 일으키는 피해도 큽니다. 2026년 10월 국내 여러 언론은 원본 ARTEX 가 국내 금융기관을 상대로 한 개인정보 유출 공격에 사용된 정황이 조사 당국에 포착됐다고 보도했으며, 관련 수사가 진행 중입니다. 이 한국어판을 공개하는 목적은 공격을 돕는 데 있지 않습니다. 방어하는 쪽이 이런 자율 AI 공격의 작동 원리를 이해하고, 탐지하고 차단하는 역량을 갖추도록 돕는 데 목적이 있습니다.
> - 허가 없는 사용은 그 자체로 범죄가 됩니다. 자신이 소유하거나 서면으로 명시적 허가를 받은 대상이 아니라면, 어떤 시스템에도 스캐닝·탐지·익스플로잇을 실행하지 마십시오. 대한민국에서 권한 없이 정보통신망에 침입하는 행위는 정보통신망법 위반이고, 개인정보가 결부되면 개인정보보호법도 함께 적용됩니다.
- 실제 서비스나 타인의 자산을 대상으로 삼지 마십시오. 학습과 연구, 그리고 본인이 소유한 로컬 격리 환경(OWASP Juice Shop·DVWA 처럼 의도적으로 취약하게 만든 환경)에서만 검증하십시오.
- 방어하는 관점으로 읽으십시오. 이 저장소는 자율 AI 공격의 탐지 시그니처와 하드닝 체크리스트 같은 방어·탐지 자료를 함께 정리해 나갑니다. → 자율 AI 공격 방어·탐지 가이드
> 이 경고와 아래 사용 제한·면책에 동의하지 않는다면, 이 저장소를 내려받거나 사용하지 마십시오.

---

기반 한국어판은 중국산 오픈소스 프로젝트 Autumn-27/ARTEX(AGPL-3.0)를 한국 사용자와 팀이 그대로 쓸 수 있도록 현지화한 판본입니다. 에이전트의 판단 성능을 보존하기 위해 내부 추론 프롬프트는 원문을 유지하고, 사용자에게 보이는 산출물(탐지 결과·요약·리포트·대화 응답)만 한국어로 강제합니다. 아래 "왜 한국어판인가"에서 방침을 설명합니다.

ARTEX 는 LLM 이 조종하는 여러 에이전트가 스스로 목표를 쪼개고, 실제 도구를 실행하고, 발견한 자산과 취약점을 그래프에 쌓아 가며 침투 테스트 과정을 자율적으로 끌고 가는 시스템입니다. Go 단일 바이너리 하나에 Next.js 프런트엔드가 내장되어 있고, 데이터는 PostgreSQL 에 저장됩니다.

---

⚠️ 먼저 읽어 주세요 — 사용 범위와 국내법 고지

ARTEX 는 자신이 소유하거나 서면으로 명시적 허가를 받은 대상에 대해서만 사용할 수 있습니다. 허가 범위를 벗어난 스캐닝·탐지·익스플로잇은 그 자체로 불법이 될 수 있습니다.

자세한 라이선스·사용 제한·면책은 아래 라이선스와 면책 절에 있습니다. 이 도구를 사용하는 것만으로 사용자는 그 조건에 동의한 것으로 봅니다.

---

왜 한국어판인가

원본 ARTEX 는 프롬프트·UI·문서가 모두 중국어로 되어 있어, 국내 사용자가 결과를 읽고 팀과 공유하기가 번거로웠습니다. 이 한국어판은 다음을 목표로 합니다.

현지화의 경계와 설계 방침은 저장소의 작업 문서에 더 자세히 적혀 있습니다. 상류(upstream) 저장소의 변경을 대조하기 쉽도록 원본 중국어 문서는 README.zh.md 로 보존합니다.

---

화면 미리 보기

아래 세 화면은 한국어화를 마친 실제 UI 입니다. 로컬 격리 샌드박스에서 뽑은 데모 데이터이고, 대상은 전부 가상의 acme.com 과 사설 대역입니다.

https://github.com/bdg9412/artex-ko-plus/blob/HEAD/대시보드: 전체 개요 화면
대시보드: 활성 작업·확인된 취약점·자산 노드·LLM 토큰 소비와 활동 흐름을 한 화면에서 봅니다.
이 대시보드 화면은 라벨을 현지화하기 전에 뽑은 데모 캡처라, 'LLM Token 소비' 카드의 데이터 원본 이름이 아직 코드 식별자 llm_usage 로 보입니다. 현재 빌드는 같은 자리를 신버전 「계량 원장」·구버전 「활동 통계」 로 표시합니다.

https://github.com/bdg9412/artex-ko-plus/blob/HEAD/취약점 목록 화면
취약점: 심각도·상태·자산·소속 작업으로 탐지 결과를 집계하고 CSV 로 내보냅니다.
취약점 제목은 모델이 생성한 값이라, 대상 앱과 기술 용어를 따라 영어가 섞일 수 있습니다(모델 선택과 출력 언어 참조). 제목 아래 설명과 화면 전체는 한국어로 나옵니다.

https://github.com/bdg9412/artex-ko-plus/blob/HEAD/사람 개입 대화 화면
대화: 자율 실행 중에 사람이 끼어들어 힌트를 주고, 에이전트가 공격 체인을 한국어로 요약합니다.

원본(중국어 UI) 전체 화면은 README.zh.md 에서 볼 수 있습니다.

---

빠른 시작 (Docker Compose)

이 확장은 현재 소스를 직접 빌드하는 로컬 Compose 구성을 기본으로 사용합니다.

./scripts/local-start.sh

처음 실행했다면 http://localhost:8787/setup/에서 관리자 비밀번호를 설정합니다. 처음 실행하기와 로컬 실행 안내를 따르세요.

기존 docker-compose.yml은 상류 autumn27/artex 이미지에 의존하는 참고 구성입니다. 소스 확장 기능을 실행하거나 배포할 때는 Dockerfile.local·docker-compose.local.yml을 사용하는 위 스크립트를 선택합니다. 상류 이미지·릴리스의 현재 배포 여부를 이 프로젝트가 보장하지는 않습니다.

그 밖의 설치 방법

상류 설치 스크립트(./install.sh)와 사전 컴파일 바이너리는 기반 프로젝트의 설치 방식입니다. 이 확장의 배포·실습에서는 위의 ./scripts/local-start.sh를 사용하세요. 상류 안내는 README.zh.md의 "安装" 절에 보존합니다.

아래 소스 수동 컴파일은 Go·Node.js·PostgreSQL을 직접 관리하는 개발자를 위한 참고 절차입니다. 기본 Docker 경로와 달리 데이터베이스 연결과 실행 도구를 별도로 준비해야 합니다. 

  cd web && npm ci && npm run build:static && cd ..   # 1) 프런트엔드 정적 빌드
  rm -rf server/webui/dist && mkdir -p server/webui/dist && cp -a web/out/. server/webui/dist/   # 2) 내장 디렉터리로 동기화(재빌드 시 중첩 방지)
  CGO_ENABLED=0 go build -tags embedui -o artex ./cmd/artex   # 3) 프런트 내장 컴파일
  ./start.sh                                          # → http://localhost:8787

1) 단계의 npm ci 는 빌드에 필요한 devDependencies(예: @tailwindcss/postcss)를 함께 설치합니다. 셸에 NODE_ENV=production 이 설정돼 있으면 npm ci 가 devDependencies 를 건너뛰어 빌드가 Error: Cannot find module '@tailwindcss/postcss' 로 실패하므로, 이때는 npm ci --include=dev 로 받으십시오.
실행은 ./artex 를 직접 돌리지 말고 start.sh(Windows 는 start.bat)로 하십시오. 이 스크립트는 종료 코드에 따라 프로그램을 다시 띄우는 감시자이고, UI 의 "원클릭 업데이트"도 이 스크립트가 처리합니다.

---

설정

데이터베이스(config.json, 또는 환경 변수 ARTEX_PG_DSN 로 덮어쓰기):

{
  "database": {
    "host": "127.0.0.1", "port": 5432,
    "user": "artex", "password": "yourpass",
    "dbname": "artex", "sslmode": "disable"
  }
}

LLM: export ANTHROPIC_API_KEY=sk-...(또는 OPENAI_API_KEY), 혹은 UI 의 "LLM 설정" 페이지에서 입력합니다. 선택 환경 변수로 ARTEX_LLM_PROVIDER / ARTEX_LLM_MODEL / ARTEX_LLM_BASE_URL / ARTEX_LLM_PROXY 를 둘 수 있습니다. 국산·오픈 모델을 쓰려면 OpenAI 호환 ARTEX_LLM_BASE_URL 을 지정하십시오.

동시성: 작업마다 돌리는 worker 에이전트 수는 "시스템 설정"에서 조정합니다(기본값 3).

자주 쓰는 인자: ./start.sh -addr :8787 -proxy :8788 에서 -addr 는 프런트엔드와 API 를 열고, -proxy 는 트래픽 기록 프록시 포트입니다.

모델 선택과 출력 언어

산출물의 한국어화는 하드 코딩된 상한이 아니라 프롬프트 지시(agent/prompt.go 의 langDirective())로 유도합니다. 그래서 출력이 한국어로 유지되는 정도는 모델의 역량과 역할, 맥락에 따라 달라집니다.

OpenAI 호환 경로의 토큰 상한 함정. gpt-4o 처럼 OpenAI 계열 모델은 응답 토큰 상한이 16,384 입니다. 그런데 OpenAI 호환 요청에는 기본적으로 더 큰 출력 상한(32,768)이 실려, 그대로 두면 모든 호출이 400 (max_tokens is too large) 으로 실패합니다. 이때는 LLM 설정에서 해당 프로파일의 max_tokens 를 16,384 이하로 지정하십시오. Anthropic 계열(기본 모델 claude-opus-4-8 등)은 32,768 을 허용하므로 이 함정에 걸리지 않습니다.

리버스 프록시 배포 (HTTPS / 443 만 개방)

프런트엔드와 API/SSE 모두 같은 백엔드 포트(기본 :8787)가 제공하고, 실시간 활동 스트림은 기본적으로 동일 출처(same-origin) 로 연결합니다. 따라서 NEXT_PUBLIC_SSE_BASE 를 따로 설정할 필요 없이, 공개망에는 443 만 열고 8787 은 내부망에 두면 됩니다.

SSE 는 장시간 연결로 이벤트를 계속 밀어 주므로, 리버스 프록시에서 버퍼링을 반드시 꺼야 합니다. 끄지 않으면 브라우저가 연결은 되지만 이벤트를 못 받습니다(활동 스트림이 계속 로딩 상태로 보임). Nginx 설정 예시는 README.zh.md에 있습니다.

---

시스템 아키텍처

ARTEX 는 LLM 멀티 에이전트가 구동하는 자율 침투 시스템입니다. Go 단일 백엔드(Next.js 프런트엔드 내장)에 PostgreSQL 을 쓰고, 에이전트 기능은 norma SDK 가 제공합니다. 핵심은 이중 그래프 구조와, 그것을 둘러싼 두 가지 자율성 장치(worker 사이의 과정 단위 정보 교환, planner 의 다중 라운드 공유 todolist)입니다.

전체 계층

flowchart TB
  subgraph FE["프런트엔드 Next.js (go:embed 단일 바이너리 내장)"]
    UI["대시보드 · 작업 · 자산 · 커버리지 그래프 · 트래픽 · 워크스페이스 · 시스템 설정"]
  end
  subgraph SRV["server (Go net/http)"]
    API["REST /api/*　JWT 인증　SSE"]
    ENG["engine 스케줄링 루프"]
    MGR["Manager　작업/엔진/store 생명주기"]
  end
  subgraph AG["agent (norma SDK)"]
    GO["goals　목표 분해 + 범위 추출"]
    PL["planner　계획자 (유일한 의도 생성자)"]
    WK["worker　실행자 ×N"]
    MA["mainagent　사람 개입"]
  end
  subgraph DB["PostgreSQL"]
    AGRAPH["자산 그래프　assets / companies / task_scope"]
    EGRAPH["탐색 그래프　exploration_nodes / anchors / activity"]
  end
  subgraph SUB["지원 서브시스템"]
    PROXY["트래픽 기록 프록시　MITM + CA 기록"]
    GUARD["guard / intercept　도구 승인 게이트"]
    ENR["enrich　DNS / HTTP 비동기 보강"]
    EXT["MCP · skills · memory · report"]
  end

UI -->|HTTP| API
  API --> MGR --> ENG
  ENG --> PL
  ENG --> WK
  API --> MA
  API --> GO
  PL --> DB
  WK --> DB
  MA --> DB
  GO --> DB
  WK -->|"Bash / HTTP 전 과정 기록"| PROXY
  WK --> GUARD
  WK --> ENR
  PL -.-> EXT
  WK -.-> EXT
  MA -.-> EXT

이중 그래프 구조: 탐색 그래프 + 자산 그래프

시스템은 "대상이 무엇인가"와 "어디까지 테스트했는가"를 서로 독립적이면서 앵커로 연결되는 두 그래프로 나눕니다. 

flowchart LR
  subgraph EG["탐색 그래프 (작업마다 독립 · 진행 체인)"]
    direction TB
    G["goal 목표"]
    I1["intent 의도 A"]
    F1["fact 사실"]
    I2["intent 의도 B"]
    FD["finding 취약점"]
    G -->|spawns| I1
    I1 -->|yields| F1
    F1 -->|derived_from| I2
    I2 -->|proves| FD
  end
  subgraph AG["자산 그래프 (전역 공유 · 진실 저장소)"]
    direction TB
    RD["root_domain"]
    SD["subdomain"]
    SV["service"]
    EP["endpoint"]
    RD --> SD --> SV --> EP
  end
  I1 -. anchor .-> SD
  F1 -. anchor .-> SV
  I2 -. anchor .-> EP
  FD -. anchor .-> EP

역할 분담: planner 는 탐색 그래프의 상황을 읽고 목표를 판정하며, 아직 커버하지 못한 새 방향이 있을 때만 의도를 frontier 에 보냅니다. worker 는 의도 하나를 맡아 실제 도구로 실행하고, 새 자산·사실·취약점을 두 그래프에 써 넣은 뒤 멈춥니다. 자산 그래프는 공유 사실이고, 탐색 그래프는 작업마다의 진행 체인입니다.

엔진과 의도 생명주기 (한 번의 탐색 폐곡선)

엔진은 이벤트 구동 폐곡선입니다. 그래프가 바뀌면 planner 를 깨우고, planner 가 의도를 보내면 worker 가 그 의도를 맡아 실행한 뒤 결과를 써 넣으며, 그 쓰기가 다시 다음 라운드를 촉발합니다. 이 순환은 목표가 증명될 때(prove_goal)까지 이어집니다.

sequenceDiagram
  autonumber
  participant EV as 그래프 변경 debounce
  participant P as planner
  participant FR as frontier 의도 큐
  participant W as worker
  participant PX as 기록 프록시
  participant DB as 이중 그래프 + activity

EV-->>P: 깨우기
  P->>DB: 상황 읽기(graph_overview 선취 + coverage/scope)
  P->>FR: 의도 0..N 개 배정(asset_ids 포함)
  Note over P,FR: 대부분의 깨우기는 0 개 배정(새 방향이 없으면 종료)
  W->>FR: claimNext 로 의도 하나 수령
  W->>DB: 의도의 asset_ids 원본 자산을 초기 정보로 가져옴
  W->>PX: 실제 도구 실행(Kali / Bash / HTTP)
  PX-->>W: 응답(전 과정 기록 + CA 검증)
  W->>DB: fact / asset / finding + 단계별 activity 기록
  DB-->>EV: 그래프 변경
  EV-->>P: 다시 깨우기(폐곡선)

worker 사이의 과정 단위 정보 교환

깊은 탐색에서는 값진 관찰(어떤 오류, 어떤 응답 조각, 숨은 파라미터)이 한 worker 의 실행 과정에서 나오지만 정식 fact 로는 기록되지 않는 경우가 많습니다. 중복 노동을 피하고 뒤따르는 worker 가 앞선 관찰 위에 설 수 있도록, worker 는 다른 work 의 과정을 검색하는 능력을 갖습니다.

이렇게 탐색 그래프에 아직 대응하는 fact 가 없어도 뒤따르는 worker 가 남의 과정 속 관찰을 재사용합니다. 정보는 worker 사이를 "실행 과정" 단위로 흐르되, 경계는 그대로입니다(각 worker 는 여전히 자기가 맡은 의도 하나만 수행).

flowchart LR
  WA["worker A (의도 #12)"] -->|"단계별 activity"| ACT[("탐색 그래프 · activity 과정 라이브러리")]
  WB["worker B (의도 #34)"] -->|"단계별 activity"| ACT
  WC["worker C (의도 #56)"] ==>|"① search_all_worker_traces(q)"| ACT
  ACT ==>|"② A/B 의 단계 명중 (자기 제외)"| WC
  WC ==>|"③ get_worker_trace(intent_id, step_ids)"| ACT
  ACT ==>|"④ 전체 과정 내용 반환"| WC

planner 의 다중 라운드 공유 todolist → 안정적인 공격 체인

실제 공격 체인은 앞뒤로 의존하는 여러 단계의 순서(예: 주입점 발견 → 인증 정보 획득 → 측면 이동 → 권한 상승)인 경우가 많아, 이것을 한 번에 병렬로 내려보내면 뒤엉킵니다. 그래서 planner 는 작업마다 보존되고 깨우기를 가로질러 공유되는 계획 할 일 목록(todolist) 을 가집니다. 

flowchart TB
  subgraph TODO["공유 todolist (작업마다 보존 · 깨우기를 가로질러 상주)"]
    direction LR
    T1["1 주입점 발견　[완료]"]
    T2["2 인증 정보 획득　[진행 중]"]
    T3["3 측면 이동　[선행 대기]"]
    T4["4 권한 상승　[선행 대기]"]
    T1 -. 선행 충족 .-> T2 -.-> T3 -.-> T4
  end
  R1["1 라운드 깨우기　의도① 배정"] --> T1
  R2["2 라운드 (①이 fact 산출)　의도② 배정"] --> T2
  R3["3 라운드 (②가 fact 산출)　의도③ 배정"] --> T3

이로써 공격 체인은 "이벤트 구동 + 무상태 세션" 환경에서도 안정적으로 진행되고, 중복되지 않고, 순서가 어긋나지 않습니다. 이것이 ARTEX 가 여러 단계의 공격 체인을 자율로 완주하는 핵심입니다.

---

방어·탐지 자료

이 저장소는 자율 AI 공격을 방어하는 쪽이 그 작동 원리를 이해하고 탐지·차단 역량을 기르도록 돕는 것을 목표로 합니다. 위 아키텍처에서 본 ARTEX 의 동작을 방어자 관점으로 뒤집어, 무엇을 관측하고 어디를 조여야 하는지를 한국어로 정리한 가이드를 둡니다.

GitHub Stars & Activity

166Stars
142Forks
0Open issues
GoLanguage

GitHub Popularity

GitHub stars166
Forks142
Open issues0
Primary languageGo
License-
Stars gained today0
Created-
Last pushed-

Trending History

Daily boardrank #74 · ▲ 0 stars

Related AI Projects

1

ollama / ollama

Go★ 182,878⑂ 18,237▲ 138 stars
→
2

JuliusBrussee / caveman

Go★ 111,210⑂ 0
→
3

lharries / whatsapp-mcp

Go★ 6,554⑂ 1,393▲ 24 stars
→
4

Armur-Ai / Pentest-Swarm-AI

Go★ 2,857⑂ 528▲ 49 stars
→
5

Bennettxai / FounderOS

Go★ 1,079⑂ 307▲ 22 stars
→
6

HEXUXIU / M365-Copilot2API

Go★ 555⑂ 189▲ 14 stars
→
7

aindeev / agent-chrome-relay

Go★ 256⑂ 3
→
8

openclaw / openclaw

TypeScript★ 391,781⑂ 82,377▲ 182 stars
→

More AI Rankings