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 | — | ✓ | ✓ | ✓ |
