You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
No default network-egress policy exists anywhere in this codebase for AMS's sandboxed code execution (confirmed by search — no existing issue or code addresses outbound network policy for tenant/miner execution environments). Competitive research across autonomous coding-agent platforms found default egress posture to be the single biggest practical security differentiator between them, and the platform with the most disclosed security incidents (Devin/Cognition Labs) is also the one with open/unrestricted-by-default egress: a documented prompt-injection chain got it to download and self-execute a C2 malware binary, plus multiple independently-documented secret-exfiltration vectors (curl/wget, URL-appended secrets, remote markdown image rendering, link-unfurling tricks).
Area
Platform / security — AMS execution sandboxing (control-plane/, packages/loopover-engine/src/miner/), directly adjacent to #7180's real driver work.
Proposal
Default AMS's sandboxed execution environments to network-egress-off or a strict allowlist (OS package registries, the target repo's own git remote, language-ecosystem package registries), matching OpenAI Codex's and GitHub Copilot coding agent's approach rather than Devin's open-by-default posture. Both reference implementations explicitly warn this isn't a complete solution on its own (GitHub: "should not be considered a comprehensive security solution") — pair it with not blindly trusting compute/process isolation alone to stop exfiltration, since output-channel vectors (e.g. auto-rendering remote content) bypass network egress control entirely regardless of how tight the allowlist is.
Deliverables
A written decision: default egress posture (off vs. allowlist) and, if allowlist, what's on it by default.
How a repo/tenant can request broader access for a legitimate need (e.g. a project's own third-party API), and what review gate that goes through.
Research citations: OpenAI Codex sandbox docs (network-off by default for the agent phase, allowlist-first proxy when enabled), GitHub Copilot coding agent firewall docs (default-on with curated allowlist), Devin/Cognition enterprise docs ("granting internet access is strongly recommended" — the open-by-default posture whose gap was exploited in a documented August 2025 disclosure)
Boundaries
Policy/mechanism decision, not an implementation of the actual firewall/proxy itself (that's #7180's job once this is decided). No reward/pricing figures.
maintainer-only — security-critical default affecting every tenant's execution environment, not a build task.
Problem
No default network-egress policy exists anywhere in this codebase for AMS's sandboxed code execution (confirmed by search — no existing issue or code addresses outbound network policy for tenant/miner execution environments). Competitive research across autonomous coding-agent platforms found default egress posture to be the single biggest practical security differentiator between them, and the platform with the most disclosed security incidents (Devin/Cognition Labs) is also the one with open/unrestricted-by-default egress: a documented prompt-injection chain got it to download and self-execute a C2 malware binary, plus multiple independently-documented secret-exfiltration vectors (curl/wget, URL-appended secrets, remote markdown image rendering, link-unfurling tricks).
Area
Platform / security — AMS execution sandboxing (
control-plane/,packages/loopover-engine/src/miner/), directly adjacent to #7180's real driver work.Proposal
Default AMS's sandboxed execution environments to network-egress-off or a strict allowlist (OS package registries, the target repo's own git remote, language-ecosystem package registries), matching OpenAI Codex's and GitHub Copilot coding agent's approach rather than Devin's open-by-default posture. Both reference implementations explicitly warn this isn't a complete solution on its own (GitHub: "should not be considered a comprehensive security solution") — pair it with not blindly trusting compute/process isolation alone to stop exfiltration, since output-channel vectors (e.g. auto-rendering remote content) bypass network egress control entirely regardless of how tight the allowlist is.
Deliverables
Resources
Boundaries
Policy/mechanism decision, not an implementation of the actual firewall/proxy itself (that's #7180's job once this is decided). No reward/pricing figures.
maintainer-only — security-critical default affecting every tenant's execution environment, not a build task.