Skip to content
engineer9 docs

Isolation & sandbox

Your sensitive Slack data stays isolated, and engineer9’s access is default-deny. It can see nothing until you grant access. This page explains the protections that make that true.

What engineer9 can see

Section titled “What engineer9 can see”

By default, engineer9 has access to no channels. An admin adds specific channels, usually project or team channels, and only those are ever read. Anything outside the channels you’ve added is invisible to it. See Channels & access for how to manage this.

Three layers of protection

Section titled “Three layers of protection”

1. Runtime isolation

Section titled “1. Runtime isolation”

Each engineer9 agent runs inside its own isolated sandbox, a dedicated environment for that agent’s execution. Data and compute are isolated per agent, so one agent’s context cannot leak into another’s.

2. Policy

Section titled “2. Policy”

What an agent is allowed to access and which commands it may run are governed by policy: plain, deterministic rules that the model never overrides. Policy is enforced at the platform layer and isolated per agent, so the boundary doesn’t depend on the model “deciding” to behave.

3. Human approval

Section titled “3. Human approval”

Anything destructive or outside the safe set requires a human to approve it first. engineer9 asks the right person in Slack and blocks until they respond. It never runs a sensitive command on its own. See Human approvals for the full flow.

Where your data lives

Section titled “Where your data lives”

engineer9 runs as a managed service, with a dedicated, isolated environment per workspace.

Section titled “Related”