Security and Trust

Answer a vendor security review: what CloudThinker stores, where agents run, who can act, how writes are approved, and what is logged.

CloudThinker agents read your cloud accounts, clusters, and tools through connections you add, and can change them only when Approvals allows it. This page collects the facts a security reviewer asks for, with a link to the page that covers each control in depth.

​

At a glance

Question	Answer	Details
Where does CloudThinker run?	A CloudThinker-managed cloud service at app.cloudthinker.io by default. Dedicated, self-hosted, and air-gapped deployments are in early access.	Deployment, reference architectures for AWS, Azure, Google Cloud, and FPT Cloud
Where do agent commands run?	In a CloudThinker managed sandbox, or on a machine you control (an environment, in beta).	Environments
How do agents reach my systems?	Only through connections a workspace Admin adds, with the credentials and permissions you grant.	Connections
Can agents change things on their own?	Reads always run. Every write goes through Approvals, and can wait for a person or be refused. The Approval mode is the control that decides today; Rules decide only once CloudThinker turns on Rule enforcement for your workspace. A read-only credential can’t write at all.	Approvals, Rules in preview
Who can sign in, and how?	Google, GitHub, SSO (SAML 2.0 or OIDC), or a code emailed to your work address. An authenticator app adds a second factor.	Single sign-on
Who can do what?	Organization roles and workspace roles: Admin, Developer, Viewer, plus an organization Owner.	Roles
Are secrets kept out of chat and model calls?	Pasted values in known credential formats are caught before a message sends, though an unusual format can get through (what to do). In tool output, connection secrets, saved credentials under a secret-sounding name (containing KEY, TOKEN, SECRET or PASSWORD) with a value of 6 or more characters, common credential formats, and protected identifiers are replaced with placeholders before the model or the screen sees them. A credential saved under a plain name, or shorter than 6 characters, is masked only if it matches a known format.	Data protection
Is there an audit trail?	Yes, on Scale and Enterprise. User, agent, and system actions across the organization, kept 90 days, exportable as CSV.	Audit logs
Can we use our own LLM account?	Yes, with BYOK on Scale and Enterprise.	BYOK
Compliance reports, hosting region, subprocessors, model-provider data terms?	These docs don’t cover them. Ask for them when you start a vendor review.	Contact us

​

Data CloudThinker handles

Data	Why CloudThinker holds it	How it’s protected
Connection credentials (cloud keys, tokens, database logins)	So agents can query the systems you connected	Encrypted at rest. Injected into the managed sandbox when a command runs, never sent to an environment.
Workspace credentials (other API keys a command needs)	So a command can call a vendor API without anyone pasting a key	Encrypted at rest, never sent back to the browser. Chat shows key names only.
Conversations, findings, reports, and artifacts	The record of what agents found and did	Scoped to the workspace and visible by role. Secrets and protected identifiers in tool output are replaced with placeholders before they’re stored. A workspace Admin can delete a conversation from its title menu (Delete Conversation).

Model calls go to CloudThinker’s LLM provider unless your organization uses BYOK, which routes them through your own AWS Bedrock, Anthropic, FPT Cloud, Claude Code, or Codex account. With BYOK, those calls fall under your own agreement with that provider, except when a failed call falls back to CloudThinker’s models (details).

Anything a connection’s credential can read can reach the model, because command output is part of the conversation. With AWS ReadOnlyAccess, that includes S3 object contents. Scope each credential’s policy to the accounts, regions, and services agents need.

​

Where agents run

Every chat and Automation runs in one of two places:

• CloudThinker Cloud. Commands run in an isolated, CloudThinker-managed sandbox. Connection credentials are injected there for the command and aren’t printed back.
• An Environment. A machine you control, such as a laptop, server, or CI runner, runs file tools and shell commands in one folder you name. A connection command still runs in the managed sandbox, so the credential stays in the cloud. Self-hosted environments are in beta.

A run doesn’t fall back from an environment to the cloud. If the environment is unavailable, the run reports an error. See Environments.

These docs don’t list egress IP ranges. If you need to allowlist CloudThinker in a security group or firewall, contact us.

​

Who can act

Access works at two levels. An organization role applies across every workspace. A workspace role sets what a member can do inside one workspace.

Workspace role	Can do
Admin	Manage connections, credentials, members, Approvals, Guardrails, and settings
Developer	Chat with agents and work findings, reviews, and scans
Viewer	View dashboards, findings, and incidents. Can’t chat with agents or change anything, with one exception: any member, Viewers included, can install a Skills Hub skill into their current workspace, and it goes live in Chat for every agent.

Organization Owners and Admins hold workspace Admin in every workspace. Full matrix: Roles.

Who can approve a write: by default, any Developer or Admin in the workspace, including the person who started the run. Viewers never can. To stop people approving their own runs, turn on the two-person rule, or send a Rule’s asks to a named approver group. See Approvers.

