> ## Documentation Index
> Fetch the complete documentation index at: https://docs.starfort.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Organization hierarchy

> How Starfort structures tenants: Company › Organization › Project, with Guardians and keys attached to projects.

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
```

<CardGroup cols={3}>
  <Card title="Company" icon="building">
    The top-level **tenant**. Owns company-wide settings such as **Control Profiles**, **Agent Users**, Desktop Agent **Access Key**, and quotas.
  </Card>

  <Card title="Organization" icon="building-user">
    A grouping inside a company for teams or business units.
  </Card>

  <Card title="Project" icon="cube">
    Where you register **Guardians** and manage credentials. Each project has a fixed **type**.
  </Card>
</CardGroup>

**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](/en/v1.2/api/quickstart) in your own application. Manages **API keys**.
* **Desktop Agent** — for protecting employees' use of AI tools via the Windows [Desktop Agent](/en/v1.2/desktop/how-it-works). 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:

| Role       | Capability                                               |
| ---------- | -------------------------------------------------------- |
| **Owner**  | Full control, including company-level settings.          |
| **Admin**  | Manage organizations, projects, Guardians, and policies. |
| **Member** | Work within assigned projects.                           |
| **Viewer** | Read-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.

<Note>
  **IAM Policy ≠ Guard Policy.** An *IAM Policy* governs who can access the system (RBAC, Account → Role). A [*Guard Policy*](/en/v1.2/concepts/guard-policy) governs content (Project Guardian → input/output filtering). Both are managed in the Console but serve different purposes.
</Note>

## 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](/en/v1.2/admin/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](/en/v1.2/admin/audit-log).
* **Monitoring** (Opticon) shows the runtime **traces** — a separate record layer from the Audit Log — per project. See [Monitor traces](/en/v1.2/admin/monitoring-opticon).

<Note>
  First time here? The [Account Admin quickstart](/en/v1.2/admin/quickstart) walks through creating the company, an organization, a project, a Guardian, and a key end to end.
</Note>