Why Starfort: the AI risk hierarchy
Starfort exists because AI risk is not one undifferentiated problem. It ranks into three tiers, and each tier is handled differently — this ordering is what justifies “enforce centrally, optimize locally.”
This maps onto a two-team responsibility split: the Security team owns AI Security risk, the AI Governance team owns Service/Quality risk, and the two jointly own Regulatory risk. Starfort is built to support exactly this collaboration — the most critical policies are enforced from the center, while teams keep the freedom to tune for quality.
How Starfort is used
There are three entry points, each providing a different level of control. They share the same Guardian engine and policies.API — service level
Internal/external services (backends, chatbots) embed guardrails by calling the Guard API before/after their model.
Desktop Agent — device level
Employees use everyday AI tools while the Desktop Agent (Windows) transparently enforces policy on the endpoint.
Proxy Server — infrastructure level
AI calls made at an external service’s server-side entry point are routed through Starfort.
What Guardian does to a request
Every piece of content is evaluated against your Guard Policies and assigned an action. The action set depends on the policy type:PASS
Content is allowed through unchanged.
MASK
Sensitive spans are replaced with tokens (e.g.
[PHONE_NUMBER_1]) — PII policies.BLOCK
The request is stopped before it reaches the AI service.
Core ideas
Guardian
The engine that inspects content and decides the action.
Guard Policy
The PII and Topic rules a Guardian enforces.
Organization hierarchy
Company › Organization › Project, and how Guardians attach to projects.
Glossary
Definitions for every Starfort term used in these docs.
This documentation covers Starfort v1.2. Product names — Starfort, Guardian, Guard Policy, Guard API, Opticon, Control Profile — are kept in English across all languages.