​

Security overview

Starfire AI security is built around separation of identity, permissions, credentials, ownership, and operational authority. The platform serves several very different actors—normal users, organization administrators, developers, automated workloads, and platform operators—and those actors should not share one undifferentiated permission model.

​

Security boundaries

​

User accounts

A user account represents a person using Starfire. It can have profile, session, organization, plan, project, and security state.

​

Organization roles

Organization permissions govern team resources such as members, projects, Knowledge, developer applications, policies, and billing context.

​

Developer credentials

API keys and service accounts represent software workloads. They should be scoped and revocable independently from interactive user sessions.

​

Control Center

Platform administration is a privileged operating surface with separate RBAC. Organization administrators do not automatically receive Control Center access.

​

Least privilege

Every layer should grant only what the job requires. Examples:

• a support operator can inspect account diagnostics without publishing models
• a billing operator can investigate subscriptions without receiving unrestricted user-content access
• a service account can start builds without administering an organization
• a project member can use project Knowledge without becoming an organization owner

​

Secrets

Passwords, API keys, provider credentials, webhook secrets, database credentials, payment-provider secrets, and other sensitive credentials belong in protected credential or secret-management systems—not prompts, agent instructions, project notes, documentation examples, or client-side code.

​

Sessions and devices

Interactive sessions can be revoked independently from the account. Device/session visibility supports account-security response without making every security event equivalent to a password change.

​

Auditing

Sensitive administrative actions should be attributable when the active subsystem supports audit history. This includes changes to access, billing, credits, models, configuration, sessions, or account state.

​

Private content and operations

Operating the platform requires metadata. It should not imply unrestricted browsing of private conversations, files, artifacts, or Knowledge sources. Operational diagnostics should reveal what is needed to understand system state while preserving a separate authorization boundary for content access.

​

Alpha security posture

Starfire is actively evolving. Security documentation describes the supported product model and expected controls, while private implementation details and production defenses remain outside the public documentation.