Agent and local runtime

Studio ships an Electron desktop app together with a local Go agent. The desktop app owns the workbench, conversations, cloud-backed records, and approval UI. The Go agent owns many device-facing and machine-facing capabilities, including terminal protocols, diagnostics, packet capture, browser automation, local indexing, and vault cryptography. This boundary improves capability separation, but both processes run inside the signed-in workstation’s trust boundary. A compromised desktop account or privileged local process is not made safe merely because a capability lives in the agent.

​

Responsibility split

The exact tool set depends on the platform, organization policy, channel policy, and the permissions granted on that workstation.

​

Local loopback boundary

The desktop app talks to the local agent over loopback. Loopback prevents remote network clients from reaching the service directly, but it does not make every endpoint unreachable to other software already running as the user. The agent therefore also uses origin checks, scoped identity, approval tokens, and capability-specific controls where implemented. Treat malware or an untrusted local process on an unlocked workstation as a serious boundary failure. Studio’s local controls reduce accidental or cross-context access; they are not a sandbox against a fully compromised endpoint.

​

Local data

Studio uses several forms of local state: Do not assume “local” means “encrypted,” and do not assume “visible in Studio” means “shared.” Check both the local storage boundary and the resource visibility.

​

Vault operations and plaintext

The Go agent performs supported AES-GCM vault operations through the BoringCrypto-backed build. Per-organization data-encryption keys are wrapped through AWS KMS and cached locally through OS-protected storage for a limited period. Sensitive synchronized fields are encrypted before cloud persistence. Plaintext still exists when a value is displayed, edited, or used:

• Some decrypted record fields can materialize in the Electron renderer while their editor or consumer is active.
• A protocol or connector must receive the resolved secret at the point of authentication.
• A compromised renderer or privileged process may observe values in memory on an unlocked endpoint.
• Putting a secret into a prompt, procedure argument, terminal command, generated file, or recording creates a new exposure outside the Key Chain record.

Use Key Chain references and supported credential-resolution paths. See Vault and keys and Known limits and roadmap for the cryptographic design and remaining plaintext boundaries.

​

Local search and organization memory

The Go agent can chunk supported Studio entities, produce embeddings with the installed local ONNX model, and maintain a local vector index and knowledge graph. Local retrieval can return candidate records without sending the entire local corpus to the model. The selected results can still enter a model prompt when a conversation or tool uses them. Organization work-product memory is a separate cloud-backed, policy-scoped capability. Read Memories and search before assuming that every search or memory path is local-only.

​

Device access and Computer Use

Network diagnostics and device protocols execute with the workstation’s routes and user privileges. Computer Use executes against the workstation’s visible interface after the required OS permissions are granted.

• Studio does not create reachability that the workstation lacks.
• Packet capture, raw-network operations, and interface control may require additional OS permission.
• Screen inspection and state-changing clicks are separate tool effects even though both use the same desktop permission boundary.
• Approval behavior depends on the active response mode and tool policy; Autopilot removes per-call prompts for available tools.

See Browser and Computer Use for operator controls.

​

Terminal recordings

The local agent records supported terminal sessions and exposes them through Session Replays. Recordings preserve command input, output, and timing and can later be archived as Studio files. Recordings can contain passwords typed into a terminal, tokens printed by a command, customer data, configuration, and other sensitive material. There is no reliable semantic redaction at capture time. Control who can access the workstation and any archived file, and avoid entering or printing a secret when recording is active.

​

Calls and shared sessions

Calls use cloud media services and require a signed-in cloud session. Shared terminal sessions combine local device access with a collaboration path to other participants. The owner workstation remains responsible for the live device connection and its local permissions. Review the participant list, interaction role, and resource visibility before sharing. See Shared sessions and Calls and Audio Use for user-facing behavior.

​

Updates and shutdown

The desktop app and Go agent ship as parts of the signed application. An application update can replace both. Signing out unloads organization key state and clears supported cached vault entries, but it does not retroactively remove exported files, terminal recordings, packet captures, or other evidence saved outside that cache.

​

Operator checklist

1. Secure the workstation and OS account before granting broad Studio capability.
2. Install signed updates and review Settings → About when troubleshooting a version mismatch.
3. Grant only the OS permissions required for the current workflow.
4. Keep secrets in Key Chain and resolve them at execution.
5. Treat local recordings, captures, logs, and exported files as sensitive.
6. Verify the organization and channel after switching context.
7. Leave Autopilot off unless targets and external effects are already bounded.

​

Related