How to Set Up CloudThinker for DevOps, Security and Product Teams

How to Set Up CloudThinker for DevOps, Security and Product Teams

This guide shows how to roll CloudThinker out across an organization where each team owns a different scope: DevOps or SRE runs production, Security runs detection and testing, and product squads own their code and staging apps. It covers which workspaces each team gets, who holds which settings, how two teams connect the same AWS account without sharing a credential, and how work moves from one team to another.

It's written for the organization Owner and the team leads who will run each workspace. How to Design CloudThinker Workspaces for Your Organization covers the general design decisions. This guide applies them to a rollout across teams. Each step gives the decision and the recommended value, then links to the CloudThinker documentation for the setup itself. Product details are current as of November 2026.

01Plan

Workspaces per team

Give each team that owns systems its own workspaces.

02Organization

Set once

The Owner sets identity, guardrails, default budgets and chat apps.

03People

Groups and leads

Map identity groups, then make each team lead workspace Admin.

04Access

Connections and approvals

Each team connects its own access and sets its own approvals.

05Operate

Handoffs and reviews

Route chat, set each team's budget, and plan for people who move or leave.

How ownership splits across teams

Ownership in CloudThinker sits at three levels. The organization holds what must be the same for every team. Each team's workspace holds what that team decides for itself. Work that crosses teams moves through the Incident Room during an incident, and through pull requests and tickets the rest of the time.

Two rules shape every step below:

• Organization Owners and Admins are Admin in every workspace. This can't be lowered per workspace, so keep that list short and give team leads their authority inside one workspace instead.
• Nothing crosses between workspaces on its own. A team can't see another team's conversations, findings or connections unless it's a member of that workspace. Step 7 sets up the handoffs.

Before you start

Step 1: Give each team the workspaces it owns

Split by who owns the credentials, the approvals and the budget, not by the org chart. A team needs its own workspace when it connects systems other teams shouldn't reach, approves changes differently, or needs its own budget. A team that only reads results can join another team's workspace as Viewer.

The reference design below covers a platform team, a security team and one product squad:

Organization

The Owner and two or three Admins

SSO and SCIM, plan, credit limits, guardrails, chat apps and audit logs, set once for every team.

01Workspace

platform-prod

DevOps and SRE

Connects

Production AWS accounts, clusters, monitoring and paging

Approvals

Manual, with named approvers

Budget

High cap, Notify only

02Workspace

platform-nonprod

DevOps and SRE

Connects

Staging, development and sandbox accounts

Approvals

The default Auto mode

Budget

Throttle

03Workspace

security

Security

Connects

SIEM, cloud threat findings, secret scanning, and the same AWS accounts through its own role

Approvals

Asks a person before writes

Budget

Its own cap, Notify only

04Workspace

product-payments

A product squad

Connects

Its repositories and staging domains

Approvals

The default Auto mode

Budget

Throttle

Between teams. An incident brings people and agents from several workspaces into one Incident Room and its Slack war room. Other work moves as a fix pull request or a ticket.

• Split production from non-production for the team that runs production. Production gets the strictest approvals and the fewest workspace Admins.
• Give Security one workspace that only the security team joins. Memory and conversation search cover every member of a workspace, and a conversation can't be marked private, so investigations stay with the people cleared to see them. Security may look at the same cloud accounts as DevOps. Step 5 shows how both teams connect them.
• Give each product squad that owns repositories and test targets its own workspace, so its Review findings, Cyber results and automations stay with the people who fix them. Squads that share one codebase can share one workspace.
• Give every repository and every Cyber test target one owning workspace, so each finding lands with the team that fixes it.

The design uses 4 workspaces. On Scale, that leaves 6 for more squads or an eval workspace during a trial. On Team, with 3, use prod, nonprod and security, and add squads to nonprod as members. Name workspaces <team>-<environment> and record the owning team in each Description, as Step 2 of the design guide explains.

Docs: Choose a layout, Create a workspace, Pricing

Step 2: Set up the organization layer once

These settings apply to every workspace, so the Owner sets them before the first team is onboarded.

