Threat model

A threat model worth writing names actors, what they want, what they can do, what stops them, and what doesn’t. This page is that for Studio.

Actors and what they want

Actor	Capability	Motive
Curious co-tenant	Authenticated to a different organization on the same Studio infrastructure.	Read another org’s hosts, credentials, conversations, or recordings.
Compromised teammate account	Holds valid credentials in a target org.	Exfiltrate sensitive operational data, run destructive commands.
Malicious operator	Authorised user, intentional misuse.	Avoid leaving traces of disallowed actions.
Network adversary	On-path between client and AWS endpoints.	Capture traffic, downgrade TLS, impersonate endpoints.
Endpoint malware	Code execution on the user’s signed-in workstation.	Read plaintext credentials, replay sessions, observe device commands.
Hostile MCP/connector	A third-party tool the org has chosen to add.	Exfiltrate data through tool-call arguments and responses.
Supply chain attacker	Tries to get malicious code into a Studio release.	Persistent backdoor across all installs.
Hostile AI prompt injection	Untrusted text reaches the model context.	Coerce the model to run actions outside the user’s intent.
Stolen paired phone	A device paired through Studio Remote is lost or accessed by another person.	Read visible work or approve a consequential action.
Hostile generated app	Generated dashboard code requests overly broad capabilities or misleadingly presents an action.	Read or change resources beyond the app’s stated purpose.

What we defend, where the defense lives

Threat	Primary defense	Secondary defense
Cross-tenant data access	Per-organization KMS CMK with org-scoped principal tags; resolver-level org filters.	AppSync custom Lambda authorizer validates Clerk JWT and org membership on every request.
Stolen at-rest copies of database rows	AES-256-GCM envelope encryption of sensitive fields under per-org DEK; ciphertext useless without KMS access.	DEK rotation every 30 days; old DEKs retained encrypted but unusable for new wraps.
Stolen at-rest object storage	S3 bucket SSE-S3 + presigned-URL-only access through a Lambda that performs ACL checks.	`enforceSSL=true`, public access blocked.
Network-on-path attacks	TLS for external endpoints; supported Cognito and KMS paths use configured AWS endpoints.	Certificate validation uses the platform trust path; unexpected certificates fail unless a feature explicitly allows a reviewed exception.
Compromised user account	Clerk-managed MFA, SSO, and session policy; short-lived AWS credentials with 5-minute refresh buffer.	KMS principal tag prevents the credential from operating outside the user’s org context even if leaked.
Endpoint malware reading local protected storage	Plaintext DEKs are cached through the OS credential service with a bounded lifetime and supported cache purge on logout.	Device-while-unlocked compromise is explicitly out of scope (see below).
Disgruntled-operator removal	Org admin triggers DEK rotation; new envelopes use new DEK; revoked operator’s cached plaintext expires within 12 hours.	Clerk session revocation cuts AWS credential issuance immediately.
Hostile MCP server	Per-tool approval gate, credentials live in vault not in the model context, OAuth tokens rotated where supported.	The connector and MCP catalog is org-controlled; admins can disable a connector.
Prompt injection	Tool-call execution is constrained by organization, channel, and runtime policy plus the selected trust posture.	Tool output is treated as untrusted context; consequential actions require review unless the operator deliberately enabled Autopilot or an equivalent autonomous posture.
Stolen paired phone	Paired connections can be listed and revoked from the desktop.	The desktop remains the execution bridge; use device lock and reject approvals that lack enough visible context.
Hostile generated app	Sandboxed execution and explicit per-user capability grants bound to the requested capability set and revision.	Restrict allowed origins and re-review grants after a revision or capability change.
Supply chain	Code signing, notarization, update artifacts SHA-512 verified by `electron-updater`.	Build pipeline runs in a controlled CI environment; release artifacts published to a controlled domain.

What we explicitly do not defend against

Honesty here matters more than completeness. The list below is the set of attacks Studio’s current architecture cannot stop. Some are by design; some are roadmap items.

