The Agent Never Holds Your Keys: Credentials and Access Boundaries
When a security team first looks at CloudThinker, they skip the demo and ask two things: what can it touch, and where do the keys live?
Those are the right questions. An agent that investigates production needs real access: an AWS account, a cluster, a Git organization, a Datadog account. If the answer to "where are the keys" is "in the prompt" or "on someone's laptop", nothing else in the design matters.
This post is about how we answer it in Frontier Investigation Agents: what holds access, where credentials live, and what reaches the machine where an agent runs.
Why the usual approach breaks
Most teams give an AI tool access the way they give a script access. Paste a token into the chat. Export a key in a shell. Put a long-lived credential on a CI runner.
Each of those moves the secret to a place you can't see. It sits in a chat transcript, in shell history, on a disk you don't patch. And the tool's reach becomes whatever that token allows, which nobody wrote down.
We wanted the opposite. Access should be declared in one place, scoped by you at the provider, and never copied onto the machine doing the work.
Three places secrets live
CloudThinker keeps secrets in three surfaces, each for one job.
01Connections
Infrastructure access
Cloud providers, databases and monitoring tools, in Settings, Connections.
02Credentials
Run-time secrets
A vendor API key or a service token, injected as an environment variable.
03BYOK
Model access
Your own model credentials, set once by the organization Owner.
Connections hold access to your cloud providers, databases and monitoring tools. Credentials hold everything else an agent needs at run time, such as a vendor API key or a service token. BYOK holds your own model credentials and has nothing to do with your infrastructure. See Your Model, Your Key.
Keeping them apart is deliberate. Credentials rejects keys with platform-reserved prefixes like AWS_, GOOGLE_, AZURE_, KUBECONFIG and GITHUB_TOKEN. Cloud access has one front door, and it's a connection.
The connection is the outer limit
A connection is a credential for one service. Agents can only see and act on what the workspace's connections allow, so the connection's permissions are the outer limit of what any agent can do.
That puts the real control where it already lives: in your provider's IAM. Our setup guides tell you to create least-privilege credentials, read-only wherever possible, and widen later. If the IAM role can't delete a bucket, no prompt or automation can make it delete one.
Inside that limit, Auto Mode and approval decide which writes run on their own and which wait for a person. Those are a second layer. The connection is the first.
Connections and credentials belong to a workspace, and a workspace is an isolated environment. Production and staging in separate workspaces means separate connections and separate credentials.
How credentials reach a command
A credential is stored encrypted at rest and never returned to the browser. The list and edit views show key names and descriptions only. Viewing and managing credentials needs the Admin workspace role.
When an agent runs a command, every credential in the workspace is injected as an environment variable. You point at one in chat with the $ picker, which inserts $STRIPE_API_KEY instead of the value. Secret values never appear in chat or in agent output. Agents see and report key names only.
If an agent needs a secret the workspace doesn't hold, it asks through a secure form in chat. The value is saved as a workspace credential, and the list marks it with the agent that added it.
Every create, update and delete is recorded in Audit Logs, by key name and never by value.
What reaches your machine
Some work has to run where your code lives. CloudThinker has two ways to do that, and both keep connection credentials in the cloud.
01Your machine
Worker or Agent CLI
- File toolsConfined to the served folder on a Worker
- Shell commandsRun as your OS account
- No connection credentialNever sent to the machine
Your code stays local
02CloudThinker Sandbox
Connection commands
- Credential injected hereFor that run only
- Writes follow workspace rulesAuto Mode and approval, same as chat
- Selected connections fixedA pending write cannot widen
The key stays in the cloud
03Your provider
IAM decides
- Least privilegeRead-only wherever possible
- Outer limitNo agent does more than the connection allows
- Revoke at the sourceAccess ends where you granted it
You set the ceiling
A Worker is a self-hosted sandbox on your laptop, a server or a CI runner. You register it and serve one folder:
cloudthinker worker start --outpost "my-laptop" --workdir ~/projects/app
File tools stay inside --workdir. A connection command doesn't run on the Worker at all. It runs in the CloudThinker managed sandbox, with the credential injected there, and the credential never leaves the cloud. Turn the CloudThinker managed sandbox switch off and connection commands don't run; the agent is told the connection is unavailable.
The Agent CLI (cloudthinker agent) works the same way from the other direction. The model loop, file edits and shell commands run on your laptop. A cloud command runs in the CloudThinker Sandbox, with a connection credential injected for that run only and never sent to your machine.
A cloud write from the CLI follows the same Auto Mode and approval rules as chat. Approval keeps the exact connections selected when the write was requested, so adding a connection can't widen a pending write, and removing access blocks it.
The design decisions
01Connection
The outer limit
What the provider credential allows is the most any agent can do.
02Workspace
The isolation line
Connections and credentials belong to one workspace.
03Approval
The write gate
Auto Mode and approval decide which writes run on their own.
04Audit
The record
Credential changes are logged by key name, never by value.
Access is declared at the provider. We don't invent a permission model on top of IAM. You already audit IAM; the agent inherits that audit.
Secrets don't travel. The value goes in once, encrypted, and is injected where the command runs. It doesn't come back to the browser, the chat or a laptop.
Broken access stops work. When a connection's credentials stop working, it flips to Error, admins get one notification per outage, and scheduled work that depends on it is skipped until it's fixed. Nothing quietly runs on a half-working credential.
No silent fallback. When a Worker is unavailable, the run reports the error. It doesn't move itself to the cloud.
Honest limits
Every credential reaches every command in the workspace. Injection happens whether or not your prompt references the key. If a secret should only reach some work, put it in a separate workspace.
Shell on a Worker is your account. File tools are confined to the folder. Shell commands are not: they run as your OS account, with its full access to the machine. CloudThinker adds no container or reduced privileges there. Serve a folder from an account whose reach you accept, and on a sensitive machine keep the workspace in Manual and use approval for shell actions.
Local commands from the Agent CLI aren't gated. CloudThinker gates cloud writes. What runs on your laptop runs as you.
A collected key can overwrite one. If an agent asks for a key that already exists and you submit it, the stored value is replaced. Check the Credentials list first.
Scope is your job. If the connection's credential is an admin key, the outer limit is admin. We tell you to start read-only. We can't make you.
Workers are in beta and the Agent CLI is in preview, so command names and flags may still change.
Try it
Connect one service with a read-only credential, then ask:
"Using the AWS connection, list what this role can and can't do, and tell me which of my questions it couldn't answer because of permissions."
"Check our Credentials list and tell me which keys you used in the last task, by name only."
"From my Worker, run the tests in this folder, then compare the failing service's deployed version in Kubernetes."
Start a trial or book a walkthrough.