infrastructureL1 Ad-hocAgent Runtime & Sandboxing

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 d

·Agents run inside the developer's local IDE (no separate runtime)
·No isolation between agent execution and developer's local environment

·Developers are aware of the security implications of agents with full local access
·Agent access scope (file system, network) is understood even if not restricted

Evidence

·Agent runs as IDE plugin with no containerization or isolation
·No sandboxing configuration exists

What It Is

"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.

Why It Matters

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

Getting Started

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.
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.
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.
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.
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.
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.

Tip

A quick way to reduce exposure without any infrastructure work is to create a dedicated Git identity for agent commits - a separate user with limited repo access. This does not fix filesystem or credential exposure, but it creates an audit trail that separates agent actions from developer actions in the git log.

6 steps to get from here to the next level

Common Pitfalls

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.

Mistakes teams actually make at this stage - and how to avoid them

How Different Roles See It

BobHead of Engineering

Bob has 40 developers using Cursor daily. His security team recently asked him about the AI tooling and he realized he does not have a clear answer for what the agents are doing or what they have access to. He is not aware of any incidents, but he also has no visibility into agent activity. He knows something needs to change but does not know how urgent it is.

What Bob should do: Bob should treat the absence of visibility as the problem, not just the absence of incidents. He should commission a one-day audit where each developer documents what credentials are present in their typical development environment and what the agent has theoretically touched. The aggregated result will almost certainly produce a prioritized risk list that justifies immediate investment in basic Docker sandboxing. Bob should then set a 60-day goal: every agent session runs in a container that does not have access to credentials beyond what the specific task requires.

What Bob should do - role-specific action plan

SarahProductivity Lead

Sarah has been focused on agent adoption rates and productivity metrics. She has not been thinking about isolation because it sounds like a security concern, not a productivity concern. But she is starting to see developers deliberately limit agent autonomy - turning off auto-approve, manually reviewing every command - in ways that cap the productivity gains. When she asks why, developers consistently mention concerns about what the agent might do accidentally.

What Sarah should do: Sarah should reframe isolation as a productivity investment, not just a security requirement. Developers who trust their agent sandbox will give agents more autonomy, which translates directly into higher throughput. Sarah should partner with infrastructure to instrument agent sessions in isolated environments and measure whether autonomous task completion rates increase. The data will almost certainly show that isolation and productivity move together, not in opposite directions. This reframing changes the conversation from "security cost" to "productivity enabler."

What Sarah should do - role-specific action plan

VictorStaff Engineer - AI Champion

Victor has been running agents extensively and has accumulated a collection of near-miss stories: an agent that almost committed a file with a database connection string, a session where the agent used the AWS CLI in a way that would have been problematic if he had not been watching, a case where the agent read from a directory it should not have known about. Victor mentally manages these risks through vigilance, but he knows that vigilance does not scale to the rest of the team.

What Victor should do: Victor should write up the near-misses as a concrete risk document and use it to justify a focused infrastructure sprint. The ask is specific: one week of engineering time to build a Docker-based agent sandbox that mounts only the project directory, excludes home directory credential files, and blocks outbound access to non-approved hosts. Victor should prototype this himself over a weekend, document the developer experience impact (minimal, with the right setup), and present it as a solved problem ready for org-wide deployment. Concrete, working solutions move faster than abstract risk discussions.

What Victor should do - role-specific action plan