안전 출력 계층

안전 출력 계층은 보안 강제 지점으로서 에이전트가 하는 모든 변경 — 댓글, 패치, issue 생성, 상태 업데이트 — 가 검증되고, 위협을 확인하고, 감시됩니다. 이는 승인 정책과 위협 탐지가 절대 우회될 수 없게 하는 유일한 병목입니다.

중앙 집중식 강제 계층이 필요한 이유

중앙 게이트 없이 모든 변경 경로마다 자체 정책 검사 필요:

• 에이전트가 issue 생성 → 정책 확인
• 에이전트가 댓글 → 정책 확인
• 에이전트가 패치 → 정책 확인
• 등등

이는 약함 — 한 경로에 검사를 빠뜨리기 쉬움. 안전 출력 계층은 모든 변경이 신뢰할 수 있는 한 적용자를 통과하도록 보장합니다.

안전 출력 계층 작동 방식

에이전트가 작업을 실행하면:

1. 정규화 — 작업을 표준 형태로 정규화
2. 정책 검사 — 워크스페이스 승인 정책 평가
3. 위협 스캔 — 보안 문제 스캔 (비밀 누출, 프롬프트 주입 등)
4. 적용 또는 큐 — 즉시 실행 (허용 시) 또는 승인 대기열에 큐
5. 감시 — 변경 불가 감시 로그에 기록

어떤 단계라도 문제 플래그 시 작업은 거부되거나 심각도에 따라 승인 대기열에 입력됩니다.

지원되는 작업 유형

안전 출력 계층은 다음 에이전트 작업 처리:

정책 평가

에이전트가 작업을 시도하면 정책 엔진:

1. 활성화된 모든 워크스페이스 정책 수집
2. 작업 유형 및 파일 경로 기반 정책 매칭
3. 결과 결정:
   • 허용 — 작업이 즉시 실행
   • 승인 필요 — 작업이 큐에 입력, 수동 승인 대기
   • 거부 — 작업이 직접 거부

예를 들어 정책이:

Action type: patch
File glob: .github/workflows/**
Effect: require_approval

.github/workflows/에 영향 주는 모든 패치는 승인을 기다리는 큐에 입력됩니다.

위협 탐지

작업 적용 전 위협 탐지기가 스캔:

• 비밀 누출 — 에이전트가 코드에 API 키 또는 자격증명 추가?
• 프롬프트 주입 — 댓글에 주입된 명령 시도?
• 위험한 패치 — 에이전트가 민감한 파일 수정?
• Shell 명령 위험 — 스크립트의 위험한 명령?
• 네트워크 위험 — 미지의 호스트로의 아웃바운드 연결?

위협 발견 시:

• 정보 수준 — 기록되지만 허용
• 경고 수준 — 허용되지만 감시에 플래그
• 차단 수준 — 워크스페이스 정책에 따라 거부 또는 큐

승인 큐잉

작업에 승인이 필요할 때:

1. 작업이 저장되고 내용의 암호 해시와 함께
2. 승인 요청이 받은편지함 → 승인에 나타남
3. 인증된 승인자 (보통 관리자)가 검토하고 결정
4. 승인 시, 저장된 작업이 적용됨 (해시 검증으로 변조 방지)
5. 거부 시, 에이전트가 통보되고 작업이 폐기됨

해시는 큐에 입력된 정확한 작업이 적용되는 것 — 중간의 변조 없음을 보장합니다.

감시 로그

모든 작업이 안전 출력 감시 로그에 기록됨:

• 발생 사항 — 작업 유형, 결과 (적용/큐/거부)
• 이유 — 정책 또는 위협 탐지의 이유
• 시기 — 타임스탐프
• 누가 — 어느 에이전트, 어느 작업
• 증거 — 추적 가능성을 위한 작업 해시

설정 → 감시 로그에서 감시 로그 보기, 필터:

• 날짜 범위
• 에이전트
• 작업 유형
• 결과 (적용, 큐, 거부)

다음에 사용:

• 보안 사건 조사
• 규정 준수 감사
• 에이전트 행동 이해
• 패턴 감지 (예: 반복 거부)

인간과 에이전트 구분

안전 출력 계층이 에이전트 발원 작업과 인간 발원 작업을 다르게 처리:

• 에이전트 작업 → 정책, 위협 탐지, 승인 게이트 대비 평가
• 인간 UI 작업 → 정책으로 게이트되지 않음 (인간 신뢰), 하지만 여전히 감시

이는:

• 당신 (인간)은 항상 댓글, issue 업데이트 등 가능
• 에이전트는 당신이 설정한 승인 정책 따라야 함
• 모든 것이 감사를 위해 기록됨

편집과 개인정보

모든 감사 항목이 자동 편집됨:

• 비밀과 API 키가 마스킹됨
• 홈 디렉토리가 익명화됨
• 민감한 파일 내용이 기록되지 않음

이는 감사 로그가 자격증명 실수 노출 없이 안전하게 공유 가능함을 보장합니다.

정책과 위협 탐지와의 통합

안전 출력 계층은 통합 지점:

• 승인 정책 (approval-policies.md) — 승인이 필요한 시기 제어
• 위협 탐지 (threat-detection-checks.md) — 보안 문제 스캔

함께 포괄적인 보안 프레임워크 형성:

1. 정책이 제어 대상 정의 (예: 「changes to .env are blocked」)
2. 위협 탐지가 방법 발견 (예: 「this patch adds an API key」)
3. 안전 출력 계층이 강제 (둘 다 검사 보장)

최선의 사례

• 정책과 탐지 결합 — 정책만으로는 불충분 (수동 구성 의존); 탐지만으로는 거짓 긍정 가능. 둘 다 사용.
• 정규적으로 감사 로그 검토 — 패턴 발견하고 정책 조정
• 신중하게 승인 — 큐의 작업을 철저히 검토 후 승인
• 정책 문서화 — 팀원이 어떤 작업이 승인 필요한지 이해 돕기
• 먼저 비프로덕션에서 테스트 — 테스트 워크스페이스에 먼저 엄격 정책 활성화, 다음 배포

제한사항

• 정책이 에이전트에만 적용 — 인간 작업은 감시되지만 게이트 안 됨
• 위협 탐지는 휴리스틱 — 패턴 매칭 기반, 만능 아님
• 승인이 수동 — 자동 승인 없음; 인간이 검토해야 함
• 편집이 최선의 노력 — 사용자 정의 비밀 패턴이 모두 포착 못할 수 있음

다음 단계

• 승인 정책 — 승인이 필요한 것 정의
• 위협 탐지 검사 — 보안 문제 스캔
• 기업 거버넌스 기능 — 워크스페이스 범위 보안