> ## 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
> A Guard Policy is the set of rules a Guardian enforces. Starfort has two policy types: PII and Topic.
A **Guard Policy** is the set of rules a [Guardian](/en/v1.2/concepts/guardian) enforces. Policies are created inside a project, **versioned**, and **assigned** to a Guardian per process type (`input` / `output`).
Starfort's **Guard Policy Type Catalog** is a fixed set — `PII` and `TOPIC`. A System Guardian declares the subset it can evaluate, and a Project Guardian inherits that subset. Each policy carries a **Policy Name** that is **unique within the project**; that name is the identifier used in Guardian output and in Opticon trace tags, so renaming a policy starts a fresh identity rather than rewriting history.
## PII policy
Detects personal/sensitive data and decides what to do with each match. A PII policy is made of three rule kinds:
| Rule kind | Matches by | Typical use |
| ----------- | ----------------------------------------- | ---------------------------------------- |
| **NER** | a trained entity model (name, address, …) | natural-language entities |
| **Regex** | a regular expression | structured IDs (phone, RRN, card, email) |
| **Keyword** | an exact word/phrase | denylisted terms |
Each rule carries a **policy\_type** that sets its action:
* **`MASKING`** — replace the match with a mask word token (e.g. `PHONE_NUMBER` → `[PHONE_NUMBER_1]`).
* **`BLOCKING`** — block the whole request when matched.
* **`PASSING`** — explicitly allow (e.g. allowlist test data) so it is not caught by a broader rule.
The default PII policy shipped by Starfort covers Korean phone numbers, resident registration numbers, passport/driver-license/customs IDs, bank accounts, cards, emails, and vehicle plates — plus `PASSING` rules for common test patterns. See [Add a customized PII policy](/en/v1.2/admin/how-to/add-pii-policy).
## Topic policy
Classifies content against defined **topics** and acts on the classification. Each topic defines `safe`, `controversial`, and `unsafe` content, and the classification maps directly to an action:
* **`safe` → PASS** — allowed through.
* **`controversial` → CHECK** — flagged as review-needed. On the Desktop Agent and Proxy Server, **CHECK is enforced as PASS** (the content passes through with no block or mask and is recorded in the trace only); API callers receive `CHECK` as-is.
* **`unsafe` → BLOCK** — the request is stopped.
So Topic policies use the action set **PASS / CHECK / BLOCK**, unlike PII's PASS / MASK / BLOCK. Example topics in the default Topic policy include weapons, illegal activity, jailbreak/test-mode, self-harm, and system-prompt exposure. See [Add a customized Topic policy](/en/v1.2/admin/how-to/add-topic-policy).
## How policies are passed to a Guardian
Policies reach a Guardian as a two-level structure: **Policy Type → Policy Name**. Several policies of the same type are kept separate by name (passed verbatim, never merged), so a single `input` slot can carry, say, two distinct PII policies and a Topic policy at once and each is evaluated independently.
## Versioning and assignment
Guard Policies use **Semantic Versioning**, and a Project Guardian **Pins** a specific version:
* Editing a policy's rules **creates a new version** (e.g. `v0.1.0` → `v0.1.1`).
* A Project Guardian keeps using the **Pinned** version until you explicitly re-pin it — **save ≠ apply**. Publishing a new version does not auto-change a pin.
* A single process-type slot can hold more than one policy (for example a PII policy **and** a Topic policy on `input`).
This is the most common source of "my change didn't take effect" — always re-apply (re-pin) the version. See [Version & apply a policy update](/en/v1.2/admin/how-to/version-and-apply-policy).
## Related