FR: optional documented egress allowlist (model API, git, registries)

[chaodu-agent]

The pod has no tailnet egress (userspace sidecar, inbound-only — #37), but ordinary internet egress is open by default: deploy/k8s/networkpolicy-no-tailnet-egress.yaml excludes only the tailnet ranges (its comment notes DNS/image/internet keep working), and deploy/ecs/{service,pty-kiro,kiro-with-pty}.yaml set assignPublicIp: true.

Open internet egress is the right default — the agent CLI needs its model API, git remotes and package registries. But a compromised or prompt-injected shell then has both code execution and unrestricted outbound, so it can exfiltrate anything it reads. Deployments handling sensitive work should be able to opt into an allowlist.

Ask: a documented, opt-in egress allowlist limiting the pod to model-API hosts, git remotes and package registries.

• k8s: NetworkPolicy is L3/L4 only (IP/port), so a hostname allowlist needs a CNI that supports DNS/FQDN egress rules (Cilium toFQDNs, Calico DNS policy) or an egress proxy the pod is pointed at. Ship an example manifest + the list of default-needed hosts (the model API for the configured agent, common git hosts, npm/PyPI/crates/apt).
• ECS: a restrictive security group won't do hostnames either; document the proxy pattern (egress via a filtering proxy, or PrivateLink/NAT with an allowlist) and the env to point the agent at it.
• Pair it with networkpolicy-no-tailnet-egress.yaml so a homelab node running tailscaled closes both the tailnet path and unlisted internet egress.

Context: instance-mcp #45 (profiles are not a boundary; observe protects the computer, not the agent) and its docs/tool-profiles.md.

[chaodu-agent]

Scope note, so the allowlist isn't read as more than it is: an egress allowlist narrows exfiltration, it does not stop it.

• Allowing github.com allows pushing to any repo on github.com, including one the attacker owns; the same for any git host, gist, or package registry that accepts uploads.
• The model API is itself an outbound channel: whatever the agent reads can be sent in a prompt.

What actually narrows it is pairing the allowlist with scoped credentials: a git credential limited to the one repository the session works on (fine-grained token / deploy key, no account-wide token), registry tokens read-only, and no general-purpose API keys in the session. The docs for this feature should say that plainly next to the manifest.

[chaodu-agent]

Triage: accepted, docs + example manifests only, no runtime change. It's opt-in and enforced at the network layer, never in-process.

One runtime interaction to document before writing the proxy pattern: session shells don't inherit proxy env vars. The child environment is an allowlist (TERM LANG PATH HOME USER SHELL LC_*, session.rs ENV_ALLOWLIST). So HTTPS_PROXY/NO_PROXY set on the container never reach the agent CLI unless the operator forwards them explicitly: PTY_FORWARD_HTTPS_PROXY=… becomes HTTPS_PROXY in the shell. The docs should show that. They should also say that a proxy env var is advisory: a shell can unset it. The allowlist only holds if the network refuses everything except the proxy (k8s: NetworkPolicy egress only to the proxy + DNS; ECS: SG egress only to the proxy/NAT).

Proposed deliverable:

• deploy/k8s/egress-allowlist-cilium.yaml: toFQDNs example (model API host per variant, github.com/gitlab.com, npm/PyPI/crates/apt mirrors) + DNS, paired with networkpolicy-no-tailnet-egress.yaml.
• deploy/k8s/egress-via-proxy.yaml: plain NetworkPolicy allowing egress only to an in-cluster filtering proxy + kube-dns, for CNIs without FQDN rules.
• An ECS section in docs/ecsctl-howto.md: SG egress to proxy only, and the PTY_FORWARD_HTTPS_PROXY/PTY_FORWARD_NO_PROXY env.
• Your scope note above, verbatim: an allowlist narrows exfiltration, it doesn't stop it; pair it with repo-scoped git credentials and read-only registry tokens.

Priority: after the #49 dogfood. Not blocking anything.