프로젝트 한눈에 보기
- 문제: 에이전트가 파일·도구·외부 API를 다루면서 신원, 시크릿, 외부 전송, 감사 경계가 분리되어 있었습니다.
- 역할: 위협 모델 정의, 보안 실행 경로 설계, SDK·컨트롤 플레인 구현, 실패 조건 검증을 수행했습니다.
- 핵심 원칙: AI는 위험을 높일 수 있지만 허용 권한을 만들 수 없고, 보안 구성요소가 실패하면 실행 경로가 닫혀야 합니다.
- 검증 결과: 교차 테넌트 접근, 불일치 토큰, egress 판정 장애, 비밀 형태 로그, 감사 레코드 변조를 모두 거부하거나 탐지했습니다.
왜 만들었나
AI 에이전트는 답변만 생성하지 않습니다. 파일을 읽고, 도구를 실행하고, 외부 API로 데이터를 보내며, 다른 에이전트와 작업 공간을 공유합니다. 대시보드에 경고를 표시하는 것만으로는 이미 시작된 실행이나 외부 전송을 막을 수 없습니다.
저는 보안을 별도 모니터링 기능이 아니라 모든 도구 호출이 지나가는 실행 경로로 다시 설계했습니다.
아키텍처
┌────────────────────┐
│ 도구 호출 요청 │
└─────────┬──────────┘
▼
┌────────────────────┐
│ 1. 신원·테넌트 검증 │
└─────────┬──────────┘
├─ 불일치 → DENY
▼
┌────────────────────┐
│ 2. 격리 공간·시크릿 │
└─────────┬──────────┘
▼
┌────────────────────┐
│ 3. 결정론적 권한 정책 │
└─────────┬──────────┘
▲
└─ AI: 위험 상향만
▼
┌────────────────────┐
│ 4. 승인된 도구 실행 │
└─────────┬──────────┘
▼
┌────────────────────┐
│ 5. egress 게이트 │
└─────────┬──────────┘
├─ 장애·불명 → DENY
▼
┌───────────┐
│ 외부 시스템 │
└───────────┘
각 결정
└─ 비밀값 없는 감사 이벤트
└─ 해시 체인 검증이 구조에서 권한 검증과 실행 후 기록을 분리했습니다. 정책 검사는 실행 가능 여부를 결정하고, 감사 경로는 그 결정과 결과가 나중에 바뀌지 않았는지 검증합니다.
설계 결정 1 — 신원을 리소스보다 먼저 검증
에이전트 토큰에는 에이전트 식별자와 테넌트를 함께 결속했습니다. 요청 테넌트와 토큰의 소속이 다르면 작업 공간이나 감사 기록을 열기 전에 중단합니다.
공용 작업 공간을 먼저 만들거나 로그를 남긴 뒤 거부하면 이미 경계를 넘을 수 있습니다. 그래서 신원 검증을 모든 리소스 해석보다 앞에 배치했습니다.
설계 결정 2 — AI에는 허용 권한을 주지 않음
보조 분류 모델은 규칙이 놓친 위험 신호를 찾는 데 사용했습니다. 그러나 모델 출력이 직접 허용, 잠금 해제, 자격증명 접근으로 이어지지 않도록 했습니다.
결정론적 정책이 권한을 판정하고, AI는 위험도를 올리거나 사람 검토를 요청할 수만 있습니다. 모델 응답이 깨지거나 시간 안에 오지 않는 경우도 자동 허용하지 않습니다.
설계 결정 3 — 외부 전송은 독립적으로 fail-closed
내부 도구 실행과 외부 전송을 별도 권한으로 분리했습니다. 데이터 출처, 전송 대상, 이용 등급, 재배포 조건을 외부 전송 직전에 다시 확인합니다.
egress 판정 서비스가 응답하지 않거나 올바르지 않은 응답을 반환하면 전송은 닫힙니다. 보안 서비스 장애가 우회 경로가 되지 않도록 한 결정입니다.
설계 결정 4 — 감사 로그에는 비밀이 아닌 증거를 기록
토큰과 키 원문은 감사 이벤트에 넣지 않습니다. 비밀을 복원할 수 없는 지문과 비밀이 아닌 식별자만 기록하고, 각 레코드가 이전 레코드의 해시를 포함하도록 연결했습니다.
레코드 수정·삭제·순서 변경이 발생하면 체인 검증이 실패합니다. 단순히 로그가 존재하는지가 아니라 기록이 바뀌지 않았는지까지 확인할 수 있습니다.
위협에서 검증까지
THREAT 교차 테넌트 접근
CONTROL 토큰·요청 테넌트 선검증
PROOF hard deny
────────────────────────
THREAT 불일치 토큰 발급
CONTROL 발급 시 신원 결속 검증
PROOF 기록 전 거부
────────────────────────
THREAT 시크릿 로그 혼입
CONTROL 실행 시 전달·형태 거부
PROOF 이벤트 수집 거부
────────────────────────
THREAT egress 판정 장애
CONTROL 독립 게이트 fail-closed
PROOF 외부 전송 거부
────────────────────────
THREAT 감사 레코드 변조
CONTROL 이전 해시 기반 체인
PROOF 변조 탐지
────────────────────────
THREAT 재시작 후 경계 손실
CONTROL 테넌트별 상태 영속화
PROOF 격리 유지정상 경로보다 실패 경로를 먼저 테스트했습니다. 빌드, SDK 예제, 컨트롤 플레인 테스트, 프로덕션 구성 테스트, 이벤트 배치 테스트를 각각 분리해 통과시켰습니다.
구현 범위와 현재 한계
실행 가능한 보안 커널에서는 테넌트 격리, 신원 결속, fail-closed egress, 비밀 형태 이벤트 거부, 해시체인 감사를 검증했습니다.
AI OS의 보조 보안 분류기는 현재 모니터링·플래깅 PoC입니다. 위험 신호를 올릴 수는 있지만 다른 구독자의 실행을 중단시키는 강제 게이트는 아닙니다. 이 차이를 공개 결과물에서도 분명히 구분했습니다.
결과
이 프로젝트를 통해 에이전트 보안을 “안전 점수”나 경고 배지가 아니라 재현 가능한 실행 경로로 설명할 수 있게 됐습니다.
- 누가 어느 테넌트 권한으로 요청했는지
- 어떤 정책 게이트에서 허용·거부됐는지
- AI의 조언과 결정론적 판정이 어떻게 분리됐는지
- 외부 전송이 어느 실패 조건에서 닫혔는지
- 감사 체인이 현재 유효한지
포트폴리오에서 보여주고 싶은 핵심은 보안 기능의 개수가 아닙니다. 신원, 격리, 권한, 외부 전송, 감사를 하나의 닫힌 실행 경로로 설계하고, 공격·장애 조건으로 검증한 과정입니다.