Enterprise AI
Security
Least-privilege access for coding agents
September 24, 2026 - 2 minute read
Least-privilege access for coding agents starts with the task, not the developer who launched it. An agent fixing a parser should not inherit access to production credentials, unrelated repositories, or unrestricted network destinations. Narrow access reduces the damage from a mistaken command, compromised dependency, or malicious instruction embedded in project content.
The NIST definition of least privilege limits access to the minimum resources needed for assigned tasks. Coding agents add a practical complication because they read files, run processes, call tools, and sometimes write to remote systems within one session. Each path needs its own boundary.
Plan least-privilege access
List the resources the task actually needs. Start with repository paths, build tools, network destinations, credentials, and external systems. Separate read access from write access. A dependency audit may read the whole repository and contact a package registry, while a documentation fix may only need one directory and no network connection.
Use a dedicated machine identity for unattended work. Give it repository access only where the automation runs, and use short-lived credentials when the platform supports them. Keep production deployment rights outside a coding task unless deployment is explicitly part of the approved workflow.
Factory's Droid Exec is read-only by default and adds mutation through explicit autonomy levels. Its --cwd option scopes the working directory, while tool restrictions can narrow the available actions. Those controls make the requested task and granted authority easier to compare.
Enforce least-privilege access
Prompt instructions describe intended behavior, but enforcement belongs below the prompt. Factory's OS-level sandbox can restrict filesystem writes and network destinations. On supported systems, commands run within kernel-enforced boundaries. Denied paths and domains remain unavailable even when repository text asks the agent to reach them.
Enterprise policy should set the upper limit. Factory's managed settings let administrators define autonomy ceilings, command blocks, model policy, sandbox rules, and MCP allowlists. Project and folder settings can add narrower constraints without weakening organization controls.
Review these boundaries before enabling a workflow:
- The working directory contains only the repositories required by the task.
- Write access excludes credentials, personal configuration, and unrelated worktrees.
- Network access is limited to named code hosts, registries, and approved services.
- External tools expose only the operations the workflow needs.
- Remote writes such as pushes, comments, and deployments require explicit authorization.
Separate execution from approval
A coding agent can prepare a change without deciding that the change should ship. Keep branch protection, required checks, and human review in the delivery path. Use a service account so commits and remote actions have a stable identity that differs from the requester.
Log denied actions as well as successful ones. Repeated denials often reveal a task that needs clearer scope or a missing approved dependency. They should lead to a deliberate policy change, not a broad permanent exception.
Least privilege works best when access expires with the task. Remove temporary credentials, discard ephemeral environments, and review reusable automation permissions after scope changes. The result is an agent workflow that can move quickly inside a small, reviewable boundary.
