> ## Documentation Index
> Fetch the complete documentation index at: https://docs.starfort.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Guard Policy

> Guard Policy는 Starfort Guardian이 각 요청에 적용하는 규칙 묶음입니다. PII와 Topic 두 유형이 있고 버전 관리와 프리셋을 제공합니다 (Starfort v1.4 문서)

**Guard Policy**는 [Guardian](/ko/v1.4/concepts/guardian)이 집행하는 규칙의 집합입니다. 정책은 프로젝트 내부에서 생성되고, **버전 관리**되며, process type(`input` / `output`)별로 Guardian에 **할당**됩니다.

Starfort의 **Guard Policy Type Catalog**는 고정된 집합 — `PII`와 `TOPIC` — 입니다. System Guardian이 자신이 평가할 수 있는 부분 집합을 선언하고, Project Guardian이 그 부분 집합을 상속합니다. 각 정책은 **프로젝트 내에서 고유한** **Policy Name**을 가집니다. 이 이름은 Guardian 출력과 Opticon 트레이스 태그에서 사용되는 식별자이므로, 정책의 이름을 변경하면 기존 이력을 다시 쓰는 것이 아니라 새로운 정체성이 시작됩니다.

## PII 정책

개인 정보 및 민감 데이터를 탐지하고 각 매칭에 대해 어떤 조치를 취할지 결정합니다. PII 정책은 세 가지 규칙 종류로 구성됩니다.

| 규칙 종류       | 매칭 기준                | 일반적인 용도                        |
| ----------- | -------------------- | ------------------------------ |
| **NER**     | 학습된 엔티티 모델(이름, 주소 등) | 자연어 엔티티                        |
| **Regex**   | 정규식                  | 구조화된 ID(전화번호, 주민등록번호, 카드, 이메일) |
| **Keyword** | 정확한 단어/구문            | 차단 목록 용어                       |

각 규칙은 액션을 설정하는 **policy\_type**을 가집니다.

* **`MASKING`** — 매칭된 부분을 마스크 워드 토큰으로 대체합니다(예: `PHONE_NUMBER` → `[PHONE_NUMBER_1]`).
* **`BLOCKING`** — 매칭되면 전체 요청을 차단합니다.
* **`PASSING`** — 명시적으로 허용합니다(예: 테스트 데이터를 허용 목록에 추가). 더 넓은 규칙에 의해 잡히지 않도록 합니다.

<Note>
  Starfort가 기본 제공하는 PII 정책은 한국 전화번호, 주민등록번호, 여권/운전면허/통관 ID, 은행 계좌, 카드, 이메일, 차량 번호판을 다루며, 일반적인 테스트 패턴에 대한 `PASSING` 규칙도 포함합니다. [맞춤형 PII 정책 추가](/ko/v1.4/admin/how-to/add-pii-policy)를 참고하세요.
</Note>

## Topic 정책

정의된 \*\*주제(topic)\*\*에 따라 콘텐츠를 분류하고 그 분류에 따라 조치합니다. 각 주제는 무엇이 `safe`이고 무엇이 `unsafe`인지 정의하며, 분류는 액션에 직접 매핑됩니다.

* **`safe` → PASS** — 통과시킵니다.
* **`unsafe` → BLOCK** — 요청이 중단됩니다.

따라서 Topic 판정은 PII의 PASS / MASK / BLOCK과 달리 **2가지 상태** — PASS / BLOCK — 입니다(주제는 마스킹되지 않으며, 통과되거나 중단될 뿐입니다). 기본 Topic 정책의 예시 주제로는 무기, 불법 행위, 탈옥/테스트 모드, 자해, 시스템 프롬프트 노출 등이 있습니다. [맞춤형 Topic 정책 추가](/ko/v1.4/admin/how-to/add-topic-policy)를 참고하세요.

## 정책이 Guardian으로 전달되는 방식

정책은 **정책 유형 → 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 정책).

이것이 "내 변경 사항이 적용되지 않았다"는 가장 흔한 원인입니다 — 항상 버전을 다시 적용(다시 Pin)하세요. [정책 업데이트 버전 관리 및 적용](/ko/v1.4/admin/how-to/version-and-apply-policy)을 참고하세요.

## 정책 아티팩트 — 모듈별 프로젝트 정책

v1.4부터 프로젝트 레벨 정책의 배포 단위를 통칭해 **정책 아티팩트**라고 부릅니다. Guardian의 정책 아티팩트가 **Guard Policy**이고, [Stratum](/ko/v1.4/concepts/stratum)의 정책 아티팩트가 **Rule Package**입니다. 둘은 동격의 프로젝트 정책으로, 버전 관리(Semantic Versioning), 저장 ≠ 적용, 모듈 인스턴스 단위 Pin이라는 동일한 관리 규율을 따릅니다. 두 모듈의 정책은 서로 공유되지 않으며, Guard Policy는 v1.4에서도 그대로입니다. Rule Package와 Taxonomy의 관리는 [Taxonomy와 Rule Package 관리](/ko/v1.4/admin/stratum-policy)를 참고하세요.

## 관련 항목

<CardGroup cols={2}>
  <Card title="액션: PASS / MASK / BLOCK" icon="traffic-light" href="/ko/v1.4/concepts/actions-pass-mask-block" />

  <Card title="Guard Policy 작성하기" icon="pen-to-square" href="/ko/v1.4/admin/author-guard-policy" />
</CardGroup>