Skip to main content
Studio is an AI-assisted operations IDE that connects directly to production network and server infrastructure. That combination — autonomous agents, persistent credentials, real device access — sets a high bar for safety. This section is the engineering account of how we meet that bar, and where we’re still working. We wrote it for the person who has to sign off on Studio for their environment. It’s not a marketing page. It cites the actual controls we’ve built, names the cryptographic primitives, and is honest about the things that aren’t done yet. If you find a gap, tell us — that’s how this gets stronger.

​
The principles

Six commitments shape every safety decision Studio makes:

Plaintext minimization

Supported secret fields use envelope encryption and Key Chain resolution. Plaintext still exists when a value is displayed or used, and local recordings, exports, or prompts can create additional copies that need their own controls.

Approval before consequence

Tool policy, risk classification, and approval UI make external effects reviewable. Autopilot is the explicit exception: it removes per-call prompts for tools that remain available under policy.

Tenant isolation by cryptography

Organization authorization is reinforced by per-organization encryption for supported sensitive fields. Metadata and unencrypted fields still depend on identity, resolver, and storage controls.

One AI provider, controlled region

Model inference goes through AWS Bedrock in the region selected under AI settings, subject to model availability. Studio does not call Anthropic’s hosted API directly.

Auditability over autonomy

Tool activity, conversation history, usage, and supported audit events make operational work inspectable. Coverage differs by surface, so target-system logs and endpoint evidence remain important.

Honest limits

Some things are not built yet. Some things never will be (because they conflict with operational reality). We document both. Buying decisions made on incomplete information cost more than the truth.

​
What’s on this tab

Threat model

What we’re defending against, what we’re not, and the assumptions our controls rely on.

Identity and access

Clerk for the user, Cognito for the AWS calls, organization isolation enforced top to bottom.

Vault and keys

Per-org KMS keys in a FIPS-validated HSM, AES-256-GCM envelope encryption, automatic 30-day DEK rotation, cryptographic shredding on org deletion.

Human in the loop

The trust-level model, tool classification, the approval gate, and how the steering controls let you stop or redirect a running agent in real time.

AI provider and data flow

Bedrock-only, model and region pinning, three-tier prompt cache, secret redaction before model context, and the boundary between local and cloud.

Agent and local runtime

Electron + Go sidecar architecture, what stays on your device, the local embeddings model, and how the desktop process talks to the backend.

Audit and telemetry

What’s logged, what’s redacted, what third parties get (Sentry, Amplitude), and how to disable optional telemetry.

Connectors and MCP safety

How third-party API credentials are stored, how MCP tool catalogs are gated, and what happens if a remote MCP server tries to misbehave.

Supply chain and updates

Code signing, notarization, update signature verification, the build pipeline, and the path from source to your machine.

Known limits and roadmap

The honest list of what isn’t done yet and what we’re working on. Read this before committing.

​
A one-paragraph version

If you read nothing else: Studio’s user identity is Clerk; AWS access goes through Cognito Identity Pool short-term credentials; sensitive fields are encrypted with AES-256-GCM under per-organization data keys wrapped by AWS KMS; the AI agent runs through tool policy and risk-based approval gates; model inference uses Anthropic models through AWS Bedrock in the configured region, with documented regional fallbacks where a model is unavailable; the desktop app is a signed Electron binary with a Go sidecar for local operations; and the remaining gaps are documented under known limits.

​
Apply controls by surface

The normal chat approval model is only one boundary. Browser autopilot, Computer Use, generated apps, Studio Remote, shared sessions, and early-access digital workers each add a distinct execution or delegation path. Review the page for that surface and test with a non-production target before granting broader access. For an operator-focused control summary, see Security and privacy.

​
How to read this section

If you’re a CISO doing initial diligence: read threat model, vault and keys, known limits, in that order. If you’re a security engineer doing the deep review: read every page. The vault and HITL pages have the most engineering detail; the supply chain page has the most surprises. If you’re an MSP or ISP team lead deciding whether your operators can use Studio: read overview, human in the loop, and audit and telemetry.