SafetyCard Request a review

Sim

Workspace to build, deploy and monitor AI agents and workflows

github.com/simstudioai/sim · 2026-10-03 · 165e117

Defense-in-depth score

3.8 / 10

Sim has strong engineering below the agent layer: a V8-isolate code sandbox with a scrubbed environment, DNS-pinned SSRF protection on every tool request, credential authorization in code, and secret redaction before logs and the model. The agent layer has no human approval for tool calls, nothing limits what an agent does after reading untrusted content, and deployed chats are public by default while running with the owner's credentials. Model-written code receives every workspace secret along with open internet egress. As shipped by compose, server telemetry also exports logs, including tool error payloads, to the vendor.

Safest setup

Sim already runs model-written JavaScript in a separate V8 isolate, checks every tool request against private and metadata addresses, and redacts secrets from logs and model input. The agent layer itself has no approval step and deployed chats start out public, so the safest setup narrows credentials, locks down chats and secrets, and turns on the limits Sim offers as settings.

SetupHowWhat it gives you
Narrow connected accountsConnect only the integrations each workflow needs, using dedicated accounts that hold just the data and rights that workflow usesThe provider itself limits what a run can read or change, whoever started it C1
Chat access controlSet each deployed chat's authType to sso, email or password in place of publicOnly people you chose can start runs that use the owner's credentials C5
Selected secrets onlySet secretScope to selected and list just the needed names in mountedSecrets on each function block an agent can callModel-written code sees only the secrets its task needs C4
A Human review stepPlace a Human block before workflow steps that send, post or change records, and keep those actions as their own workflow blocksA signed-in workspace member reviews the run before those steps go ahead C2
Approved MCP domainsSet ALLOWED_MCP_DOMAINS to the domains of the MCP servers you trustWorkspace members can add MCP servers only from those domains C7
Run time limitsSet EXECUTION_TIMEOUT_FREE and EXECUTION_TIMEOUT_ASYNC_FREE in the environmentEvery self-hosted run ends after a fixed time C10
Server telemetry offSet NEXT_TELEMETRY_DISABLED=1 in the compose environment, as the Helm chart doesLogs and traces, tool error payloads included, stay on your own servers C8
Limited outbound networkRun the Sim app container with outbound access limited to the model providers and services your workflows useA narrow path for data to leave, around HTTP tools and model-written code alike C5

Approving with confidence

  • A Human block shows only the fields its author chose, so include the exact recipients, URLs or records the next step will act on.
  • Tool calls inside an Agent block run without a pause, so attach only the tools that step needs.

Handling data

  • Run logs keep each tool call's arguments and results; give workspace access to people who may see that data.
  • Connected OAuth tokens are stored in the database, so protect the database and its backups like the accounts they reach.

Key gaps (3)

  1. Agent block tool calls, including code execution, generic HTTP, SSH and email send, run with no approval gate in the default configuration. C2 · Approval gates
  2. A hijacked agent can exfiltrate data and take irreversible actions unattended; public-by-default chat deployments and inbound triggers start runs that use the owner's write credentials. C5 · Untrusted input blast radius
  3. Model-written function code receives every workspace secret by default together with a fetch() that reaches any public host. C4 · Code-execution isolation

Criteria

C1 Identity & least privilege

0.45 / 1.00

Workflows act with the OAuth grants and API keys that workspace members connect, chosen per tool block. Before any token is attached, a deterministic check confirms the credential belongs to the workflow's workspace and that the acting user may use it, and service-account tokens are minted with only the scopes the tool declares. OAuth grants are still broad, though. Gmail asks for modify and send, Drive for full access, and one grant serves both reads and writes. Deployed runs act as the workflow owner whoever triggered them, so a public chat user borrows the owner's authority.

C2 Approval gates

0.15 / 1.00

The Agent block's tool loop runs every tool the model calls, including email sends, HTTP requests, SQL and SSH commands, with no approval step. The platform offers a Human-in-the-Loop block that pauses a workflow until an authenticated workspace member resumes it. The workflow author has to place it, and it cannot stop an individual tool call inside an Agent block. Copilot chat has per-tool approvals, but only when an operator sets COPILOT_TOOL_PERMISSIONS_ENABLED, and they are skipped for non-interactive runs.

