What breaks when organisations let coding agents run with broad file and command access on a laptop or shared workstation?

Broad access removes the last practical checkpoint before destructive actions. A mistaken delete, an overbroad refactor, or a malicious instruction hidden in a file can affect the home directory, local credentials, or unrelated projects. If the environment is not disposable and isolated, the blast radius extends well beyond the task, which makes recovery slower and incident impact larger.

Why This Matters for Security Teams

Broad file and command access turns a coding agent from a helper into an execution path with the same reach as the logged-in user, and often more if credentials, shells, or mounted repositories are present. That creates immediate risk to source code, local secrets, build artefacts, and even adjacent workspaces on a laptop or shared workstation. The issue is not only accidental deletion; it is also instruction smuggling, where a malicious file or repository content influences the agent to act outside the intended task. This is consistent with the concerns highlighted in the OWASP Agentic AI Top 10 and the governance focus of the NIST AI Risk Management Framework. When a workstation is shared, the trust boundary is not a single project folder; it is the whole environment, including browser sessions, cached tokens, and synced storage. In practice, many security teams only discover the problem after a routine refactor has already touched the wrong repository or leaked a credential into a chat, log, or commit history.

How It Works in Practice

The mechanics are straightforward: the agent reads files, interprets instructions, and executes commands with whatever privileges the local account has. If that account can access package managers, cloud CLIs, SSH keys, or secrets stores, the agent can chain those capabilities without a human checkpoint. Good practice is to treat the agent as an untrusted executor and narrow its operating envelope so every action is constrained by task, path, and privilege. Current guidance from the NIST AI Risk Management Framework and the MITRE ATLAS adversarial AI threat matrix points toward containment, traceability, and attack-aware monitoring rather than blind automation.

• Run agents in disposable workspaces or containers with scoped mounts, not in a full user profile.
• Grant command access only to approved tools and wrappers, not a general shell by default.
• Separate source trees, secrets, and personal data so one repository cannot reach unrelated material.
• Require human approval for destructive actions, credential access, and network-relevant commands.
• Log prompts, file targets, and executed commands so unexpected behaviour can be reviewed quickly.

This is also where identity and NHI governance matter: if the agent can reuse local tokens, SSH material, or API keys, it effectively inherits non-human identity authority without controls designed for machine use. The OWASP Non-Human Identity Top 10 is relevant because the agent may act through secrets that were never intended for autonomous execution. These controls tend to break down when developers use long-lived personal laptops with synced home directories, because one compromised session can expose both active work and dormant credentials.

Common Variations and Edge Cases

Tighter agent permissions often increase setup overhead and can slow iterative development, so organisations need to balance speed against containment. Best practice is evolving, and there is no universal standard for exactly how much command access a coding agent should receive on a workstation. For low-risk sandbox tasks, broader read access may be acceptable if the environment is disposable, but that changes quickly once the agent can write to shared folders, invoke deployment tools, or reach external services. The practical boundary is whether the machine contains anything worth protecting beyond the task itself.

Shared workstations are especially tricky because the same local account may hold browser sessions, cloud credentials, or cached repository access for multiple projects. On these systems, even a harmless-looking command can cross into another team’s data. The Anthropic report on AI-orchestrated cyber espionage is a reminder that autonomous tooling can be manipulated into abuse when controls are weak. The right response is not to ban agents outright, but to define where they may run, what they may touch, and which actions always require explicit approval. That distinction becomes critical when local access extends into production credentials or synchronized enterprise storage.

Related resources from NHI Mgmt Group

• What breaks when autonomous coding agents are given broad access?
• What breaks when AI agents are given broad enterprise access without tight governance?
• What breaks when AI agents are given broad access to healthcare systems?
• What breaks when AI agents are given broad standing access?