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

# 조직 계층

> Starfort가 테넌트를 구조화하는 방식: Company › Organization › Project, 그리고 프로젝트에 연결되는 Guardian과 키.

Starfort는 테넌트 리소스를 4단계 계층 아래에 구성하며, 그 루트에는 플랫폼 자체(**Global**)가 있습니다.

```
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">
    최상위 **테넌트**입니다. **Control Profile**, **Agent User**, Desktop Agent **Access Key**, 할당량 등 회사 전체 설정을 소유합니다.
  </Card>

  <Card title="Organization" icon="building-user">
    팀이나 사업 단위를 위해 회사 내부에서 묶는 그룹입니다.
  </Card>

  <Card title="Project" icon="cube">
    **Guardian**을 등록하고 자격 증명을 관리하는 곳입니다. 각 프로젝트는 고정된 \*\*유형(type)\*\*을 가집니다.
  </Card>
</CardGroup>

**Global**은 Company 위에 위치하며, 개별 회사의 데이터와 분리되어 플랫폼 운영자(System Admin)가 관리하는 시스템 전역 범위입니다.

## Account와 Multi-Company

**Account**는 콘솔에 로그인하는 인증 주체입니다 — 트래픽이 거버넌스 대상이 되는 *Agent User* 및 *API End User*와는 구별됩니다. 하나의 Account는 **동시에 여러 Company에 속할 수 있습니다**(Multi-Company). 로그인 시 회사를 선택하여 컨텍스트를 전환합니다. 정체성과 권한은 분리되어 있습니다 — Account가 인증을 수행하되, 그 권한은 `(Account, Company)` 컨텍스트에서 결정되며, 하나의 컨텍스트가 여러 역할을 가질 수 있습니다.

테넌트는 격리됩니다. 정책, 로그, 권한 데이터는 Company 또는 Project 경계를 넘어 노출되지 않습니다.

## 프로젝트 유형

프로젝트를 생성할 때 유형을 선택하며, 이후에는 **변경할 수 없습니다**.

* **API** — 직접 만든 애플리케이션에 [Guard API](/ko/v1.2/api/quickstart)를 내장하기 위한 유형입니다. **API 키**를 관리합니다.
* **Desktop Agent** — Windows [Desktop Agent](/ko/v1.2/desktop/how-it-works)를 통해 직원의 AI 도구 사용을 보호하기 위한 유형입니다. **Control Profile**과 **Agent User**를 통해 관리됩니다.

## 역할

접근은 **RBAC**로 관리됩니다. **Role**은 **IAM Policy**(시스템 접근 규칙)를 묶은 것이며, Account에 역할이 부여됩니다. 표준 역할은 다음과 같습니다.

| 역할         | 권한                         |
| ---------- | -------------------------- |
| **Owner**  | 회사 수준 설정을 포함한 전체 제어.       |
| **Admin**  | 조직, 프로젝트, Guardian, 정책 관리. |
| **Member** | 할당된 프로젝트 내에서 작업.           |
| **Viewer** | 읽기 전용.                     |

Organization과 Project는 네 가지 역할을 모두 자동 생성하고, **Company**는 **Owner**와 **Viewer**만 자동 생성합니다. IAM Policy를 조합하여 **Custom Role**을 정의할 수도 있습니다.

<Note>
  **IAM Policy ≠ Guard Policy.** *IAM Policy*는 누가 시스템에 접근할 수 있는지를 관리합니다(RBAC, Account → Role). [*Guard Policy*](/ko/v1.2/concepts/guard-policy)는 콘텐츠를 관리합니다(Project Guardian → input/output 필터링). 둘 다 Console에서 관리되지만 서로 다른 목적을 가집니다.
</Note>

## 계층을 따르는 거버넌스 제어

### Kill Switch (3단계)

**Kill Switch**는 세 가지 리소스 단계 — **Organization**, **Project**, **Project Guardian** — 에서의 비상 토글이며, 각 단계는 독립적으로 토글할 수 있습니다. 이를 활성화하면 해당 단계 아래의 모든 Project Guardian이 중단되는 동시에 **각 리소스 자체의 상태는 보존**됩니다. 해제하면 보존된 상태에서 재개됩니다. 참고:

* **Company는 자체 Kill Switch를 갖지 않습니다** — 대신 상위 권한이 그 아래의 모든 리소스를 발동할 수 있습니다.
* 이는 API Key 상태(Active / Inactive / Revoked)와 \*\*직교(orthogonal)\*\*합니다. Bastion은 모든 요청에서 둘 다 검증합니다.
* 마스터 **System Guardian**은 Kill Switch에서 제외됩니다.

[Kill Switch 사용하기](/ko/v1.2/admin/kill-switch)를 참고하세요.

### 감사 로그 및 모니터링

* **Audit Log**는 **거버넌스 변경만** 기록합니다 — 관리/운영 작업. 런타임 요청/응답 트레이스, 자동 시스템 이벤트(하트비트, 헬스 체크), 단순 읽기, 거부된 시도는 기록하지 *않습니다*. 이는 두 단계로 구성됩니다: **Company** Audit Log와 `/aim` **System** Audit Log. 변경 불가능합니다. [감사 로그](/ko/v1.2/admin/audit-log)를 참고하세요.
* **모니터링**(Opticon)은 프로젝트별로 런타임 **트레이스** — Audit Log와는 별개의 기록 계층 — 를 보여줍니다. [트레이스 모니터링](/ko/v1.2/admin/monitoring-opticon)을 참고하세요.

<Note>
  처음 오셨나요? [Account Admin 빠른 시작](/ko/v1.2/admin/quickstart)에서 회사, 조직, 프로젝트, Guardian, 키를 처음부터 끝까지 생성하는 과정을 안내합니다.
</Note>