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

# Developer Security

> Secure Starfire AI API keys, applications, service accounts, webhooks, scopes, and developer access boundaries.

# Developer security

Developer access extends Starfire into external software, so developer credentials must be treated as independent security-sensitive identities.

## Keep credentials server-side

API keys and service-account credentials belong in backend configuration or a dedicated secrets manager. They should never be embedded into public browser code, mobile application bundles, screenshots, or source repositories.

## Scope narrowly

Grant only the resource scopes the integration needs. A build automation service should not automatically receive organization billing or unrelated account-management permissions.

## Use durable ownership

Production integrations should belong to an organization, application, or service account when those capabilities are available rather than to one employee's personal identity.

## Rotate and revoke

Replace credentials when ownership changes, exposure is suspected, or policy requires rotation. Revoke old credentials after the dependent application has moved to the replacement.

## Webhooks

Webhook receivers should verify the documented Starfire event-authentication mechanism when enabled, handle duplicate deliveries safely, and avoid logging sensitive payload data unnecessarily.

## Logs

Use request IDs, endpoint/status metadata, and resource identifiers for diagnostics. Do not copy API secrets into support tickets or log them for convenience.

## Test vs production

When separate test and live environments are available, keep their credentials and data boundaries distinct. A test credential should not be assumed to have the same models, billing behavior, or external integrations as production.

## Organization policy

Developer access can still be limited by the owning organization's policy, plan, and administrative configuration.

<Warning>
  Revoking a user's browser session does not automatically prove their developer credentials are no longer valid. Review interactive and programmatic access separately during a security response.
</Warning>

<CardGroup cols={2}>
  <Card title="API access" icon="key" href="/developers/api-access">Learn the developer credential model.</Card>
  <Card title="Applications & service accounts" icon="server" href="/developers/applications-service-accounts">Design durable non-human integration ownership.</Card>
</CardGroup>