Skip to main content
Workser Code coordinates agents that can read files, run commands and call services. Review the tools and account access you give them, and inspect the available evidence before a production release.

​
What stays local, what goes to the cloud

Choosing a connected coding agent does not mean all project content stays on your machine. Code may be sent to its model provider, synchronized to Workser or included in a deployment. Do not put information into a task or model request unless it is appropriate for that path. The local project folder and third-party CLI credential storage remain on your computer. Workser uses local authentication checks to determine whether a CLI is ready. Complete provider sign-in yourself and keep credentials out of chats, documents and logs.

​
The local daemon

The desktop app runs a local service on loopback, authenticated with a session token. The Workser CLI can use this service to act in the linked project and show activity or approval requests in the desktop UI. A standalone CLI session can instead target the cloud API. It does not have the desktop approval UI. API credentials and server-side scopes still apply; do not treat standalone access as a way around a declined action.

​
Approvals and autonomy

Routine work and approval prompts depend on the agent’s permissions, the run’s autonomy setting and the specific command. Autonomy can cover some actions that would otherwise prompt. The following protected desktop operations require an explicit decision and cannot be granted by the general autonomy setting:
  • Production deployment.
  • Live payment operations.
  • Project database deletion.
  • Neon bucket deletion.
Pressing the desktop button that starts one specific operation can supply that approval; the same decision does not need a second identical prompt. It does not authorize unrelated future operations. Other gated actions include revealing secrets, rotating credentials, changing domains, destructive queries and installing skills. Read the displayed action, resource and destination before approving. A denied or timed-out request must not be bypassed. This short recording shows the release decision in the workspace.

Review the Make it live prompt

​
Owner-only CLI actions

These commands are still refused by the CLI with owner_only (exit code 6):
Create or switch projects and delete environment configuration through the owner UI. Domain management is no longer an owner-only CLI refusal: workser domain add and workser domain rm use domain validation and the applicable approval gate. Reserved Workser and provider hostnames cannot be attached as your custom domain.

​
Roles and tools

A role’s capabilities, tools and the backing agent’s permission mode determine what it can do. Read-only adapters restrict supported review runs, but a role title alone is not a security boundary. Inspect role configuration, connected apps, MCP servers and skills before assigning work. The desktop approval flow applies to desktop operations. Your deployed app must enforce its own user authentication, authorization and confirmations for SDK calls. App connections.

​
Agent Cloud access

Agent Cloud has a separate server-side execution path:
  • Product runs use the agent’s published version. Draft changes affect test runs until you publish them.
  • Project-scoped API keys cannot invoke agents in another project. Reading a run or its event stream also checks organization ownership before returning messages or tool activity.
  • Product agents require a reference for the app user they serve. This creates an attributable session and audit record; it does not replace your app’s own authentication or authorization.
  • Tool calls pass the agent’s capability grants. Protected writes can pause for a person, and the run can return a waiting-for-human outcome.
  • Secrets are stored separately from the versioned agent definition. Artifact downloads use short-lived links.
  • Runtime and spend ceilings can stop work. Cancellation ends an active run but does not erase usage already incurred.
Treat connected actions, MCP servers, workflows and custom sandbox packages as separate trust boundaries. Test unavailable services, denied approvals, expired credentials and partial failures before exposing the agent to users.

​
Credentials

  • Store app credentials in environment or connection settings, not in source code.
  • Never expose a project API key or database URI to a browser or mobile bundle.
  • Treat commands that reveal secrets, such as workser env get and workser db url, as sensitive.
  • Keep secret values out of workser memory add, project documents and answers to workser ask.
  • Review third-party tool and model access separately from Workser account access.

​
Checks and recovery

A successful typecheck or build is evidence about that check, not a guarantee that the app is correct or secure. Test the main flows and review the destination before publishing. A source checkpoint restores project files. It does not reverse a payment, retract an email or restore a deleted production database. Use the relevant service’s recovery procedure for those changes.

​
Platform policies

See the Security Whitepaper, Privacy Policy, Compliance status and Subprocessor List for the platform-wide terms and controls. Contract-specific requirements should be confirmed with Workser.