No isolation

"No isolation" describes the default state at L1: the AI agent runs directly in the developer's working environment with no boundary between the agent's execution context and the developer's full system. The agent process has access to the same filesystem, environment variables, network interfaces, and credentials as the developer. There is no container, no sandbox, no permission boundary of any kind between the agent and the rest of the machine.

This is not a deliberate architectural choice. It is the absence of a choice. When a developer installs Cursor or Claude Code and starts using it, no isolation is the default. The agent runs as the developer, sees what the developer sees, and can do what the developer can do. For early exploration, this is fine. As a long-term operating model for autonomous agents, it is a security liability that grows with agent capability.

The risk profile of no isolation is asymmetric. On most days, nothing goes wrong. Agents fix bugs, write tests, and update docs. But the occasional catastrophic event - an agent that deletes the wrong directory, exfiltrates credentials through an unexpected network call, or corrupts configuration files - is entirely possible and has no guardrail. The longer an organization runs agents without isolation, and the more capable those agents become, the more likely a serious incident becomes.

Understanding what "no isolation" means concretely is the first step toward fixing it. The agent can read ~/.aws/credentials, ~/.ssh/id_rsa, any .env file in any project directory, browser cookie stores, and any secret stored in the system keychain if the developer has granted the terminal access to it. The agent can make outbound network requests to any host the developer's machine can reach. It can write to any file the developer can write to. This is the blast radius of an uncontrolled agent.

• Credential exposure is the highest-severity risk - SSH keys, cloud provider credentials, database passwords, and API tokens are all readable by default, making credential theft via a compromised or misbehaving agent a real attack vector
• Debugging agent mistakes is harder without isolation - when an agent modifies files across the entire filesystem rather than a bounded working directory, reconstructing exactly what changed requires exhaustive diff-checking rather than simply inspecting the isolated environment
• Incident scope is unbounded - an agent mistake in a no-isolation environment can affect not just the current project but any data the developer's account can access, including other repositories, cloud resources, and internal tooling
• Compliance violations become invisible - agents reading files that contain personal data, payment card information, or protected health information create compliance obligations that no one tracks because no one knows the agent touched those files
• Trust ceiling is structurally low - developers who understand the blast radius of no-isolation agents will constrain agent autonomy as a self-protective measure, capping the productivity gains that agents could otherwise deliver

1. Audit your current exposure - Run env | grep -E "(KEY|SECRET|TOKEN|PASSWORD|CREDENTIAL)" in your typical terminal session to see what secrets the agent inherits. Run ls ~/.aws ~/.ssh ~/.config to see what credential files are accessible. This audit creates the baseline for your isolation plan.
2. Identify the highest-risk secrets - From the audit output, identify which credentials would cause the worst outcome if compromised. Cloud provider credentials with broad IAM permissions are typically highest priority. Scope-limited read-only API tokens are lower priority.
3. Restrict the immediate blast radius without full sandboxing - As a short-term measure, use a separate terminal profile for agent sessions that does not load cloud credentials (unset AWS_PROFILE, clear GCP credentials). This reduces exposure without requiring container infrastructure.
4. Review agent session logs - Most IDEs log what commands the agent runs. Review the last week of agent sessions to understand what the agent actually accessed vs. what you intended it to access. The gap will motivate the isolation investment.
5. Set a timeline for moving to Docker-based isolation - No isolation should be a time-bounded state, not a permanent condition. Set a 30-60 day deadline for having basic Docker sandboxing in place for agent sessions.
6. Brief the security team - Security teams are often unaware that AI agents are running in developer environments. Brief them on the current state and your isolation roadmap. Their input on the highest-risk exposure points will sharpen the prioritization.

Assuming the agent will not find credentials it was not told about. Agents that execute shell commands in the developer's terminal have access to the full shell environment. Commands like env, cat ~/.netrc, or reading project configuration files can expose credentials the developer never thought to protect. Agents do not need to be malicious to access these - they encounter them in the course of normal operation.

Treating "the agent has not caused a problem yet" as evidence of safety. The absence of incidents in a no-isolation environment reflects good luck and limited agent autonomy, not a safe architecture. As agents become more capable and run longer tasks, the probability of an incident increases. The no-incident track record is not a reason to delay isolation - it is a reason to invest in isolation before the first incident.

Conflating no-isolation with no-risk for read-only agents. Some teams reason that if the agent only reads files and does not write them, there is no risk. This is incorrect: an agent that reads files can exfiltrate their contents via outbound network calls, include them in its context in ways that leak to the LLM provider's training pipeline, or log them to files that other parties can access. Read access to sensitive files is a risk even without write access.

Delaying isolation investment because it "feels like a future problem." No isolation feels low-risk when agents are running short, interactive tasks. It becomes high-risk when agents start running longer unattended tasks, and by the time that transition happens, the habit of no-isolation is entrenched. The right time to invest in isolation infrastructure is before autonomy scales up, not after.