infrastructureL1 Ad-hocAgent Runtime & Sandboxing

Agent in developer's IDE

At the earliest stage of AI-assisted development, the agent lives inside the developer's IDE - literally running as an extension or plugin within VS Code, Cursor, or JetBrains.

·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

At the earliest stage of AI-assisted development, the agent lives inside the developer's IDE - literally running as an extension or plugin within VS Code, Cursor, or JetBrains. The agent process executes on the developer's laptop, using the developer's local environment: their filesystem, their shell, their credentials, their installed tools. When a Cursor agent runs a terminal command or reads a file, it does so as the logged-in developer, with all the same permissions and access that person has.

This is the path of least resistance. There is no infrastructure to configure, no containers to build, no environments to provision. Install the plugin, connect an API key, and the agent is running. That simplicity is why this pattern is universal at L1 - it matches how developers already work, and it requires zero platform investment from the organization.

The IDE-resident agent model works well for single-file edits, code explanations, and autocomplete. Where it breaks down is when agents start taking broader autonomous actions: reading across many files, running tests, executing shell commands, installing packages. At that point, the agent's scope expands far beyond what the developer intended to hand over, and the shared-environment problem becomes acute. The agent is no longer just suggesting edits - it is acting as the developer, with the developer's full blast radius.

This pattern is not wrong for getting started. It is wrong as a permanent state. Every organization should pass through it, but treating it as the destination is a risk that compounds over time as agents become more capable and more autonomous.

Why It Matters

Zero-friction adoption - developers can start using AI agents immediately without waiting for platform teams to provision environments, making it the fastest path to first value
Full toolchain access - the agent can use every tool the developer has locally: git, npm, make, Docker, cloud CLIs, proprietary internal tools that would take weeks to expose in a controlled environment
No context gap - the agent sees exactly what the developer sees, including local configuration, uncommitted changes, and environment-specific settings that would be missing in a remote sandbox
Reveals the real bottlenecks - running agents in the IDE first shows which tools agents actually need, which permissions matter, and what isolation boundaries would be meaningful before investing in platform infrastructure
Developer trust starts here - developers who use agents in their own IDE build intuition for agent behavior before any organization-wide rollout, creating the internal champions who later drive adoption

Getting Started

Install a capable IDE agent - Cursor and VS Code with the Claude extension are the leading options. Cursor's agent mode (with "yolo" or auto-approve enabled) gives the most representative experience of what autonomous agent operation feels like on a real codebase.
Start with read-only tasks - Before letting the agent write files, use it for codebase exploration: "explain how this module works," "find all callers of this function," "summarize what this service does." Read-only tasks reveal agent capability without risk.
Enable write access incrementally - Move to small, bounded write tasks: fix a lint error, add a test for one function, update a dependency. Keep tasks scoped to single files or small directories where the blast radius of a mistake is minimal.
Audit what the agent accesses - After a few sessions, review what files the agent read, what commands it ran, and what external services it touched. This audit becomes the input for your sandboxing design at L2.
Document the credential exposure - List every credential the agent could theoretically access while running in your IDE: SSH keys, AWS credentials, database connection strings in .env files, cloud CLI tokens. This list is the security debt you will need to address.
Set a graduation criterion - Decide in advance what event triggers moving to isolated environments: first time an agent modifies a file it should not have, first time an agent runs a command with unintended side effects, or simply "after 30 days of use."

Tip

Use your IDE's activity log or terminal history to understand what an agent actually does during a session. Most developers are surprised by how many files agents read beyond the ones they asked about. That breadth is useful context for the agent but represents a wide information exposure surface.

6 steps to get from here to the next level

Common Pitfalls

Treating laptop-resident agents as the permanent architecture. The IDE agent is a starting point, not a destination. As agents become more capable and autonomous, the shared-environment model scales from "minor inconvenience" to "serious security risk." Organizations that never graduate from IDE-resident agents are implicitly accepting that risk indefinitely.

Letting agents access cloud provider CLIs without restriction. When an agent runs in the developer's shell, it inherits the developer's AWS, GCP, or Azure credentials. An agent that reads the wrong file and discovers an IAM role with broad permissions can make cloud API calls that look entirely legitimate in audit logs. This is not theoretical - it is a known failure mode of uncontrolled IDE agents.

Confusing agent capability with agent safety. A Cursor agent that can fix a complex bug in five minutes is impressive. It is also an agent that can delete important files in five minutes if it misunderstands the task. Capability and safety are independent dimensions. IDE-resident agents max out capability (full environment access) while providing zero safety guarantees.

Not auditing agents before scaling adoption. Teams that adopt IDE agents widely without auditing what those agents do end up with a poorly understood blast radius across the whole engineering org. When something goes wrong - and eventually something will - the absence of audit data makes root cause analysis very difficult.

Missing the dependency on developer uptime. IDE-resident agents only run when the developer's machine is on and the IDE is open. Long-running agent tasks that take 30+ minutes are interrupted when the developer closes their laptop. This limitation forces developers into short, interactive sessions rather than the unattended overnight runs that become possible at higher maturity levels.

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

How Different Roles See It

BobHead of Engineering

Bob's team adopted Cursor six months ago and everyone has it running in their IDE. Agents are helping with autocomplete and small refactors. But Bob has started hearing stories: one developer accidentally let an agent push to the wrong branch, another ran an agent that made API calls to a staging database because its connection string was in a local .env file. Bob is not sure whether these are one-off mistakes or signs of a systemic problem.

What Bob should do: Bob should treat these incidents as early signal, not aberrations. They are the natural consequence of running capable agents with no environmental guardrails. Bob should commission a lightweight audit: ask developers to document the three most surprising things an agent did in the last month. The resulting list will reveal the real risk surface and make the case for investing in isolated environments. Bob does not need to stop IDE agents - he needs to start the journey toward sandboxing so that the foundation is in place before a serious incident occurs.

What Bob should do - role-specific action plan

SarahProductivity Lead

Sarah tracks how developers are using AI tools and notices that Cursor usage is high but agent mode (autonomous task execution) is low. Most developers use Cursor for autocomplete and chat, not for multi-step agent tasks. When she asks why, the common answer is "I don't trust it to not break things." That lack of trust is directly connected to the shared-environment model: developers instinctively know that an agent with access to their full environment is risky, so they keep it on a short leash.

What Sarah should do: Sarah should recognize that the developer instinct is correct - the shared environment is risky - and invest in the infrastructure that makes it safe to use agents more ambitiously. Isolated environments (L2 and beyond) are not just a security feature; they are a productivity feature that unlocks the trust developers need to let agents run autonomously. Sarah should calculate the opportunity cost: if 20 developers are constraining agent use because of justified safety concerns, fixing the safety concern is worth significant infrastructure investment.

What Sarah should do - role-specific action plan

VictorStaff Engineer - AI Champion

Victor has been running Claude Code in his IDE for months and has pushed it further than anyone on the team. He uses it for multi-step tasks, lets it run tests, and sometimes runs overnight agent sessions. He is also the person who discovered that the agent once committed a file containing a local API key to a feature branch (caught before push, but still). Victor understands the risks better than anyone because he has hit them directly.

What Victor should do: Victor should document his near-misses and share them with the team without waiting for a formal incident review. His operational experience is the most credible data the organization has about what IDE-resident agents actually do in practice. Victor should also prototype a Docker-based agent sandbox - even a simple one that mounts only the project directory and excludes the home directory - to demonstrate that isolation is achievable without breaking the development workflow. That prototype becomes the proof of concept that justifies the L2 investment.

What Victor should do - role-specific action plan