#Agent가 사내 시스템을 만지는데 "유출 금지"라고만 쓰면 될까

← 전체 목차 · 이전: Agent가 스스로 "이상하다"고 오판했다면, 대량 쓰기는 무엇이 막는가 · 다음: 프롬프트를 가득 채우지 마라

"시스템 프롬프트에 '민감정보를 유출하지 말라'고 한 줄 넣으면 된다, 모델의 자각에 맡긴다." 이 답의 본질적 결함은 확정적으로 성립해야 할 보안 경계 문제를, 확률적으로 동작하는 생성 모델의 자각에 통째로 맡긴 것이다. 차단점도, 감사 기록도, 실패 시 최종 안전망도 없다. Agent가 사내 업무 시스템에 접속해 사용자 프라이버시·인터페이스 자격증명·핵심 업무 데이터를 상시 접촉하는 순간, 이 답은 사고를 시간문제로 만든다.

#네 겹의 추궁 — 어디서 새는가

네 번째 질문이 특히 날카롭다 — 그것이 요구하는 것은 방안이 아니라 실제 유출 사고를 시간선으로 복기할 수 있는가다. 전 링크 조작 감사 로그가 없으면 이 시간선 자체를 그릴 수 없다.

#가장 흔한 함정 — 출구만 지키고 입구가 뚫려 있다

두 번째 항목이 가장 은밀한 함정이다. 출력만 마스킹하고 상하문·장기 기억에 원문이 남으면, 다음 턴 대화나 한 번의 소급 조회가 그것을 그대로 끌고 나온다. 앞문은 잠그고 뒷창은 열어 둔 것과 같다.

#방안 3단 판정

"프롬프트에 한 줄 넣는다"는 이 분급에서 최저 등급, 게다가 무민감 데이터 시나리오에서만 성립한다. Agent가 프라이버시·자격증명을 상시 접촉한다는 전제 자체가 이 방안을 기각한다.

#전 링크 방어 4층

1층 · 데이터 접촉면 확정
  Agent가 전 과정에서 접촉하는 데이터 유형(사용자 프라이버시 / 인터페이스 자격증명 / 핵심 업무 데이터)을 나열
  각 유형이 거치는 구간을 표기: 입력 → 상하문 → 도구 호출 파라미터 → 장기 기억 → 생성 출력
        ↓
2층 · 데이터 접근 준입 표준
  대규모 모델에 절대 넘기면 안 되는 민감 데이터 목록 제정
  단일 세션 민감정보 임계값 + 보존 기한 레드라인 설정
        ↓
3층 · 방안 대조(암기가 아니라 비교)
  Prompt 제약 / 입출력 탈민감 / 도구 권한 격리 / 기억 분급 저장
  네 가지를 대화 / 도구 호출 / 장기 기억 / 멀티테넌트 격리 네 시나리오에서 각각 비교
  탈민감 규칙이 업무 민감 등급별 분급 설정인지 확인 (하드코딩 키워드 금지)
  상하문에 탈민감 이전 원본이 남지 않는지 확인 (2차 유출 방지)
  고민감 세션은 세션급 암호화 + 기억 자동 정리 조합으로 격리
        ↓
4층 · 아키텍처 구현 규범
  데이터 접근 준입 표준 + 단일 세션 임계값 + 보존 기한
  고민감 조작 자동 탐지 + 사람 심사를 최종 방어선으로
  도구로 안전 침투 테스트를 배치화
  전 링크 조작 감사 모니터링
  멀티테넌트 대량 접근 시 중점 재검증
  금융 데이터·개인 프라이버시·기업 기밀은 고합규 모듈로 별도 취급

#사고 정리로 되돌리기

사고 복기는 3단 요구를 되짚는 것과 같다.

검지 → 규칙 매칭 vs 대모델 2차 심사?
  └─ 검지 우회 리스크는 얼마인가?
      └─ 독립 안전 게이트웨이 + 전량 감사 로그 도입 필요한가?
           └─ 더 철저한 안전 폐쇄 루프 구축

탈민감 입도 → "안전 강도"와 "교호 체험"을 분리할 수 있는가

#상용 배치 문 앞의 철칙

탈민감 메커니즘도 없고 감사 능력도 없는 Agent 서비스는 그대로 배포 금지.

#핵심 통찰

