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

• 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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

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.