---
date: 2026-07-08
project: AI 에이전트
type: reference
domain: architecture
status: active
last-reviewed: 2026-07-27
tags:
  - foundry
  - security
  - governance
  - access-control
  - markings
  - audit
  - evals
related:
  - "[[00_MOC — Foundry+AIP 플랫폼 설계]]"
  - "[[02_Data Integration — 파이프라인과 Lineage]]"
  - "[[04_AIP — 온톨로지 위의 AI 계층]]"
---

# ③ 보안 · 거버넌스 모델

> [!NOTE] TL;DR
> 거버넌스는 "나중에 붙이는 것"이 아니라 **모든 계층을 관통하는 설계**다. 데이터 제품·lineage·권한·민감도 태그·감사 로그가 **하나의 메타데이터 모델 안에서 함께** 움직여야 한다.

---

## Foundry 보안 = discretionary + mandatory 조합

| 개념 | 유형 | 설명 |
|------|------|------|
| `Projects` | 경계 | Foundry의 주 작업 단위이자 **1차 보안 경계** |
| `Roles` | discretionary | Owner·Editor·Viewer·Discoverer (Project 단위 부여) |
| `Markings` | **mandatory** | PII·PHI·금융·수출통제 범주. 모든 marking 조건 충족해야 접근 |
| `Property markings` | mandatory | 속성 단위 marking/CBAC |
| marking 전파 | lineage 연동 | **민감 데이터의 파생물도 민감도를 이어받음** |

> discretionary(역할이 있으면 접근) + mandatory(marking을 충족 못 하면 역할이 있어도 차단)의 **AND** 조합. 둘 다 만족해야 접근된다.

---

## 자체 설계 시 최소 요구사항

- **object/property-level access**: 타입 전체 권한 + 속성 단위 masking/deny
- **tool/action authorization**: LLM이 호출해도 실행 시 **사용자 권한 + service account 권한 모두** 검증
- **권한 전파**: raw PII에서 파생된 feature·embedding·summary·chunk에도 민감도 태그 전파
- **audit**: 누가·어떤 context·어떤 model/tool로·어떤 action을 제안/실행/거절했나
- **retention**: prompt·retrieved context·output·action log의 보존·삭제 정책

> [!DANGER] vector DB 착각 — 가장 흔한 보안 사고
> embedding·chunk가 원문보다 덜 민감하다고 착각하기 쉽다. **실제로는 원문의 파생물**이므로 원문과 **같은 marking·retention·삭제 정책**을 따라야 한다.

---

## AI 실행을 위한 4대 안전 장치

| 장치 | 역할 |
|------|------|
| **Human-in-the-loop** | AI output을 action proposal로 만들고 검토 후 실행 |
| **Approvals** | 민감/권한초과 변경은 request → admin approval → invoke |
| **Checkpoints** | 민감 상호작용 중간에 목적·정당화 입력 요구 + audit record |
| **Evals** | prompt/model/function 변경마다 테스트 케이스·평가함수·metric·버전 비교 |

> [!IMPORTANT] 운영 AI의 핵심 질문
> **"AI가 언제 제안만 하고, 언제 실행하고, 누가 승인하는가."** 이 경계를 [[04_AIP — 온톨로지 위의 AI 계층]]에서 action tool로, [[07_전략 — 7단계 실행 로드맵]]에서 단계로 구현한다.

### Eval이 없으면 운영 반영 금지
LLM은 비결정적이다. eval set(100~300개) + 평가 함수 + 이전 버전 비교 없이 prompt를 운영에 넣는 것은 [[06_안티패턴 — 흔한 실패 모드]]의 대표 사례.

---

## 감사(audit) 완전성 기준
- 모든 proposal/실행에 **생성 근거 + 입력 context** 기록
- 감사팀이 **기록만 보고 의사결정 경로를 재구성** 가능해야 함 (audit completeness 목표 100%)
- 자동 실행 action도 예외 없이 audit log로 추적

관련 KPI·게이트: [[08_전략 — 게이트·KPI·RACI]]