1. 확정적 안전 경계를 확률적 시스템에 맡기면 안 된다 — 시스템 프롬프트의 "민감정보를 유출하지 말라"에는 차단점도 감사도 실패 시 최종 안전망도 없다. 100% 성립해야 하는 경계는 모델 바깥에서 코드와 게이트웨이로 구현해야 한다. 대규모 모델은 생성기이지 정책 엔진이 아니다.
2. Demo와 프로덕션의 격차는 기능이 아니라 데이터 유통의 합규성에 있다 — 기능 차원은 "돌아가는가"를 보지만 합규 차원은 "데이터가 어느 구간을 거치고, 어디에 남고, 누가 가져갈 수 있고, 실효되면 어떻게 되는가"를 본다. 후자는 Demo에서 절대 드러나지 않는다.
3. 탈민감은 양쪽을 다 봐야 한다 — 출구 탈민감만으로는 상하문 역류를 막지 못한다 — "대규모 모델의 상하문이 탈민감 이전 원본 데이터를 그대로 지니고 있을 수 있는가"라는 점검 항목이 가리키는 고빈도 사고 패턴은, 출력측에서는 치환했지만 원문이 상하문과 장기 기억에 남아 다음 턴 대화나 한 번의 소급으로 그것을 그대로 가져오는 것이다.
4. 양화 지표 없는 안전 평가는 자기 위안이다 — "차단률·오차단율·데이터 유출 리스크 등급·서킷브레이커 차단 능력" 같은 지표의 가치는 반증 가능하다는 데 있다. "대체로 안전하다"는 반증 불가능하므로 면접에서도 평가에서도 정보량이 없다.
5. 차단률과 오차단율은 반드시 짝으로 나와야 한다 — 차단률만 추구하면 시스템이 과잉 차단으로 조정되어 교호 체험이 무너진다. 그래서 세 번째 핵심 검토 항목 "탈민감 입도가 안전 강도와 교호 체험을 분리할 수 있는가"가 생긴다 — 분리가 되어야 두 지표를 동시에 최적화할 수 있다.
6. 방어는 계층화해야 하며 가장 중요한 것은 "주 방어선이 뚫렸을 때 무엇이 남는가"다 — "탈민감 실효 시 서킷브레이커 차단 능력 대조"와 3단 방안 중 "최종 안전망 부재 = 데이터 완전 노출"은 같은 이야기를 하고 있다 — 안전 방안을 평가할 때는 정상 동작 시가 아니라 첫 겹이 뚫린 뒤의 상태를 봐야 한다.
7. 사고 시간선을 복기할 수 있는가가 감사 능력의 시금석이다 — 네 번째 추궁 "시간선으로 복기해 줄 수 있는가"는 방안 서술로 얼버무릴 수 없다. 전 링크 조작 감사 모니터링이 없으면 시간선 자체를 그릴 수 없다. 그래서 "전량 감사 로그"가 2층과 4층에 함께 등장한다.
8. 복기를 프롬프트로 굳히는 것이 안전 경험을 규모화하는 유일한 저비용 경로다 — 사고 복기 지식점과 방어적 코딩 제약을 프롬프트로 응결시켜 AI 코드 생성에 먹이면, 1회성 인력 review가 매 생성마다 자동 적용되는 제약으로 바뀐다.

#엔지니어링 실전 Tips

• "후치 사람 심사"를 최종 안전망으로 강등하고 유일한 방어선으로 쓰지 말 것: 앞에 자동 탐지 없이 사람 심사만 있는 구조는 사고 후에야 발견된다. 자동 탐지가 발견을, 사람 심사가 방류 결정을 맡는 역할 분담을 지킬 것.
• 자동 탐지와 사람 심사 최종 방어선의 트리거 조건을 구분할 것: 고민감 조작 자동 탐지는 발견 담당, 사람 심사는 방류 결정 담당이며 사람 심사가 탐지를 대체해서는 안 된다.
• 장기 기억은 영속 저장소로 다스릴 것: 보존 기한 레드라인을 정하고 자동 정리를 하며 소급 유출 리스크를 평가할 것. "상하문이 길어진 기능"으로 취급하지 말 것.
• 동시성은 권한 경계의 압박 테스트장이다: 단일 요청에서 옳은 권한 검증이 순간 고동시성에서도 옳다는 보장은 없다. 최종 방어 방안은 극단적 부하를 기준으로 설계할 것.
• 멀티테넌트는 별도의 대량 접근 재검증을 거칠 것: 격리 정책은 단일 테넌트에서는 문제가 드러나지 않는다. 테넌트 간 침투 시나리오를 별도 점검 항목으로 둘 것.
• 침투 테스트는 도구로 배치화할 것: 단건 검증이 아니라 커버리지를 확보하는 것이 목적이다.
• 감사 로그는 "전량"이어야 한다: 안전 폐쇄 루프와 사고 시간선 복기 모두 여기에 의존한다. 샘플링 로그로는 사고 포렌식을 감당하지 못한다.
• 더 파고들 방향: 세 번째 추궁(순간 고동시성 월권)의 구체적 최종 방어 설계(속도 제한·서킷브레이커·권한 캐시 무효화 전략), 탈민감 강도와 교호 체험의 정량 트레이드오프 곡선, 장기 기억 소급 유출을 자동 스캔하는 도구화, Agent 프롬프트 인젝션 방어(AGENT 04)·도구 권한 등급화(AGENT 16)·감사 로그(AGENT 35)와의 결합 지점 — 이 문서가 다루는 것은 "데이터가 새는 경로" 자체이며, 저 문서들은 각각 "악성 지시 방어"와 "실행 권한 통제"와 "사후 기록"을 다룬다.