AeonBox는 LLM이 정책을 판단하게 하는 대신, Liquid Types(정제 타입)로 에이전트 프로그램의 허용 행동을 검사하는 실험적 에이전트 하네스다. 비공개 저장소를 읽어 오염된(tainted) 세션은 공개 이슈를 만들 수 없도록 해 프롬프트 인젝션에 따른 데이터 유출 경로를 실행 전에 막는 것을 목표로 한다.
권한 승인만으로 부족한 이유
에이전트가 비공개 데이터 접근, 신뢰할 수 없는 웹 콘텐츠 읽기, 외부 전송 능력을 동시에 가지면 이른바 lethal trifecta 위험이 생긴다. 개별 명령 승인에는 사용자가 무뎌지고, LLM 기반 심사자는 확률적 판단이라 같은 공격에 속을 수 있다.
AeonBox의 관점은 “이 명령을 허용할까?”보다 “이전 행동 이후 이 행동이 논리적으로 가능한가?”다.
세션에 데이터 상태를 담는다
다음은 핵심 아이디어를 단순화한 형태다.
repoRead(session, private_repo) -> tainted session
createPublicIssue(untainted session, public_repo, body) -> issue비공개 저장소를 읽으면 세션의 상태가 tainted가 된다. 공개 이슈 생성 함수는 untainted 세션만 받도록 타입으로 선언하므로, 에이전트가 비공개 내용을 읽은 뒤 공개 이슈에 붙이는 프로그램은 컴파일되지 않는다. 선형 타입(linear type)은 오래된 세션 상태를 다시 쓰지 못하게 해 행동의 순서도 보존한다.
무엇이 다른가
| 접근 | 정책을 적용하는 시점 | 한계 |
|---|---|---|
| 도구 권한 | 호출 전 사용자 또는 정책 엔진 | 데이터가 어디서 왔는지 추적하기 어려움 |
| LLM 심사자 | 호출 전 모델 판단 | 확률적이고 우회 가능 |
| AeonBox 방식 | 생성된 계획의 타입 검사 | 모델링한 API·정책 범위 안에서만 보장 |
이는 범용 보안 해법이 아니다. 터미널 전체가 아니라 안전 제약을 선언한 GitHub SDK 같은 제한된 API 표면을 에이전트에 제공해야 하며, 잘못되거나 빠진 정책은 막지 못한다. 그래도 정보 흐름 제어를 에이전트 행동에 적용하는 구체적인 설계 예시가 된다.
적용 대상
- 비공개 코드·고객 데이터에 접근하는 개발 에이전트
- 읽기와 외부 게시를 함께 수행하는 자동화
- 단순 승인 팝업보다 강한 데이터 흐름 보증이 필요한 팀
관련 문서
- llm-guardrails — LLM 출력과 정책을 통제하는 가드레일 인프라
- ai-agent-security-tips-prompt-injection-3-hops — 다단계 프롬프트 인젝션 데이터 유출
- information-flow-control — 데이터 흐름을 기준으로 권한을 설계하는 보안 모델
참고 자료
- AeonBox: Logical Guardrails for Agents — Alcides Fonseca (2026-08-19)
- alcides/aeonbox — GitHub 공식 저장소