Admin Settings is the organization console, for organization Owners and Admins. Admin Settings isn’t in a workspace Admin’s menu, but they can open one page there from a direct link: Guardrails, which shows that workspace’s settings.

​

Sign-in controls

Control	Where	Plans
Authenticator app (TOTP) with one-time backup codes. Each person turns it on for their own account; there’s no organization-wide 2FA requirement.	Account Settings → 2FA	All
SSO with SAML 2.0 or OIDC, domain verification, and enforced SSO	Admin Settings → Identity and access	Scale and Enterprise
SCIM user and group sync	Admin Settings → Identity and access	Scale and Enterprise

See Single sign-on and SCIM.

​

How agent changes are approved

A write is any agent call that changes a connected system, such as restarting a service. Reads always run. Each write passes these checks in order:

1. Always blocked, a built-in list of calls that never run, such as stopping CloudTrail logging, closing an AWS account, or deleting the kube-system namespace. Nothing overrides it, not a Rule, a person, or break-glass (an opt-in emergency override that lets an owner or admin run one call a Deny Rule refused).
2. Your Rules, which allow, ask first, or deny a named kind of write. Rules decide only when Rule enforcement is on for your workspace. It’s off by default, and CloudThinker turns it on per workspace; until then Rules record the verdict they would give and the Approval mode alone decides. See Rules in preview.
3. The Approval mode for the run, described below.
4. The approver, who approves or declines.

The Approval mode is either Manual or Auto. An Auto label, such as Auto · Rules + AI · Ask me, adds two more choices after the mode:

Part	Options	What it does
Mode	Manual	Asks a person for every write
	Auto	Lets writes run without a person when the next part allows them
What can allow a write	Rules	Only your Allow Rules
	Rules + AI	Your Allow Rules, plus AI judgment for writes no Rule covers
What happens to the rest	Ask me	Waits for a person
	Refuse	Refused, with no wait

New workspaces start on Auto · Rules + AI · Ask me. Automations default to Auto · Rules + AI · Refuse, since no one may be there to answer. Here’s what AI judgment does:

Write	Result
Matches what you asked for and stays in its scope	Runs, and the decision is recorded in Audit logs
Destructive, or its effect is unclear	Goes to the mode’s last part: Ask me waits for a person, Refuse refuses it with no wait. A destructive write also raises a high-severity alert.
AI judgment can’t finish its check	The same fallback. It never allows a write by default.

A write also needs the connection to permit it. If Allow writes is off on the connection’s detail panel in More → Workspace settings → Connections, or the credential is read-only, the write is refused whatever the mode says. To require a person for every write, switch the workspace to Manual. See Approvals and Approval mode.

​

Audit and retention

Admin Settings → Audit Logs shows one timeline of user, agent, and system actions across all workspaces: connection changes, approval decisions, credential changes, member changes, and module activity. Each entry records the actor, the workspace, and the outcome.

Fact	Value
Who can view	Organization Owner and Admin
Plans	Scale and Enterprise
Retention	90 days, then deleted automatically. There’s no in-app setting to change it.
Export	Export CSV, respecting your current filters. There’s no streaming feed to a SIEM, so export on a schedule to keep a longer record.

Credential entries never include the value or the key name. See Audit logs.

On Free or Team, audit what agents did in AWS from your own CloudTrail: filter events on the role you created for CloudThinker (CloudThinkerAccessRole if you used the setup template).

​

Encryption and sessions

Layer	What CloudThinker does
In transit	The app and API are served over HTTPS
Stored secrets	Connection credentials, workspace credentials, BYOK keys, and integration tokens are encrypted at rest with Fernet (AES-128 with HMAC-SHA256). CloudThinker manages the key. Customer-managed encryption keys aren’t offered. BYOK covers LLM credentials, not encryption keys.
Passwords	Any account password is stored as a bcrypt hash
Sessions	Access tokens are signed with RS256. Refresh tokens rotate on use and are stored as hashes.

​

Before you connect production

• Start each connection with read-only credentials, scoped to the accounts and regions agents need.
• Keep production workspaces on Manual. That setting is live today; an Ask first Rule only holds a write once CloudThinker turns on Rule enforcement for the workspace.
• Ask every Owner and Admin to turn on 2FA, or enforce SSO so sign-in follows your identity provider’s MFA policy.
• Give each member the lowest role that fits.
• Check the built-in protections in Admin Settings → Guardrails, and add patterns for your own ID formats.

For a security questionnaire or a dedicated deployment, contact us.

​

Next steps

Data Protection

See what happens when a secret is pasted or printed

Custom Guardrails

Choose which identifiers agents never see

Approvals

Decide which writes run, wait, or never run

Single Sign-On

Connect your identity provider and enforce SSO