C3 Tool & action scoping

0.50 / 1.00

Tools have typed parameter schemas, and parameters marked user-only (hosts, passwords, secret scopes) are stripped from model arguments in code. Every external tool request passes through a shared check that resolves DNS, blocks private and metadata addresses, pins the IP and rechecks redirects. Several tools are still general-purpose, though: HTTP requests to any public URL, model-written code, SQL whose statement check also allows INSERT, UPDATE and DELETE, and SSH commands. Agents receive only the tools their author attaches, but each of those tools reaches far.

C4 Code-execution isolation

0.53 / 1.00

Model-written JavaScript runs in an isolated-vm V8 isolate inside a separate Node worker process whose environment is cut down to an allowlist, with a 128 MB memory limit and timeouts. Python and shell are refused unless a remote E2B or Daytona sandbox is configured, so there is no fallback to running code on the host. However, by default the isolate is given every workspace secret and a fetch that reaches any public URL. Code the model writes can therefore send those secrets anywhere. SSH and SQL tools also run model-written commands on remote systems with no sandbox.

C5 Untrusted input blast radius

0.25 / 1.00

Workflows are built to read untrusted content: 78 trigger integrations (inbound email, chat, webhooks), web and HTTP tools, and knowledge-base connectors. Chat deployments are public by default. Tool results reach the model as ordinary tool messages, and only compacted conversation summaries are labelled as untrusted data. Nothing in code limits what a hijacked agent can do after reading untrusted content. It can leak secrets through HTTP or code, send email, and delete records, all while acting with the owner's credentials and with no human involved.

C6 Memory, context & configuration integrity

0.20 / 1.00

Agent memory is off by default. When enabled, conversations are stored per workspace under an ID the workflow author chooses, and replayed as history. Agents can also be given tools that write to workspace-wide knowledge bases and memory, which later runs and other users retrieve. Writes are not validated or reviewed, and only compacted summaries are labelled as untrusted. A poisoned entry can therefore keep steering tool use in later sessions and for other users of the workspace.

C7 Third-party extensions

0.40 / 1.00

Sim does not run third-party extension code in its own process. MCP servers are reached only as remote HTTP endpoints, and nothing is launched locally. A workspace member adds each server by URL, and a malicious server gets only the arguments and headers sent to it. Servers are not pinned or verified, however. Any domain is allowed unless the operator sets ALLOWED_MCP_DOMAINS, and tool lists are re-fetched, with only schema changes flagged.

C8 Secrets & sensitive-data protection

0.38 / 1.00

Workspace secrets are encrypted with AES-256-GCM. A provenance system replaces resolved secret values with [REDACTED_SECRET] in model-bound content, traces and tool logs, and the code worker gets a scrubbed environment. OAuth access and refresh tokens, however, sit in plaintext in the database. The shipped compose file also leaves server telemetry on: it exports traces and every log line, including tool error payloads, to telemetry.simstudio.ai. Model-written function code receives all workspace secrets by default.

C9 Audit & traceability

0.50 / 1.00

Every workflow run is recorded in Postgres with its trigger type and trace spans, including each tool call's arguments and results (size-bounded), and credential use and platform changes go to a separate audit log. These records are written by the platform, not by the model. The audit log is fire-and-forget, though, and per-block progress is kept in Redis and written once when the run ends. A crash can therefore lose the record of actions already taken. There is no tamper-evidence, and the record does not separate the person who triggered a run from the owner whose credentials it used.

C10 Limits & kill switch

0.40 / 1.00

An Agent block makes at most 20 tool round-trips, nested workflow calls stop at depth 25, and loops and parallel branches have default caps. Cancelling a run passes an abort signal down to in-flight tool calls and code execution. On a self-hosted install with billing disabled (the default), though, workflow runs have no wall-clock limit. There is also no token or spend ceiling, so a runaway workflow or schedule can keep calling paid models and tools.