Convenience-first defaults don't scale down on their own
90% of professional developers use AI coding agents at work at least weekly as of mid-2026, and the shift from suggestion-only copilots to autonomous agents that research, act, and iterate has made the question of what access an agent actually holds newly material — an agent that can run shell commands, install dependencies, and touch infrastructure is a meaningfully different risk surface than one that only proposes text changes for human approval.
Why "just give it full access" is the common but wrong default
Teams setting up an agent for the first time often grant broad access to avoid friction during onboarding — full shell, unrestricted network, standing production credentials — and rarely revisit that grant once the agent is working, even after the specific task it was set up for no longer requires that breadth.
What "task-appropriate scope" actually looks like
- Frontend-only work needs component and page-level file access, no shell, no network, no credentials.
- Backend/API work needs route and lib-level file access, a sandboxed (not full) shell for local testing, and at most a scoped credential — never a full production key.
- Infrastructure and data-migration work genuinely needs broader reach, but still benefits from a sandboxed shell and scoped credentials rather than standing full access.
Why blast radius, not just "is this agent trustworthy," is the right frame
The relevant question isn't whether a given agent run will misbehave — it's what becomes reachable if a single generated command, misdirected action, or exploited prompt does something unintended. A narrowly scoped agent limits that reachable set regardless of why the unintended action happened; a broadly scoped one doesn't, even if it behaves correctly 99% of the time.
Revisiting scope as tasks change
An agent's access level is easy to set once and forget — but a scope granted for an early infra-setup task, still active once the agent has moved on to routine frontend work, is exactly the kind of drift a periodic scope check is meant to catch.
Frequently Asked Questions
The relevant question is what becomes reachable if a single action goes wrong for any reason — a narrowly scoped agent limits that reachable set regardless of the cause, while a broadly scoped one doesn't, even if it behaves correctly the vast majority of the time.
Component and page-level file access is typically sufficient — no shell access, no network egress, and no credentials, since UI work doesn't require any of the three.
Many backend and full-stack tasks genuinely need to run commands (installing a package, running a test) that 'no shell' would block, but a full unsandboxed shell grants far more reach than that task needs — a sandboxed, ephemeral shell covers the legitimate need without the excess.
No — scope tends to drift as an agent's actual task changes over time (for example, moving from initial infra setup to routine frontend work), so a periodic scope check against the agent's current task is worth doing rather than a one-time setup decision.
No. All calculation happens locally in your browser — nothing about your agent setup or access configuration is uploaded or logged anywhere.