Decide the Admin list before you invite anyone. An Admin can invite a new member as Admin, but only the Owner can promote an existing member to Admin.

Docs: SSO, SCIM, Guardrails, BYOK, Credit limits

Step 3: Map identity provider groups to workspaces

With SCIM on, one change in your identity provider puts a person into the right workspaces. Push one group per team and map each group to its workspaces and an organization role:

Group names are examples. Five behaviors to plan for:

• New members get Viewer by default. Viewers can't chat or run anything, so set Developer on engineering groups.
• The role is set once. CloudThinker sets a member's organization role when it creates them. Later syncs don't change it, and a role you change by hand stays.
• Workspace roles aren't mapped. A mapping grants workspaces and an organization role. Workspace Admin for a team lead is an override you set by hand in Step 4.
• Mappings only add access. Removing someone from a group, or a workspace from a mapping, doesn't take them out of that workspace. Step 9 covers team changes.
• Invitations and just-in-time sign-up are off while SCIM is on. Someone your identity provider hasn't provisioned is refused at SSO sign-in.

Without SCIM, invite each person with their role and choose their workspaces when you invite them. An organization Owner or Admin can change a person's workspaces later in one place.

Docs: Map groups to workspaces, Set defaults for new members, Invite members, Set access across workspaces at once

Step 4: Hand each workspace to its team lead

Give team leads Admin inside their own workspace, not across the organization. A Developer with an Admin override manages that workspace's connections, credentials, approvals, automations and members, and can't open other teams' workspaces.

Five permissions decide most of these rows:

• Developers can't change incidents in Resolve. Anyone who works incidents needs workspace Admin there: on-call engineers in platform-prod, analysts in security. Keep them on a named list and review it when the rotation changes.
• Only workspace Admins create automations, accept Detectors and verify Cyber domains. Developers run Cyber tests, work Review findings and create custom agents.
• Developers can merge from Review. If someone shouldn't merge in a squad's repositories, give them Viewer in that workspace.
• Developers can add credentials through chat. The Credentials tab is locked for them, but the secure form an agent shows in chat doesn't check the workspace role, so any member who can chat can create a workspace credential or overwrite one. Keep production membership to people you'd trust with that.
• A workspace Admin isn't an organization Admin. Usage, credit limits, audit logs, chat mappings and SSO stay with the Owner and organization Admins. The one Admin Settings page a workspace Admin can open, from a direct link, is Guardrails. Agree on how leads ask for organization changes, such as a ticket queue the organization Admins own.

Docs: Roles and permissions, Workspace roles

Step 5: Connect shared AWS accounts once per team

DevOps and Security often need the same production AWS accounts for different jobs. A connection belongs to one workspace, and each connect dialog generates an External ID that ties its role to that workspace. So each team connects the account from its own workspace, through its own role:

• Create the second role from Manual steps. The setup script stops when CloudThinkerAccessRole already exists in the account. Don't swap that role's External ID for the new workspace's, because the first connection stops working. Manual steps in the dialog accept any role name.
• Keep each dialog open until you click Connect. The External ID exists only in that open dialog, which matters when Terraform applies the role later in CI.
• Turn off Allow writes on connections that must stay read-only. It starts on for AWS and most other connections, and with it off a connection stays read-only even if someone widens the role later.
• Set the Environment on each account right after you connect it. It labels the account for people and agents. Approval Rules don't read it, so to treat production differently, write a Rule that names the connection.
• Place each credential in the narrowest workspace that needs it. A security tool's API key belongs in security, not in a workspace other teams share.

Docs: Required permissions, Write access, Multiple AWS accounts, Set the environment

Step 6: Set approvals for each team

Approvals are configured per workspace, so each team lead sets the policy that fits their systems. New workspaces start on Auto with AI judgment on: reads run, a write that AI judgment finds safe runs, and the rest wait for a person. Automations default to refusing a write instead of waiting, because nobody may be there to answer. The table gives recommended settings for the reference design.

Four details matter when several teams share an organization:

