Skip to main content
A principal is an identity that can receive roles and own API keys. Manage principals in Settings → Organization → Users, under the Human, Application, and Agent tabs.

Principal types

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, so authorized administrators can change them.
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.
See Resources and actions for the actions available at each principal scope, including currently unimplemented lifecycle actions.