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

# Applications & Service Accounts

> Model durable Starfire AI integrations around applications, organization ownership, non-human identities, and scoped access.

# Applications & service accounts

A production integration is easier to manage when its developer resources belong to a named application or non-human identity instead of floating as unrelated keys under an employee account.

## Applications

A Starfire developer application can group concepts such as:

* API keys
* webhooks
* permissions
* usage
* environment
* organization ownership
* logs

Example application:

```text theme={null}
Application: Starfire Discord Bot
├── production credential
├── webhook endpoints
├── usage history
└── permissions
```

## Why applications help

Applications make it easier to answer:

* which workload used this credential?
* which webhook belongs to this integration?
* how much usage did this integration generate?
* what permissions does the integration have?
* who owns the integration now?

## Service accounts

A service account is a non-human identity for backend automation.

Instead of attaching a production build system to an employee's personal account, an organization can use a service-account model with only the permissions required for that workload.

## Least privilege

A service account should be scoped to its job. A CI integration that creates FORGE builds and retrieves resulting artifacts should not automatically receive billing administration or unrelated organization-management permissions.

## Organization ownership

For business systems, the organization should own the application and service account whenever the platform supports that model.

That makes offboarding safer because removing an employee does not automatically break the organization's production integration.

## Credential rotation

Applications can have more than one credential during controlled rotation. After dependent software has moved to the replacement credential, revoke the old one.

## OAuth direction

Starfire's developer architecture is also designed with future delegated application authorization in mind. OAuth-style capabilities should be treated as **planned or staged** until the active developer portal marks them available.

<Note>
  An application or service account is not a way to bypass organization policy. Its effective access remains bounded by its scopes, owner, plan, and platform configuration.
</Note>