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

# Principals

> Human, Application, and Agent identities, including the system-managed OleanderSystem principal.

A principal is an identity that can receive [roles](/iam/roles) and own [API keys](/platform/settings/api-keys). Manage principals in [Settings → Organization → Users](https://oleander.dev/app/settings/members), under the **Human**, **Application**, and **Agent** tabs.

## Principal types

| Type        | Used for                                         | Lifecycle                                                                            |
| ----------- | ------------------------------------------------ | ------------------------------------------------------------------------------------ |
| Human       | People who sign in to oleander.                  | Invite to the organization; remove their membership when access is no longer needed. |
| Application | Services, integrations, and automated workloads. | Create an identity in the organization; delete it when no longer needed.             |
| Agent       | AI agents that need their own access.            | Create an identity in the organization; delete it when no longer needed.             |

Removing a Human removes membership in the current organization, not the person's account. Deleting an Application or Agent deletes that organization-owned identity. Organization owners and system-managed principals are protected from these removal operations.

New custom Application and Agent principals receive a default API key, but no roles automatically. Assign the roles they need before using IAM-managed resources. Human invitations can include roles; inviting requires **Invite** for **All human principals** and **Manage grants** on each selected role.

## Acting as a principal

An API key acts as its owner. A scheduled job uses its configured execution principal, whose current organization membership and compute access are checked when it runs.

An MCP OAuth connection can act as the signed-in user or a selected, non-system-managed Agent principal. Selecting another execution principal requires **Describe** and **Manage grants** on that principal. MCP delegation is checked again when the connection refreshes its credentials.

The selected principal's permissions govern the work. The person configuring the connection or schedule does not transfer their own permissions to it.

## OleanderSystem

Oleander provisions an Application principal named **OleanderSystem** for each organization. It starts with the **JobOperator** role and a default API key. Internal workflows use this key for operations including OpenLineage reporting.

**JobOperator** grants **Execute** and **Abort** across all compute engines; it does not grant warehouse data access. Being system-managed does not bypass IAM checks.

OleanderSystem cannot be deleted. Its role assignments remain subject to the ordinary [assignment rules](/iam/permissions#delegating-access), so authorized administrators can change them.

<Warning>
  Revoking OleanderSystem's default API key can interrupt workflows that depend on it. Retrying organization provisioning preserves the existing key and its revocation state; it does not reactivate a revoked key.
</Warning>

See [Resources and actions](/iam/resources-and-actions#principals) for the actions available at each principal scope, including currently unimplemented lifecycle actions.