에이전트 보안은 상태 머신 문제입니다: Codex 보안 스레드가 놓친 것¶
빠른 답변: 이번 주 최대 AI 코딩 스레드 — Codex 보안 논의 — 는 추천 500개 이상과 댓글 200개 이상을 모았고, 조언의 대부분은 프롬프트 인젝션과 샌드박싱에 집중했습니다. 그것들도 중요하지만, 일상적인 에이전트 워크플로에서 실제로 문제가 되는 실패 모드는 상태 머신 문제입니다: 활성화 상태가 갈라진 채 남는 크래시, 같은 토큰을 소비하는 두 동시 호출, 스키마 검증을 통과하는 자리표시자 증거. AIOS v5.4.0은 정확히 이 세 가지 수정을 담았습니다 — write-ahead 활성화 트랜잭션, 스토어 파일 락, 엄격한 evidence-ref 검증이 있는 타입 아티팩트 스키마.
모두가 이야기하는 스레드¶
Codex 보안 스레드는 이번 주 Hacker News 정상을 차지하며 수백 개의 댓글이 달렸습니다. 프롬프트 인젝션, 탈취(exfiltration), 샌드박스 경계에 대한 건전한 논의였습니다. 동시에 불완전하기도 했습니다: 사람들이 일상적인 에이전트 작업에서 실제로 맞닥뜨리는 공격은 좀처럼 특이하지 않습니다. 보안 결과를 수반하는 평범한 신뢰성 실패입니다:
- 상태 쓰기 도중 크래시. 워크플로는 전진했다고 믿고, 디스크의 파일은 그렇지 않다고 말합니다. 재시작하면 에이전트는 단계를 두 번 실행하거나 조용히 건너뜁니다.
- 같은 토큰을 소비하는 두 동시 호출. 재시도와 예약 실행이 경쟁합니다; 둘 다 단계를 소유했다고 생각하고, 워크플로는 한 계획에서 두 번 전진합니다.
- 실제처럼 보이지만 실제가 아닌 증거. 증거 필드의
TODO문자열이 타입 없는 스키마를 통과하고, 결코 검증되지 않은 주장으로 계획이 종료됩니다.
이 중 어느 것도 프롬프트 인젝션이 아닙니다. 모두 에이전트가 실행되는 상태 머신을 손상시킵니다 — 상태 손상이야말로 "검증했습니다"가 "실제로는 실행된 적이 없다"로 변하는 방식입니다.
상태 무결성이 보안 경계인 이유¶
에이전트 워크플로를 상태 머신으로 생각하세요: 계획 → 작업 → 증거 → 검증 → 완료. 모든 전이가 상태를 씁니다. 그 쓰기가 원자적이지 않고 검증되지 않으면, 머신은 동시에 두 곳에 있을 수 있습니다:
- 크래시 후 갈라진 상태 — 워크플로 로그는 한 가지를, 프로젝션은 다른 것을 말하고, 다음 실행은 잘못된 복사본으로 결정을 내립니다.
- 동시성 아래 토큰 이중 소비 — 두 호출이 모두 "현재 토큰 = 3"을 읽고 둘 다 "지금 4번 토큰"을 쓰며, 계획의 한 단계는 조용히 건너뛰고 다른 단계는 두 번 실행됩니다.
- 실제로 받아들여진 자리표시자 증거 — 모든 문자열을 허용하는 스키마는
TODO: verify this가 작업 완료의 증거가 되게 합니다.
프롬프트 인젝션은 모델을 속이려 합니다. 상태 손상은 프로세스를 속입니다 — 그리고 완료를 승인하는 것은 프로세스입니다.
v5.4.0이 실제로 무엇을 하는가¶
AIOS는 Claude Code, Codex, Gemini CLI, OpenCode, Grok Build 위의 로컬 퍼스트 워크플로 레이어입니다. v5.4.0은 상태 머신을 직접 강화했습니다:
Write-ahead 활성화 트랜잭션¶
Workflow와 Activation 프로젝션은 이제 write-ahead 트랜잭션(.aios/workflow-activations/transactions/)을 통해 씁니다. 쓰기는 원자적입니다; 불완전한 트랜잭션은 재시작 시 자동으로 roll-forward되고; 읽기는 두 프로젝션 사이의 일관성을 검증하고 어느 쪽이 우연히 더 새로운지 신뢰하는 대신 fail-closed(stale-activation-projection) 처리합니다.
토큰 전진을 위한 스토어 파일 락¶
파일 락이 Command 토큰 전진을 직렬화합니다. 동시 호출은 이제 같은 토큰을 조용히 이중 소비하는 대신 AIOS_REX_STORE_BUSY를 받습니다 — 재시도와 예약 실행은 경쟁할 수 있지만 단계를 이기는 쪽은 하나뿐입니다.
타입 아티팩트 스키마와 엄격한 증거 참조¶
Wayfinder와 Planning 아티팩트에는 이제 타입 스키마가 있습니다(wayfinder-artifact.mjs, planning-artifact.mjs): 부분적이거나 차단된 아티팩트는 Decision Ticket이나 Next Slice를 주장할 수 없고, Parallel Group은 그룹 간에 유일해야 합니다. 증거 참조는 프로토콜 접두사(artifact:, receipt:, …)를 가져야 하며 TODO/TBD/자리표시자 값을 거부합니다 — 그래서 머신은 검증되지 않은 주장으로 계획을 닫기를 거부합니다.
이미 존재하던 레이어¶
상태 무결성은 새로운 강화이고, 주변 게이트는 이미 있었습니다:
- Privacy Guard는 모델 소비 전에 민감한 읽기를 마스킹합니다 (
aios privacy read --file ..., 엄격 모드는aios privacy status). - 검증 게이트는 "계획됨"과 "검증됨"을 분리합니다:
verification-before-completion은 계획이 닫히기 전에 실제 증거를 요구합니다. - 적응형 워크플로 정책은 작은 변경을
guarded(편집 게이트 + 집중 검증)로 유지하고, 위험한 다단계 작업을 지속된 소유권과 증거를 가진planned로 승격합니다.
안전한 시작 순서¶
aios init --all
aios doctor --native --verbose
라우트 매트릭스와 검증 게이트는 워크플로 정책 문서, 상태가 시스템을 통해 흐르는 방식은 아키텍처 가이드, 민감한 파일 읽기의 안전한 방법은 Privacy Guard 사례를 읽으세요.
FAQ¶
프롬프트 인젝션이 진짜 위협이 아닌가요?¶
실제 위협이고 샌드박싱도 중요합니다. 하지만 에이전트를 도입하는 대부분의 팀은 먼저 상태 무결성 실패를 맞닥뜨립니다. 그 실패는 조용하고 반복적이기 때문입니다. 보안 논의에는 둘 다 포함되어야 합니다: 모델은 속일 수 있고, 프로세스는 손상될 수 있습니다.
내 코딩 클라이언트가 내부적으로 처리하지 않나요?¶
클라이언트는 자기 세션 상태를 처리합니다. 워크플로 레이어 — 계획, 활성화, 증거, 검증 — 는 클라이언트 밖에 살아 있고, 그래서 자기만의 트랜잭션 상태가 필요한 것입니다. v5.4.0이 크래시에 안전하게 만든 부분이 바로 그것입니다.
"fail closed"가 나에게 무엇을 의미하나요?¶
두 프로젝션이 불일치하면 시스템은 추측으로 진행하는 대신 멈추고 stale-activation-projection을 보고합니다. 나중에 단계가 두 번 실행되었거나 아예 실행되지 않았다는 것을 발견하는 대신 트랜잭션을 명시적으로 복구합니다.
구현 세부 사항은 어디에 있나요?¶
Changelog에 릴리스별 v5.4.0 강화가 정리되어 있고, 릴리스 게시물 Workflow Iteration v2.1이 닫히고 있는 세 종류의 조용한 실패를 설명합니다.
다음 보안 헤드라인도 여전히 프롬프트에 관한 것일 것입니다. 일주일을 날려먹게 하는 실패는 상태 머신을 조용히 두 번 전진시킨 그 실패일 것입니다.