Agent Permissions, Sandboxes, and Supply Chain Trust
The coding agent did exactly what it was asked to do and one thing nobody noticed it could do: it read a local environment file while debugging a failing integration test. Nothing leaked that day.
Agent permissions are now part of the AI-native SDLC because a coding agent is a tool-using actor inside the development environment, not just a text generator.
The coding agent did exactly what it was asked to do and one thing nobody noticed it could do: it read a local environment file while debugging a failing integration test. Nothing leaked that day. The near miss was enough. The team realized that an autonomous coding assistant is not just a text generator. It is a tool-using actor inside the development environment.
Tool-using AI belongs inside a permission model.
AI-native SDLC security must cover more than generated code quality. It must govern what agents can read, write, execute, install, call, and transmit. As tools gain shell access, repository access, browser access, package-manager access, and issue-tracker access, the development environment becomes part of the attack surface.
Key Takeaways
- A coding agent should have explicit read, write, shell, network, dependency, and release boundaries.
- Prompt injection becomes operational risk when the model can run tools or touch source control.
- Least privilege is an AI productivity feature because it gives teams safe operating lanes.
- Generated dependencies and build changes belong in the software supply-chain threat model.
Research spine
This chapter uses: OWASP LLM01:2025 Prompt Injection; OWASP Top 10 for Large Language Model Applications; SLSA: Supply-chain Levels for Software Artifacts; Anthropic Claude Code Security; NIST SP 800-218, Secure Software Development Framework.
The agent threat model
A coding agent can be influenced by user instructions, repository content, documentation, dependency output, test logs, issue comments, web pages, and error messages. Some of those inputs are untrusted. Prompt injection is therefore not only a chatbot risk; it can become a development-environment risk when the model uses tools.
The threat model should ask: what can the agent observe, what can it modify, what commands can it run, what network calls can it make, and what human approvals are required before consequential actions?
Least privilege for development agents
Development agents should operate under least privilege. A read-only planning mode is different from an edit mode. Editing local files is different from pushing branches. Running tests is different from installing packages. Installing packages is different from publishing artifacts. The permission model should make these boundaries explicit.
Teams should use sandboxes where possible, isolate credentials, prevent access to secrets, restrict network egress for risky tasks, and require human approval for dependency changes, migrations, release steps, and production access.
Supply-chain trust
Generated code can introduce dependencies or build steps. Agents can propose package updates. They can copy snippets. The SDLC must preserve supply-chain trust through dependency review, signed artifacts, reproducible builds where appropriate, and provenance. SLSA is useful not because every team must immediately reach the highest level, but because it gives a vocabulary for improving artifact integrity.
Operating table
| Agent capability | Risk | Control |
|---|---|---|
| Read repository | Exposure of sensitive code or docs | Scoped repository access |
| Edit files | Unsafe modification | Branch isolation and review |
| Run shell commands | Data exfiltration or destructive command | Sandbox and allowlist |
| Install dependencies | Supply-chain compromise | Dependency review and lockfile policy |
| Open network calls | Prompt-injection exfiltration | Egress restrictions |
| Publish/release | Production impact | Human approval and signed artifacts |
Artifact example: a development-agent permission policy
agent_permissions:
modes:
plan:
read_repo: true
write_files: false
run_shell: false
network: false
edit:
read_repo: true
write_files: true
run_shell: ["npm test", "pytest", "go test ./..."]
network: false
dependency_change:
requires_human_approval: true
allowed_commands: ["npm install", "pip install"]
required_checks: ["license_scan", "vulnerability_scan", "lockfile_review"]
release:
agent_allowed: false
requires: ["human_release_manager", "signed_artifact"]
Checklist
- Define modes for AI development agents.
- Restrict shell, network, and dependency permissions.
- Treat repository text as potentially untrusted input.
- Keep secrets outside agent-readable context.
- Use signed artifacts and dependency review for generated changes.
Takeaway
A tool-using coding agent is part of the software supply chain and must be governed like one.
Operational note: Prompt injection becomes operational when tools exist
A model that can only answer text is risky; a model that can run commands changes the threat surface. In the context of Agent Permissions, Sandboxes, and Supply Chain Trust, the practical danger is not that the team lacks effort; it is that effort is aimed at the wrong scarce resource. The AI-native software delivery argument says that the old visible unit of work is no longer the safest unit of management. A team can produce more drafts, more code, more messages, more analysis, or more tickets while becoming less reliable at the point where the business needs a decision. The fix is to move the management surface away from raw output and toward evidence: what was decided, by whom, from which inputs, against which criteria, with what rollback path.
A mature implementation treats this as an operating-system concern rather than a personal-performance concern. The artifact should make the judgment visible: the rubric, acceptance gate, cost line, risk boundary, owner, and expiry date. When those fields are missing, the model's speed hides organizational ambiguity. When they are present, AI acceleration becomes tractable because the team can see which decisions deserve automation, which deserve human review, and which deserve rejection before execution begins.
The useful test is whether a new teammate can replay the decision two weeks later without interviewing the original author. If replay requires folklore, the process is still human-memory-bound. If replay can be done from the artifact, the team has converted judgment into infrastructure. That conversion is the recurring discipline throughout this book: not replacing human judgment, but making human judgment explicit enough that machines can safely do more of the surrounding work.
Field expansion: Least privilege is an AI productivity feature
Clear permissions reduce fear and let teams use agents confidently within safe boundaries. In the context of Agent Permissions, Sandboxes, and Supply Chain Trust, the practical danger is not that the team lacks effort; it is that effort is aimed at the wrong scarce resource. The AI-native software delivery argument says that the old visible unit of work is no longer the safest unit of management. A team can produce more drafts, more code, more messages, more analysis, or more tickets while becoming less reliable at the point where the business needs a decision. The fix is to move the management surface away from raw output and toward evidence: what was decided, by whom, from which inputs, against which criteria, with what rollback path.
A mature implementation treats this as an operating-system concern rather than a personal-performance concern. The artifact should make the judgment visible: the rubric, acceptance gate, cost line, risk boundary, owner, and expiry date. When those fields are missing, the model's speed hides organizational ambiguity. When they are present, AI acceleration becomes tractable because the team can see which decisions deserve automation, which deserve human review, and which deserve rejection before execution begins.
The useful test is whether a new teammate can replay the decision two weeks later without interviewing the original author. If replay requires folklore, the process is still human-memory-bound. If replay can be done from the artifact, the team has converted judgment into infrastructure. That conversion is the recurring discipline throughout this book: not replacing human judgment, but making human judgment explicit enough that machines can safely do more of the surrounding work.
Design consequence: Supply-chain controls are not optional decoration
AI-assisted dependency changes can move faster than old review habits can safely follow. In the context of Agent Permissions, Sandboxes, and Supply Chain Trust, the practical danger is not that the team lacks effort; it is that effort is aimed at the wrong scarce resource. The AI-native software delivery argument says that the old visible unit of work is no longer the safest unit of management. A team can produce more drafts, more code, more messages, more analysis, or more tickets while becoming less reliable at the point where the business needs a decision. The fix is to move the management surface away from raw output and toward evidence: what was decided, by whom, from which inputs, against which criteria, with what rollback path.
A mature implementation treats this as an operating-system concern rather than a personal-performance concern. The artifact should make the judgment visible: the rubric, acceptance gate, cost line, risk boundary, owner, and expiry date. When those fields are missing, the model's speed hides organizational ambiguity. When they are present, AI acceleration becomes tractable because the team can see which decisions deserve automation, which deserve human review, and which deserve rejection before execution begins.
The useful test is whether a new teammate can replay the decision two weeks later without interviewing the original author. If replay requires folklore, the process is still human-memory-bound. If replay can be done from the artifact, the team has converted judgment into infrastructure. That conversion is the recurring discipline throughout this book: not replacing human judgment, but making human judgment explicit enough that machines can safely do more of the surrounding work.
Managerial implication: Prompt injection becomes operational when tools exist
A model that can only answer text is risky; a model that can run commands changes the threat surface. In the context of Agent Permissions, Sandboxes, and Supply Chain Trust, the practical danger is not that the team lacks effort; it is that effort is aimed at the wrong scarce resource. The AI-native software delivery argument says that the old visible unit of work is no longer the safest unit of management. A team can produce more drafts, more code, more messages, more analysis, or more tickets while becoming less reliable at the point where the business needs a decision. The fix is to move the management surface away from raw output and toward evidence: what was decided, by whom, from which inputs, against which criteria, with what rollback path.
A mature implementation treats this as an operating-system concern rather than a personal-performance concern. The artifact should make the judgment visible: the rubric, acceptance gate, cost line, risk boundary, owner, and expiry date. When those fields are missing, the model's speed hides organizational ambiguity. When they are present, AI acceleration becomes tractable because the team can see which decisions deserve automation, which deserve human review, and which deserve rejection before execution begins.
The useful test is whether a new teammate can replay the decision two weeks later without interviewing the original author. If replay requires folklore, the process is still human-memory-bound. If replay can be done from the artifact, the team has converted judgment into infrastructure. That conversion is the recurring discipline throughout this book: not replacing human judgment, but making human judgment explicit enough that machines can safely do more of the surrounding work.
Production implication: Least privilege is an AI productivity feature
Clear permissions reduce fear and let teams use agents confidently within safe boundaries. In the context of Agent Permissions, Sandboxes, and Supply Chain Trust, the practical danger is not that the team lacks effort; it is that effort is aimed at the wrong scarce resource. The AI-native software delivery argument says that the old visible unit of work is no longer the safest unit of management. A team can produce more drafts, more code, more messages, more analysis, or more tickets while becoming less reliable at the point where the business needs a decision. The fix is to move the management surface away from raw output and toward evidence: what was decided, by whom, from which inputs, against which criteria, with what rollback path.
A mature implementation treats this as an operating-system concern rather than a personal-performance concern. The artifact should make the judgment visible: the rubric, acceptance gate, cost line, risk boundary, owner, and expiry date. When those fields are missing, the model's speed hides organizational ambiguity. When they are present, AI acceleration becomes tractable because the team can see which decisions deserve automation, which deserve human review, and which deserve rejection before execution begins.
The useful test is whether a new teammate can replay the decision two weeks later without interviewing the original author. If replay requires folklore, the process is still human-memory-bound. If replay can be done from the artifact, the team has converted judgment into infrastructure. That conversion is the recurring discipline throughout this book: not replacing human judgment, but making human judgment explicit enough that machines can safely do more of the surrounding work.