Skip to main content

Orgs, Roles, and Environments: Enterprise Administration Guide

How we organize access for enterprise customers

This document describes how Thunk.AI organizes access for enterprise customers: how organizations are structured, who administers them, and how resource environments control what AI models and business application connections are available to users.

Organizations

An organization (org) is the top-level tenant unit in Thunk.AI. Every user belongs to exactly one org. The org is the administrative boundary for:

  • User membership and roles

  • Billing and tier (SKU)

  • AI provider API keys shared across the org

  • Resource environments made available to org members

Orgs are created and managed by Thunk.AI platform administrators — enterprise customers cannot self-provision orgs directly.


The Platform Admin

The platform admin is a Thunk.AI operator-level role. It is distinct from any org-level role.

Who is a platform admin: Any user who is an owner or admin of the internal Thunk.AI "Alpha Team", or the designated system service account (PLATFORM_SYSTEM_USER_ID).

What a platform admin can do:

Action

Description

Create an org

Provision a new named tenant

Delete an org

Remove an org entirely

Transfer org ownership

Move the owner role to a different user within the org

Change an org's billing tier (SKU)

Adjust the subscription level

List all orgs

View all tenants across the platform

Resolve any org by ID

Access any org record directly

Platform admins cannot read or control the content inside orgs (thunks, workflows, user data) unless they are also explicitly added as org members.


Org Roles: Owner and Admin

Within an org, there are two administrative roles: Owner and Admin. Both have full administrative authority over the org and its environments.

Org Owner

The org owner is the user who was designated as owner when the platform admin created the org (typically the primary enterprise contact). There is one owner per org.

What the org owner can do:

  • Everything an org admin can do (see below)

  • Transfer ownership to another org admin (via the platform admin)

Org Admin

Org admins are appointed by the owner. There can be multiple org admins.

What org admins can do:

Action

Description

Manage org membership

Add and remove participants

Appoint or remove other admins

Manage the admin roster

Add and remove AI provider API keys

Manage OpenAI, Anthropic, Google keys stored on the org

Create resource environments

Provision new environments for the org

Update and delete resource environments

Rename, reconfigure, or remove environments

Configure LLM models in an environment

Add or remove AI models available in each environment

Configure MCP servers in an environment

Add or remove business application connections in each environment

Grant environment access to users

Control which org members can see and use each environment

Revoke environment access

Remove individual users from an environment


Org Roles: Participant

Participant is the standard membership role for employees in the org. Participants can use the resources (API keys, environments) that have been explicitly provisioned to them — they do not automatically gain access to everything in the org.


Resource Environments

A resource environment is a named configuration context owned by an org. It bundles together the AI models and business application connections that users and automated workflows can draw on when running thunks.

What an environment contains

Resource type

Description

AI models

Connections to LLM providers (e.g., GPT-4o via OpenAI, Claude via Anthropic, Gemini via Google). Org admins add models from the org's stored provider API keys.

MCP servers

Business application integrations (e.g., Salesforce, GitHub, internal APIs) registered as Model Context Protocol servers.

OAuth connections

Per-environment delegated credentials for third-party services.

Each environment has an isolated credential (a LiteLLM virtual key) that scopes its AI model and MCP server access. One environment cannot use or see the resources of another.

Multiple environments per org

An org can have multiple environments. Common patterns:

  • Dev / Staging / Production — different model tiers or application endpoints per stage

  • Team-specific environments — different business app connections for different departments

  • Cost-controlled environments — different model selections for cost or compliance reasons

A thunk (workflow) is linked to one environment at a time. Moving a thunk between environments (e.g., from staging to production) means reassigning its environment reference.

Who can create and manage environments

Only the org owner and org admins can create, update, delete, or configure environments. Participants cannot create environments.

Who can see and use an environment

Org owners and admins automatically have access to all environments in their org.

Regular participants do not automatically see all org environments. Access is per-environment and must be explicitly granted by an org admin. This allows orgs to maintain strict separation between environments (e.g., only the infrastructure team sees the production environment).

The org owner/admins can grant/revoke access to an environment to specific users and groups.

The Personal Environment

In addition to org-managed environments, every user has a personal environment. This is an isolated context that belongs to the individual user — the org does not provision or control it.

The personal environment surfaces the platform-level AI models (provided by Thunk.AI) for personal use. Users experimenting or building individual automations use this environment. When a user is ready to promote a thunk to a shared org environment, they reassign its environment reference.


Summary: Who Can Do What

Action

Platform Admin

Org Owner

Org Admin

Participant

Create / delete an org

Transfer org ownership

Set org billing tier

Manage org API keys

Add / remove org members

Create / delete environments

Configure models & MCP servers

Grant environment access to users

Use environments they have access to

Use personal environment

Did this answer your question?