input / output)별로 Guardian에 할당됩니다.
Starfort의 Guard Policy Type Catalog는 고정된 집합 — PII와 TOPIC — 입니다. System Guardian이 자신이 평가할 수 있는 부분 집합을 선언하고, Project Guardian이 그 부분 집합을 상속합니다. 각 정책은 프로젝트 내에서 고유한 Policy Name을 가집니다. 이 이름은 Guardian 출력과 Opticon 트레이스 태그에서 사용되는 식별자이므로, 정책의 이름을 변경하면 기존 이력을 다시 쓰는 것이 아니라 새로운 정체성이 시작됩니다.
PII 정책
개인 정보 및 민감 데이터를 탐지하고 각 매칭에 대해 어떤 조치를 취할지 결정합니다. PII 정책은 세 가지 규칙 종류로 구성됩니다.| 규칙 종류 | 매칭 기준 | 일반적인 용도 |
|---|---|---|
| NER | 학습된 엔티티 모델(이름, 주소 등) | 자연어 엔티티 |
| Regex | 정규식 | 구조화된 ID(전화번호, 주민등록번호, 카드, 이메일) |
| Keyword | 정확한 단어/구문 | 차단 목록 용어 |
MASKING— 매칭된 부분을 마스크 워드 토큰으로 대체합니다(예:PHONE_NUMBER→[PHONE_NUMBER_1]).BLOCKING— 매칭되면 전체 요청을 차단합니다.PASSING— 명시적으로 허용합니다(예: 테스트 데이터를 허용 목록에 추가). 더 넓은 규칙에 의해 잡히지 않도록 합니다.
Starfort가 기본 제공하는 PII 정책은 한국 전화번호, 주민등록번호, 여권/운전면허/통관 ID, 은행 계좌, 카드, 이메일, 차량 번호판을 다루며, 일반적인 테스트 패턴에 대한
PASSING 규칙도 포함합니다. 맞춤형 PII 정책 추가를 참고하세요.Topic 정책
정의된 **주제(topic)**에 따라 콘텐츠를 분류하고 그 분류에 따라 조치합니다. 각 주제는safe, controversial, unsafe 콘텐츠를 정의하며, 분류는 액션에 직접 매핑됩니다.
safe→ PASS — 통과시킵니다.controversial→ CHECK — 검토가 필요한 것으로 표시됩니다. Desktop Agent와 Proxy Server에서는 CHECK가 PASS로 집행됩니다(콘텐츠가 차단이나 마스킹 없이 통과하며 트레이스에만 기록됨). API 호출자는CHECK를 그대로 받습니다.unsafe→ BLOCK — 요청이 중단됩니다.
정책이 Guardian으로 전달되는 방식
정책은 Policy Type → Policy Name이라는 2단계 구조로 Guardian에 전달됩니다. 동일한 유형의 여러 정책은 이름으로 구분되어 별도로 유지되므로(그대로 전달되며 절대 병합되지 않음), 하나의input 슬롯이 예를 들어 서로 다른 두 개의 PII 정책과 하나의 Topic 정책을 동시에 담을 수 있고 각각은 독립적으로 평가됩니다.
버전 관리 및 할당
Guard Policy는 **시맨틱 버저닝(Semantic Versioning)**을 사용하며, Project Guardian은 특정 버전을 Pin합니다.- 정책의 규칙을 편집하면 새 버전이 생성됩니다(예:
v0.1.0→v0.1.1). - Project Guardian은 명시적으로 다시 Pin하기 전까지 Pin된 버전을 계속 사용합니다 — 저장 ≠ 적용. 새 버전을 게시해도 Pin이 자동으로 변경되지 않습니다.
- 하나의 process type 슬롯은 둘 이상의 정책을 담을 수 있습니다(예:
input에 PII 정책 그리고 Topic 정책).