• Rules decide only once CloudThinker turns on Rule enforcement for a workspace. Until then, Rules record what they would decide and the mode alone decides each write. That's why production stays on Manual. Ask CloudThinker support to turn enforcement on for a workspace when its team's Rules are ready.
• An empty Default approvers list lets every Developer or above approve. Name the approvers in production and in security.
• Send writes on another team's systems to that team. An approver group answers the Ask first Rules that name it, such as a DBA group for database writes in platform-prod. Groups route asks once Rule enforcement is on.
• Choose Destructive actions for the two-person rule unless a second approver is reachable at all hours. With All writes, an on-call engineer working alone can't approve their own fix.

Keep a baseline policy as a file, for example in Git. Exporting active Rules from one workspace gives you a policy file with its Rules, approver groups, Approval modes and two-person setting. Import it into another team's workspace, which shows what would change before it applies anything.

Turn on Agent approvals in each workspace's notifications, so an approval that a Resolve investigation raises overnight reaches someone.

Docs: Approval mode, Default approvers, Require a second person, Export and import your policy. Auto Mode explains how an agent decides what it may do alone.

Step 7: Route chat and hand work between teams

Each chat channel sends its requests to one workspace. In a regular Slack channel, every request runs as one account, whoever created the mapped workspace or the Owner, with that account's access. Treat channel membership as access, and map one channel per workspace:

• Map every Slack channel the moment the bot joins it. An unmapped Slack channel still runs requests, in the Owner's default workspace with its connections. Remove the bot from channels that shouldn't reach your systems.
• Incident war rooms are the exception. In a war room that Resolve creates, CloudThinker matches each sender by email and runs the request as that person, or refuses it.
• Microsoft Teams maps each team to one workspace. People who link their CloudThinker account run requests as themselves.
• Pick each workspace's default notification channel, so production alerts reach the production channel and security alerts reach the security channel.

Work incidents across workspaces in the Incident Room

The Incident Room is the war room for an incident: people and agents from several workspaces work the issue together in one place. Resolve opens it in the workspace where the incident starts, and CloudThinker answers from the investigation it's running there. The people you invite join as themselves. The agents you invite work exactly as their own workspace set them up.

01Who joins

People and agents

• Platform on-callResponder in platform-prod
• Security on-callInvited as a responder
• Security agentShared by the security workspace
• Squad agentShared by product-payments

02Incident Room

One room per incident

• One investigationCloudThinker answers from the analysis it is running
• Shared agentsEach follows its own workspace's setup
• Fixes through ApprovalsThe production approvers still decide

03Slack

The war room channel

• inc-<id>-<title>One summary card, edited as things change
• InviteesUp to 20 Slack members from any team

Requests run as the sender, matched by email.

Set it up in each workspace that runs incidents, starting with platform-prod:

• An invited agent follows its own workspace's setup, entirely. The security agent works with the connections, permissions and approvals of the security workspace, so Security's workspace Admins decide what it can see and do in any Room. People in a production Room can ask it about SIEM alerts or cloud threat findings, and platform-prod never gets Security's connections. Set up security the same way, so a security incident's Room can bring in an agent that platform-prod shares.
• Fixes in the Room still go through Approvals, so the production approvers from Step 6 still decide.
• Only workspace Admins page by hand and change an incident's status. Keep an Admin of platform-prod on call at all hours.
• In the Slack war room, CloudThinker runs each request as the sender, matched by email, or refuses it. Anyone invited can follow the incident and talk to the responders. Only people with access to the workspace can ask CloudThinker there.

A security lead who wants to read production incidents without being on call can join platform-prod as Viewer.

Hand off everything else in the tools teams already share

Incident Rooms open only for incidents Resolve pages people on. Other work crosses teams as a pull request or a ticket:

Docs: Who requests run as, Microsoft Teams, Notifications, Turn on On-call, Add a Slack war room, Work the incident together

Step 8: Give each team a budget

Credits come from one pool for the whole organization. Credit limits cap each workspace's monthly share:

