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:
Rule kindMatches byTypical use
NERa trained entity model (name, address, …)natural-language entities
Regexa regular expressionstructured IDs (phone, RRN, card, email)
Keywordan exact word/phrasedenylisted 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.

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

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

​
Related

Actions: PASS / MASK / BLOCK

Author a Guard Policy