infrastructureL1 Ad-hocAgent Runtime & Sandboxing

Agent has access to everything or nothing

At the L1 maturity level, organizations face a binary permission model for AI agents: either the agent has full access to the developer's environment (everything), or access is so

·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 L1 maturity level, organizations face a binary permission model for AI agents: either the agent has full access to the developer's environment (everything), or access is so restricted that the agent cannot do useful work (nothing). There is no middle ground. This binary state is not a design decision - it emerges from the absence of any access control infrastructure. Without the ability to define scoped permissions, teams default to one of two extremes.

The "everything" side of the binary is the more common path. Teams give agents full access because it is the path that makes agents useful immediately. The agent can read any file, run any command, use any installed CLI tool. This maximizes what agents can do today while deferring the security question indefinitely.

The "nothing" side is what happens when security concerns override productivity concerns. The agent is locked down so tightly - no file access beyond the current file, no terminal execution, no external integrations - that it becomes a sophisticated autocomplete tool rather than an autonomous agent. Teams that end up here are often reacting to a security policy rather than engineering a thoughtful permission model.

The fundamental problem with the binary model is that both extremes are wrong. "Everything" creates unacceptable security risk as agents become more capable. "Nothing" forfeits the productivity gains that justify the AI investment. The path out of this binary is granular, task-scoped permissions - which requires infrastructure investment that does not exist at L1. Recognizing this binary as a structural problem, not a temporary inconvenience, is the first step toward building the permission model that enables safe, high-autonomy agents.

Why It Matters

Binary access creates a permanent productivity ceiling - developers who recognize the security risks of "everything" self-limit agent autonomy, and developers who have only "nothing" cannot use agents for complex tasks at all
Security teams reject everything-or-nothing - when security reviews AI tooling and sees the binary model, the common outcome is restriction rather than enablement; fine-grained permissions are the negotiating lever that prevents blanket lockdowns
Incident blast radius is tied to access scope - an agent with scoped access to one repository can make mistakes within that scope; an agent with everything-access can make mistakes anywhere the developer has access
Compliance requirements assume least-privilege - SOC 2, ISO 27001, and most security frameworks require least-privilege access; the everything model is structurally incompatible with these requirements
The binary model blocks multi-agent architectures - when you want to run 5 parallel agents with different roles, you need different permission profiles for each; the everything-or-nothing model makes this impossible to manage safely

Getting Started

Map the access you actually need - For each agent use case in your team (code editing, test running, dependency updates, documentation), list the specific file paths, commands, and external services that use case genuinely requires. This becomes your target permission model.
Implement directory-scoped access as a first step - The simplest escape from the binary model is directory scoping: agents get access to a specific project directory and nothing outside it. In practice this means mounting only the project directory in the agent's sandbox, not the home directory.
Separate read and write permissions - Create distinct agent modes: read-only (for exploration and analysis tasks) and read-write (for implementation tasks). Read-only mode is much lower risk and can be granted more broadly. This is a two-level permission model, which is already better than binary.
Enumerate which external services agents need - API keys for services like GitHub, Jira, and Slack are necessary for some agent workflows. List each one and scope the credentials: a GitHub token that can only read a specific repo is far better than a token with org-wide write access.
Document the exceptions - There will be cases where an agent genuinely needs broader access. Document them explicitly: which agent, which task, why broader access is required, and when that broader access should be reviewed. This discipline prevents exception creep.
Set a 90-day milestone for scoped credentials - Within 90 days, every agent credential in use should be documented, scoped to the minimum necessary access, and stored in a secrets manager rather than a .env file. This is achievable without significant infrastructure investment.

Tip

The "principle of least privilege" for agents is not just a security principle - it is a debugging tool. When an agent runs with scoped access and something goes wrong, the investigation is bounded. When an agent runs with everything access and something goes wrong, the investigation could involve any system the developer has access to.

6 steps to get from here to the next level

Common Pitfalls

Confusing "the agent has not misused access" with "the agent has appropriate access." An agent that has run successfully with everything-access for three months has not demonstrated that everything-access is correct. It has demonstrated that nothing has gone wrong yet. The access model should be designed for the worst plausible agent behavior, not the average agent behavior.

Implementing nothing-access as the security answer. Organizations that respond to AI agent security concerns by heavily restricting agent access are solving the wrong problem. The goal is not minimum agent capability - it is minimum agent access for the capability you want. Scoped access that enables productive agents is the target, not locked-down agents that cannot do useful work.

Letting different teams develop different permission practices. Without a platform-level permission model, different teams will make different decisions: some will give agents everything, some will give nothing, and neither will be intentional. The result is an organization with inconsistent security posture and no way to audit what agents can actually do.

Treating scoped credentials as a one-time setup. Permissions granted to agents today will become incorrect as the codebase evolves, as agents take on new task types, and as security requirements change. Scoped credentials need periodic review - at least quarterly - to ensure they still match actual need.

Not including agents in access reviews. Most organizations have processes for reviewing human employee access (e.g., SOC 2 access reviews). AI agents should be included in these reviews with the same rigor. An agent credential that outlives its use case is a forgotten attack surface.

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

How Different Roles See It

BobHead of Engineering

Bob's team is split: half are using agents with full environment access and are productive but exposed, the other half have been told by the security team to restrict agent access and are frustrated because restricted agents cannot do useful work. Bob is caught between the two groups and is not sure how to reconcile them.

What Bob should do: Bob should frame the problem correctly to both groups. To the "everything" camp: the security team is right that unconstrained access is a problem, but blanket lockdown is the wrong solution. To the "nothing" camp: the productivity team is right that restricted agents do not deliver value, but that does not mean everything-access is acceptable. Bob should sponsor a joint working group - one productivity engineer, one security engineer - with a 30-day mandate to define a permission model that enables productive agents with scoped access. That working group produces the policy that replaces the binary.

What Bob should do - role-specific action plan

SarahProductivity Lead

Sarah has been trying to drive agent adoption but keeps hitting the same blocker: security policy restricts agent access to the point where agents cannot run tests, cannot read across modules, cannot access the APIs they need. Every time she tries to expand agent use cases, security flags the expanded access request. She feels stuck between productivity and compliance.

What Sarah should do: Sarah should invest time in understanding what security is actually worried about, specifically. In most cases, security's concern is not "agents should not run tests" - it is "agents should not be able to exfiltrate credentials" or "agents should not be able to write to production systems." These are solvable problems with scoped credentials and network isolation. Sarah should propose a threat model exercise: list the actual security scenarios that concern the security team, then design the permission model that blocks those scenarios without blocking productive agent work. This converts a binary debate into a technical design problem with a solution.

What Sarah should do - role-specific action plan

VictorStaff Engineer - AI Champion

Victor has been running agents with everything-access because it is the only way to do the complex multi-step tasks he uses agents for. He knows this is not right architecturally, and he has been thinking about what a better permission model would look like. He has sketched out a per-task credential system where each agent gets a unique set of scoped credentials generated at task creation time and revoked when the task completes.

What Victor should do: Victor should build the prototype of the per-task credential system. The core of it is not complicated: a script that creates a scoped GitHub token with access to a specific repo, an AWS role with access to a specific S3 bucket, and a Jira token with access to a specific project, bundles them into environment variables, launches an agent with those variables, and revokes them on exit. This prototype demonstrates that fine-grained permissions are operationally feasible. Victor should present it as infrastructure the platform team should own, with his prototype as the proof of concept.

What Victor should do - role-specific action plan