Apps & Organizations

An app is the unit that owns API keys, provider configuration, and grants. One app per integrated product is the usual shape.

An organization groups apps that belong to the same company or team. Most workspaces have one organization; the distinction matters mainly for billing, member management, and isolating production from staging.

What lives on an app

• API keys — runtime keys (alter_rk_…) and unbound agent-typed keys (alter_ak_…), both minted from the app’s API Keys page; per-agent keys bound to a named managed agent — and keys minted before the scoped formats — use the legacy alter_key_… prefix. See API keys.
• Provider configurations — OAuth client IDs and secrets per provider, managed-secret credentials, scope allowlists. See Providers.
• Identity provider settings — the IDP that authenticates the app’s end users (Auth0, Clerk, Okta, WorkOS, custom OIDC). See Connecting an identity provider.
• Grants — every OAuth authorization a user has completed and every managed secret an operator has provisioned. See Grants.
• Managed agents — workload identities for AI agents and background services. See Agents.
• Audit logs — credential access, provider execution, lifecycle, and policy events attributed to this app. See Audit logs.

Boundary semantics

An app is a hard boundary for grants, API keys, and agents. A key minted for app A cannot read grants on app B; an agent provisioned in app A cannot be addressed from app B. Cross-app access is rejected as if the resource did not exist.

This makes apps the right primitive for separating:

• Production from staging — distinct apps means distinct keys, distinct grants, and no chance of a staging credential reaching a production grant.
• Distinct products in the same organization — a calendar product and a billing product can coexist in one org without sharing grants.
• Multi-tenant isolation (usually unnecessary) — most apps multiplex many end users through the same app via identity resolution, not separate apps per tenant.

Lifecycle

An app moves through three states:

• Active — the normal operating state. Grants resolve, agents authenticate, the SDK accepts requests routed to this app.
• Archived — a reversible visibility change. The app is hidden from default operator listings while its grants, managed secrets, keys, and runtime behavior remain intact. Use it to remove inactive apps from the normal workspace view; unarchive the app to restore it to that view.
• Deleted — a hard, irreversible cascade. The app and its owned grants, keys, secrets, and agents become permanently unavailable. Deletion requires a typed-confirmation step in the portal and the CLI.

What’s next

• Setting up an app — the operator surface.
• API keys — minting, rotation, revocation.
• Providers — the provider catalog.