메인 콘텐츠로 건너뛰기
Starfort는 테넌트 리소스를 4단계 계층 아래에 구성하며, 그 루트에는 플랫폼 자체(Global)가 있습니다. 
Global              ← the whole system
└── Company         ← a company / customer tenant
    └── Organization
        └── Project ← Guardians, API keys / Agent Users live here

Company

최상위 테넌트입니다. Control Profile, Agent User, Desktop Agent Access Key, 할당량 등 회사 전체 설정을 소유합니다.

Organization

팀이나 사업 단위를 위해 회사 내부에서 묶는 그룹입니다.

Project

Guardian을 등록하고 자격 증명을 관리하는 곳입니다. 각 프로젝트는 고정된 **유형(type)**을 가집니다.
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를 내장하기 위한 유형입니다. API 키를 관리합니다.
  • Desktop Agent — Windows Desktop Agent를 통해 직원의 AI 도구 사용을 보호하기 위한 유형입니다. Control Profile과 Agent User를 통해 관리됩니다.

​
역할

접근은 RBAC로 관리됩니다. Role은 IAM Policy(시스템 접근 규칙)를 묶은 것이며, Account에 역할이 부여됩니다. 표준 역할은 다음과 같습니다.
역할권한
Owner회사 수준 설정을 포함한 전체 제어.
Admin조직, 프로젝트, Guardian, 정책 관리.
Member할당된 프로젝트 내에서 작업.
Viewer읽기 전용.
Organization과 Project는 네 가지 역할을 모두 자동 생성하고, Company는 Owner와 Viewer만 자동 생성합니다. IAM Policy를 조합하여 Custom Role을 정의할 수도 있습니다.
IAM Policy ≠ Guard Policy. IAM Policy는 누가 시스템에 접근할 수 있는지를 관리합니다(RBAC, Account → Role). Guard Policy는 콘텐츠를 관리합니다(Project Guardian → input/output 필터링). 둘 다 Console에서 관리되지만 서로 다른 목적을 가집니다.

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

​
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 사용하기를 참고하세요.

​
감사 로그 및 모니터링

  • Audit Log는 거버넌스 변경만 기록합니다 — 관리/운영 작업. 런타임 요청/응답 트레이스, 자동 시스템 이벤트(하트비트, 헬스 체크), 단순 읽기, 거부된 시도는 기록하지 않습니다. 이는 두 단계로 구성됩니다: Company Audit Log와 /aim System Audit Log. 변경 불가능합니다. 감사 로그를 참고하세요.
  • 모니터링(Opticon)은 프로젝트별로 런타임 트레이스 — Audit Log와는 별개의 기록 계층 — 를 보여줍니다. 트레이스 모니터링을 참고하세요.
처음 오셨나요? Account Admin 빠른 시작에서 회사, 조직, 프로젝트, Guardian, 키를 처음부터 끝까지 생성하는 과정을 안내합니다.