Notifications
Clear all
Topic starter
18/08/2026 2:25 pm
TL;DR: AI code agents that only propose diffs are unreliable because they cannot actually run linters, tests, or service-specific toolchains, according to Edge Delta. The governance shift is to treat code-producing agents like engineers with controlled execution, not text generators with commit access.
NHIMG editorial — based on content published by Edge Delta: Why AI code agents need real execution sandboxes, not diff suggestions
Questions worth separating out
Q: How should security teams govern AI agents that can read tickets and open pull requests?
A: Treat the agent as a governed non-human identity with separate permissions for reading, analysing, and writing.
Q: What breaks when an AI coding agent can suggest diffs but never run them?
A: The agent loses contact with the real toolchain, so it cannot detect dependency drift, broken tests, stale imports, or environment-specific failures.
Q: How do security teams know if an AI agent sandbox is actually working?
A: A working sandbox should stop execution, block privilege expansion, and prevent the agent from touching sensitive context even when the model is manipulated.
Practitioner guidance
- Separate execution from repository mutation Allow agents to edit only in ephemeral sandboxes, then move accepted changes through a trusted host-side GitHub API path that creates the branch, commit, and pull request.
- Require validation before promotion Make linting, type-checking, dependency installation, and tests mandatory in the sandbox before any code change can be considered for review.
- Bind agent actions to bounded workspace policy Enforce file-count, file-size, and total workspace caps so an AI agent cannot expand its change set beyond the reviewed execution boundary.
What's in the full article
Edge Delta's full article covers the implementation detail this post intentionally leaves for the source:
- The exact sandbox toolchain layout and per-turn container setup used to run code safely
- The host-side GitHub API sequence that turns verified edits into commits and pull requests
- The checkpoint, restore, and filesystem snapshot approach used to resume agent sessions without re-cloning
- The artifact upload guardrails that prevent symlink-based data exfiltration from the workspace
👉 Read Edge Delta's analysis of sandboxed AI code execution for repository changes →
AI code agents and sandboxed execution: what teams need to govern?
Explore further
18/08/2026 3:15 pm
AI code agents are effectively non-human identities, and they need the same governance discipline as any other privileged automation. The article shows that an agent able to read repositories, run tooling, and open pull requests is not just a developer aid. It is a software actor with delegated access to code and build systems. That makes identity, authorization, and execution boundary design central, not optional, for any team allowing agentic code changes.
A question worth separating out:
Q: What is the difference between sandboxed execution and trusted repository mutation?
A: Sandboxed execution is where the agent reads files, runs tools, and tests changes in an isolated workspace. Trusted repository mutation is the separate step where a controlled host process creates commits, branches, or pull requests. Keeping those paths distinct prevents the model from directly steering source-of-truth state.
👉 Read our full editorial: Why AI code agents need real execution sandboxes, not diff suggestions