• Keep Throttle off workspaces that work incidents. Once a workspace reaches its limit, Throttle blocks every new paid run there, including an investigation during an incident. Only chat on the Light model, using free daily credits, keeps working.
• The limit is checked when a run starts. A run already in progress finishes, so a workspace can end a little above its limit.
• Limit alerts go to the Owner only, at 80% and 100%. Team leads can't open Usage, so share each workspace's meter in the monthly review.
• The workspace limit is the backstop for automations. There's no per-automation credit cap.

Docs: Credit limits, Usage

Step 9: Plan for people who move or leave

Automation ownership can't be moved ahead of time. It changes only after the owner loses access, and the Automations page doesn't show who owns each one. Keep a list of who created which automation, so someone can take ownership the same day.

Okta and Microsoft Entra ID suspend a person when you unassign them from the app. They're removed from the organization only when your identity provider sends a delete.

Docs: What happens when someone leaves, Ownership and offboarding, Detectors

Operate and review

Docs: Check Activity, Audit logs, Usage

Anti-patterns

Setup checklist

• Each team that owns systems has its workspaces, and each workspace description names the owning team.
• Organization Admins are a named list of two or three people.
• SCIM maps each team's group to its workspaces, with Developer for engineering groups.
• Each team lead is workspace Admin through an override, and production workspace Admins are a named list.
• Each team connects shared AWS accounts through its own role, and read-only connections have Allow writes off.
• Production runs on Manual, with named Default approvers and the two-person rule for destructive actions.
• Agent approvals notifications are on in every workspace that runs incidents.
• On-call is on in every workspace that runs incidents, with responders from each team and the agents other workspaces share.
• Every chat channel the bot is in maps to one workspace, and every member of the channel may use it.
• Production and security use Notify only. Non-production, squad and eval workspaces use Throttle.
• A list records who owns each automation.

Limitations

• Organization Owners and Admins can access every workspace. Their access can't be restricted per workspace.
• SCIM maps organization roles and workspaces, not workspace roles. Overrides are set by hand, and group mappings only add access.
• Most configuration doesn't copy between workspaces. Approval policy moves as an exported file and custom skills as a .zip. A connection, custom agent or knowledge base two teams need is set up in both.
• AWS onboarding is one dialog and one role per account in each workspace. There's no bulk onboarding.
• Rule enforcement is turned on per workspace by CloudThinker. Until then, the Approval mode decides every write.
• Credit limit alerts go to the Owner only, and team leads can't open Usage.
• Audit Logs has no workspace filter. Read the Workspace column. The CSV export doesn't include it, so note the workspace when you share an export.
• Automation ownership moves only after the owner loses access.
• Agents from other workspaces join a Room only when agent sharing is on and the owning workspace allows its agent to join rooms.

Frequently asked questions

Can DevOps and Security share one AWS connection?

No. A connection belongs to one workspace. Connect the account in each team's workspace, each through its own role with its own External ID, as in Step 5.

Can a team lead run their workspace without being an organization Admin?

Yes. Give them the Developer role with an Admin override in their workspace. They manage its connections, credentials, approvals, automations and members, and they can't open other teams' workspaces.

Can Security see what DevOps does in production?

Through the Incident Room. Invite the security on-call to the On-call responders of platform-prod, so they join each Room alongside the platform team. The security workspace can also share its agent into those Rooms, and that agent works under Security's own setup. A security lead who wants to read production incidents without being on call can join platform-prod as Viewer. Organization Owners and Admins see every workspace.

How many workspaces do three teams need?

Usually four: production and non-production for the team that runs production, one for Security, and one for each product squad. Team includes 3 workspaces, Scale 10 and Enterprise unlimited.

What role do people get when SCIM creates them?

The role set on their group, or the auto-assigned organization role, which is Viewer by default. It's set once, when CloudThinker creates the member.

Why can't our on-call engineer update an incident?

Developers can view incidents in Resolve but not change them. Give on-call engineers workspace Admin in each workspace where they work incidents.

Related reading

• How to Design CloudThinker Workspaces for Your Organization
• Where Your Keys Live: Credentials and Access Boundaries
• Auto Mode: How an Agent Decides What It May Do Alone
• Control Before Trust: Putting Agents Into Production