Skip to main content
Starfort organizes tenant resources under a four-tier hierarchy, with the platform itself (Global) at the root. 
Global              ← the whole system
└── Company         ← a company / customer tenant
    └── Organization
        └── Project ← Guardians, API keys / Agent Users live here

Company

The top-level tenant. Owns company-wide settings such as Control Profiles, Agent Users, Desktop Agent Access Key, and quotas.

Organization

A grouping inside a company for teams or business units.

Project

Where you register Guardians and manage credentials. Each project has a fixed type.
Global sits above Company and is the system-wide scope managed by the platform operator (System Admin), separate from any individual company’s data.

​
Accounts and Multi-Company

An Account is the authenticating subject that logs into the console — distinct from the Agent Users and API End Users whose traffic is governed. One Account can belong to several Companies at once (Multi-Company): you pick a company at login to switch context. Identity and permission are separated — the Account authenticates, but its permissions are resolved in the (Account, Company) context, and one context can hold multiple roles. Tenants are isolated: policy, log, and permission data is never exposed across Company or Project boundaries.

​
Project type

When you create a project you choose its type, and it cannot be changed afterward:
  • API — for embedding the Guard API in your own application. Manages API keys.
  • Desktop Agent — for protecting employees’ use of AI tools via the Windows Desktop Agent. Managed through Control Profiles and Agent Users.

​
Roles

Access is governed by RBAC: a Role bundles IAM Policies (system-access rules), and an Account is granted roles. Standard roles:
RoleCapability
OwnerFull control, including company-level settings.
AdminManage organizations, projects, Guardians, and policies.
MemberWork within assigned projects.
ViewerRead-only.
Organizations and Projects auto-create all four roles; a Company auto-creates only Owner and Viewer. You can also define Custom Roles by composing IAM Policies.
IAM Policy ≠ Guard Policy. An IAM Policy governs who can access the system (RBAC, Account → Role). A Guard Policy governs content (Project Guardian → input/output filtering). Both are managed in the Console but serve different purposes.

​
Governance controls that follow the hierarchy

​
Kill Switch (3-tier)

The Kill Switch is an emergency toggle at three resource tiers — Organization, Project, and Project Guardian — and any tier can be toggled independently. Activating it halts every Project Guardian beneath that tier while preserving each resource’s own state; releasing it resumes from the preserved state. Note:
  • A Company has no Kill Switch of its own — a higher authority can trigger all resources beneath it instead.
  • It is orthogonal to API Key state (Active / Inactive / Revoked); the Bastion verifies both on every request.
  • The master System Guardian is excluded from the Kill Switch.
See Use the Kill Switch.

​
Audit Log and monitoring

  • Audit Log records governance changes only — administrative/operational actions. It does not record runtime request/response traces, automatic system events (heartbeats, health checks), simple reads, or denied attempts. It has two tiers: Company Audit Log and the /aim System Audit Log. It is immutable. See Audit log.
  • Monitoring (Opticon) shows the runtime traces — a separate record layer from the Audit Log — per project. See Monitor traces.
First time here? The Account Admin quickstart walks through creating the company, an organization, a project, a Guardian, and a key end to end.