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.

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 every external endpoint; Cognito and KMS calls hit FIPS endpoints.	Certificate pinning at the OS trust store; no custom CA injection.
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 the keychain	Plaintext DEKs cached in OS keychain (macOS Keychain, Windows DPAPI, Linux libsecret) with 12-hour TTL; full 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 requires either supervised approval or explicit autonomous trust; destructive operations have stricter gates.	Read-only operations are scoped, output never auto-pasted into the next prompt without human review of context attachment.
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 can observe plaintext credentials and session data in transit through the Go sidecar.	The desktop app is the trust boundary. If an adversary executes code on your unlocked workstation, they have already won; cryptography downstream is moot. Mitigation is OS-level (EDR, signed software policy, screen lock).
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.
Keychain extraction by a privileged process. macOS / Windows / Linux keychains are protected by the OS but not magic.	Privileged-process compromise is again device-level and out of scope.
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 sidecar. Local-only; the sidecar is part of the same package and trusts the parent process. Plaintext keys move across this boundary in memory.
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 external system has its own credential, its own approval posture, and its own audit log entry per call.

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 has not pasted their KMS-wrapped DEKs out of the keychain into a less protected location.
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.

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