Skip to main content
Starfort
Starfort is an AI governance platform by AIM Intelligence — an intelligence control solution that lets an organization control both the people using AI and the AI itself, the way the organization intends. Security, regulatory compliance, and quality management all sit on top of this single control model. Its Guardian module inspects the content flowing to and from AI services in real time and enforces your organization’s policies — masking sensitive data, blocking disallowed topics, and recording every decision for audit.

​
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.”
PriorityRiskExamplesHow it is handled
1stAI Security riskPII / secret leakage, jailbreak, prompt injectionNon-negotiable — enforced centrally
2ndAI Regulatory risknational AI law, domain rules (finance, healthcare), internal policyMandatory — central guidance + per-domain application
3rdAI Service riskhallucination, quality, user experienceQuality improvement — autonomous optimization allowed
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.
Governance for all three is configured by an Account Admin in the Console (cloud.starfort.io): organizations, Guardians, Guard Policies, keys, and monitoring.

​
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.
PII policies resolve to PASS / MASK / BLOCK; Topic policies resolve to PASS / CHECK / BLOCK (CHECK flags review-needed content). See Actions: PASS / MASK / BLOCK for details.

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

​
What’s new in v1.3

  • Forge — test your policies before they meet traffic — register a Test Dataset (inputs paired with expected verdicts) per Project Guardian, run Experiments against chosen policy versions, and measure PASS / MASK / BLOCK accuracy. Failed cases point you to the policy fix; a re-run confirms it. See Test policies (Forge).
  • Opticon Fail-Safe (Fail-Open / Fail-Closed) — each project can now choose what happens when a Guard verdict is rendered but its audit trace ultimately can’t be recorded: return it as before (Fail-Open, the default) or block the request (Fail-Closed), closing the audit gap for compliance-critical operations. See Monitor traces (Opticon).
This documentation covers Starfort v1.3. Product names — Starfort, Guardian, Guard Policy, Guard API, Opticon, Control Profile — are kept in English across all languages.