Out of scope	Why
Device-while-unlocked compromise. Code running in the signed-in Electron process or with sufficient local privilege can observe plaintext credentials and session data at their point of use.	The desktop app and local agent are inside the endpoint trust boundary. Use OS hardening, EDR, application control, rapid locking, and least privilege.
Operationally-required plaintext. Hostnames, display names, ownership, folder structure, and audit-context fields are stored unencrypted server-side.	Encrypting these would break search, sort, sync, and audit query patterns. Sensitivity of these fields is acknowledged and explicit.
AI provider seeing substituted secrets. When a procedure substitutes `{{password}}` into a prompt that goes to Bedrock, the substituted value enters Anthropic’s model context for that call.	Bedrock-side data handling is governed by AWS’s contracts with Anthropic; no model training on inference data. AI context scrubbing is on the roadmap.
Self-inflicted misuse with autonomy. A user who switches Copilot to autonomous trust and walks away from the keyboard can be convinced by prompt injection to run something destructive.	Autonomous trust is a deliberate choice with a deliberate cost. The defense is not removing the option; it is making the option visible and the consequences observable in the audit history.
Carrier or transit eavesdropping below TLS. TLS protects content but timing, volume, and metadata leak.	Standard for any cloud-connected app.
OS credential-store extraction by a privileged process. Platform-protected storage is not a boundary against a sufficiently privileged local attacker.	Privileged-process compromise is device-level and out of scope.
Remote approval with incomplete visual context. A paired phone can show the request but not every relevant desktop surface.	Reject ambiguous mobile approvals and continue on the desktop.
Unattended early-access workers. A poorly scoped worker can repeat an incorrect action under its granted channel and stage tools.	Keep workers owner-gated, use human gates, and restrict service credentials and stage tools.
Multi-party collusion among trusted operators. Two operators with the right roles can agree to do something they shouldn’t.	This is what audit logs and approvals exist for after the fact, not before.
Quantum-capable adversaries. Current ciphers are not post-quantum.	AWS’s published roadmap will move us when that becomes operationally available.

Trust boundaries

Studio has four crossings worth naming:

User ↔ Studio desktop app. Established by OS sign-in and Clerk authentication. The app trusts the user once authenticated.
Desktop app ↔ Go agent. Local loopback; the agent is part of the same package and receives signed-in scope and capability calls from the desktop. Loopback is not isolation from a compromised local account.
Desktop app ↔ AWS backend. Authenticated via short-term Cognito-issued AWS credentials, derived from a Clerk JWT. Every AWS API call is signed.
Studio ↔ external systems (devices, connectors, MCP, AI provider). The most variable boundary. Each system has its own credential and external audit behavior; Studio’s tool history does not replace the target system’s logs.
Studio desktop ↔ paired phone or collaborator. The desktop lends a bounded control and visibility path to another device or participant. Revocation, role, and approval scope matter.
Generated app or worker ↔ granted capabilities. Sandboxing or cloud execution is useful only if the grant, channel, credential, and target boundaries are narrow.

The vault, the approval gate, and the audit trail sit on these boundaries. The pages that follow walk through each in detail.

Assumptions our controls rely on

If any of these assumptions don’t hold for you, our controls are weaker than advertised. They’re worth verifying:

The user’s workstation is not compromised at the OS level.
The user’s Clerk account uses MFA.
The user keeps secrets in Key Chain and does not copy resolved values into prompts, commands, recordings, or less protected files.
The user reviews approval prompts rather than reflexively clicking “approve.”
The user’s organization is configured so that not every operator has admin or autonomous-trust capability.
The user’s connectors and MCP servers are sourced from trusted parties.
Paired phones, generated apps, and early-access workers are reviewed and revoked or paused when their purpose ends.

The controls described in the rest of this section are designed to make these assumptions easy to keep, not to make them unnecessary.

Vault and keys

The crown jewel: per-org KMS, AES-256-GCM, 30-day rotation, cryptographic shredding.

Known limits

The honest list of what isn’t built yet and what we’re working on.

Overview

Controls

Data and AI

Extensibility and supply chain

Transparency

Actors and what they want

What we defend, where the defense lives

What we explicitly do not defend against

Trust boundaries

Assumptions our controls rely on

Vault and keys

Known limits

​Actors and what they want

​What we defend, where the defense lives

​What we explicitly do not defend against

​Trust boundaries

​Assumptions our controls rely on

​Related

Vault and keys

Known limits

Actors and what they want

What we defend, where the defense lives

What we explicitly do not defend against

Trust boundaries

Assumptions our controls rely on

Related