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: This role is held by Thunk.AI staff and is assigned by Thunk.AI — it is not something an org or its members can request or grant.
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 | Define models in the org catalog and assign or unassign them per 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-5.1 via OpenAI or Azure, Gemini 3.5 Flash via Gemini or Vertex AI). Org admins define a model once in the org's model catalog, then assign it to one or more environments. |
MCP servers | Business application integrations (e.g., Salesforce, GitHub, internal APIs) registered as Model Context Protocol servers. |
OAuth connections | Client-credential connections used by AI models (and other integrations) that require OAuth. An org admin creates these under their own Personal environment's Connections settings, then references them by ID from a model definition or environment. |
Each environment has an isolated credential that scopes its AI model and MCP server access. One environment cannot use or see the resources of another.
Managing AI Models
Setting up AI models for an org generally follows this order:
Make sure everyone who needs access to the new models — thunk owners and, optionally, other admins — is already a member of the org.
Create the environment(s) that will hold the models, setting its description, deployment phases, and members. Many orgs create a matching set of environments (e.g. one for each stage of development).
Create a credential for each distinct client ID your models will use.
Create the model definitions, giving each a prefix and a credential.
Assign the model definitions to the environment(s) that should use them.
Test each assignment with Test It.
Creating a credential
If a model requires an OAuth client-credentials connection, create it once and reuse it — models that share the same underlying client credentials (for example, every model in a given environment) can all reference the same connection rather than each creating its own. An org admin creates a credential under their own Personal environment’s Connections settings: give it a name, choose Client Credentials (Machine-to-Machine) as the grant type — not Authorization Code, which is for a different, user-driven flow — and enter the token endpoint, client ID, and client secret. Once saved, the connection is assigned an ID you can reference from any model definition.
Use the Diagnostics button on the credential to confirm it can obtain a token before relying on it in a model definition. Some warnings shown there can be safely ignored as long as the token itself is retrieved successfully.
A model definition can also create its own OAuth connection inline if you’d rather not manage it separately, but it won’t be reusable by other models unless you reference that same connection’s ID from them.
Creating an environment
Creating an environment starts with a name and description. After it’s created, open the environment to set:
Deployment Phases — tags (Prototype, Testing, Production) that control which thunks, by their own phase, can use this environment. An environment with no phases assigned can be used by a thunk in any phase.
Members — the org members who should have access to this environment. Only existing org members can be added, so complete step 1 above first.
Creating a model definition
In org settings, open the Model Definitions tab and select New Model Definition. A model definition specifies:
Base Model Name and Provider — which underlying model and which AI provider serves it
Prefix — a short qualifier that keeps this model’s registered name unique. Following an org-wide convention for prefixes (e.g. by team) makes models easier to identify; models within the same environment typically share a prefix, though this isn’t required.
Provider Model Name — the deployment name or model ID your provider uses, if different from the base model name
API Base URL (and, for some providers, an API version or GCP project) — only needed for a custom or dedicated endpoint
Credential — attach an existing OAuth connection, create a new one, or leave the model to use the org’s default provider API key
Once created, a model definition is reusable — the same definition can be assigned to multiple environments rather than being configured separately in each one.
Assigning a model to an environment
From an environment’s detail view, select Assign Model Definition and choose from the org’s catalog. The model becomes available to anyone with access to that environment. Removing a model from an environment (via its Unassign control) does not delete the underlying model definition — it remains in the catalog and can be re-assigned or assigned to other environments.
A model definition must be unassigned from every environment it’s assigned to before it can be deleted from the Model Definitions tab.
Testing a model connection
Each assigned model shows a Test It button that sends a simple request through the model to confirm the connection is configured correctly — useful right after creating or editing a definition, or when diagnosing why a workflow isn’t reaching a model. A successful test shows the model’s response; a failed test shows the error returned.
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.
Who can see and use an environment
Org owners and admins automatically have access to all environments in their org.
Everyone else — thunk owners and other admins — must be explicitly granted access to an environment by being added as a Member of that environment, which only an org admin can do. This allows orgs to maintain strict separation between environments (e.g., only the infrastructure team has access to the production environment).
The org owner/admins can grant/revoke a user’s membership on an environment at any time.
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 | — | ✓ | ✓ | ✓ |