오늘 한 일 한눈에 보기4일차까지는 "로그가 잘 쌓인다"를 눈으로 확인했습니다. 5일차는 그 확인을 명령 하나로 반복 가능한 테스트로 바꾼 날입니다. 시나리오를 컨테이너에서 실행하고, 쌓인 로그를 기대값과 비교해서 PASS/FAIL을 내는 러너와 판정기를 만들었고, 그 테스트 자체가 믿을 만한지까지 검증했습니다.구분내용만든 것tools/judge.sh(판정기), run_scenarios.sh(러너), tools/test_judge.sh, tools/test_runner.sh(테스트의 테스트), tools/mock/(가짜 로더와 가짜 agent-run), tools/fixtures/(실제 로그 표본 7종), scenarios/s00_benign, scenarios/s99_dummy_block기존 코드 변경..

오늘의 목표: 판정이 나온 뒤의 "처리 계층"3일차까지는 이벤트를 보고 판정을 내리는 데까지 만들었다. 4일차는 그 판정을 받아서 처리하는 쪽을 만든다. 탐지 로직은 여전히 더미이고, 결과물은 판정이 어디로 가서 무엇을 일으키는지다.3일차까지의 문제판정이 나오면 화면에 JSON 한 줄을 출력하는 것이 전부였다.탐지기 → 판정 → 화면 출력 (끝)화면에 찍히고 사라지니 나중에 검토할 기록이 없다.여러 세션의 판정이 한 화면에 섞여서 어느 세션의 것인지 구분이 안 된다.BLOCK이 나와도 아무 대응이 없다.4일차의 목표탐지기 → 판정 → [판정 수집기] → 세션별 로그 파일에 기록 └→ BLOCK 이면 → kill 스텁 호출만드는 것역할이유판정 수집기 (handle_ve..

오늘의 목표: 출력만 하던 로더를 "판정하는 구조"로2일차까지는 로더가 ring buffer에서 이벤트를 받아 JSON으로 찍기만 했다. 3일차의 목표는 이 사이에 디스패처와 탐지기를 끼워 넣어, 이벤트가 "위험한가"를 판단하는 구조의 뼈대를 만드는 것이다. 탐지 로직은 없고(더미 탐지기 2개뿐), 새 탐지기를 파일 하나로 추가할 수 있는 구조와 그것을 검증하는 단위 테스트까지가 범위다.구조의 변화원래 흐름은 "이벤트 → 출력"이었다.이벤트 → handle_event() → JSON 출력3일차 이후에는 이렇게 된다.이벤트 → handle_event() → 디스패처 → 탐지기들 → 판정 → (출력 / 로그 / kill switch)단계하는 일3일차 구현handle_event()ring buffer에서 이벤..

목표와 환경 점검2일차의 목표는 agent-run -- ls를 실행했을 때 세션 cgroup의 execve가 ring buffer를 거쳐 유저스페이스에 JSON으로 출력되고, 호스트 셸에서 친 명령은 잡히지 않는 것이다. 탐지 로직은 없고 관측만 한다. 구현은 mycontainer_run.c가 이미 C와 libbpf를 쓰고 있으니 C + libbpf skeleton으로 정했다.환경 점검작업을 시작하기 전에 도구와 커널 기능을 확인했고 전부 통과였다.확인결과의미clang, llvm, libbpf-dev, bpftool, 커널 헤더이미 설치됨빌드 도구 준비 완료커널 버전7.0.0-27-generic최신 커널이라 이후 주차에 필요한 기능도 쓸 가능성이 높음/sys/kernel/btf/vmlinux존재CO-RE..

프로젝트와 이번 글의 범위이 글은 "AI 코딩 에이전트 실행 샌드박스" 프로젝트의 v0.1 1주차 중 첫날 기록이고, 오늘의 결과물은 agent-run 서브커맨드와 "세션"이라는 실행 단위다. eBPF는 다음 글로 미루고, 이번에는 컨테이너 실행 코드를 읽고 고치는 데 집중했다.프로젝트가 풀려는 문제2026년 상반기에 Cursor, Codex, Gemini CLI 같은 AI 코딩 에이전트에서 프롬프트 인젝션으로 셸 안전장치를 우회하는 취약점이 연달아 공개됐다. 이 프로젝트는 그 원인을 개별 구현 실수가 아니라 "안전장치가 에이전트와 같은 신뢰 영역 안에 있다"는 구조적 문제로 본다. 그래서 판정을 에이전트의 출력이 닿지 않는 OS 커널(eBPF)에서 규칙 기반으로 수행하는 경량 샌드박스를 만든다.새로운 ..

1. 장애 상황 (Incident)현상: 멀티모달 인덱싱 파이프라인에서 비동기 AI Worker들이 각각의 태스크 완료 이벤트를 동시에 발행할 때, 최종 단계로 진입하기 위한 Fan-In 상태 전이(모든 하위 작업 완료 판정)가 간헐적으로 누락되는 현상을 확인했다.연쇄 효과: 하위 비동기 작업들이 모두 성공적으로 끝났음에도 불구하고, 전체 파이프라인의 최종 상태가 '완료'로 갱신되지 않고 '진행 중' 상태로 멈추는 시스템 교착(Stall)이 발생했다.2. 원인 분석 (Root Cause Analysis)문제의 근본 원인은 비동기 환경에서 트랜잭션 격리 수준과 JPA 영속성 컨텍스트의 특성이 결합하며 발생한 TOCTOU(Time-of-Check-Time-of-Use) 레이스 컨디션 및 설계상 취약점이었다...