Skip to main content
A Guard Policy is the set of rules a 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: 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.

​
Topic policy

Classifies content against defined topics and acts on the classification. Each topic defines what counts as safe and unsafe content, and the classification maps directly to an action:
  • safe → PASS — allowed through.
  • unsafe → BLOCK — the request is stopped.
So Topic verdicts are 2-state — PASS / BLOCK — unlike PII’s PASS / MASK / BLOCK (topics are never masked, only allowed or stopped). 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.

​
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.

​
Policy artifacts — per-module project policies

Starting with v1.4, the deployable units of project-level policy are collectively called policy artifacts. Guardian’s policy artifact is the Guard Policy; Stratum’s is the Rule Package. They’re peer project policies under the same management discipline: semantic versioning, save ≠ apply, and pinning per module instance. The two modules never share policies — Guard Policies (PII/Topic) are unchanged in v1.4. For managing Rule Packages and Taxonomies, see Manage Taxonomies & Rule Packages.

Actions: PASS / MASK / BLOCK

Author a Guard Policy