Primary sources behind the firewall

The devcontainer’s outbound network operates on a default-deny policy: agent tools and background processes can only reach domains explicitly required for building, running, and testing the game. That sandbox protects local keys and limits unexpected external calls, but it created an operational friction point when investigating regulatory requirements. Researching Norwegian localization and accessibility standards from inside the container meant relying on secondary summaries and training data because external government documentation was unreachable. Opening outbound routes for primary regulatory sources resolved that restriction without weakening the sandbox.

Web accessibility under Norwegian law requires meeting explicit universal design standards, while privacy guidelines set strict boundaries around user consent. Relying on secondary articles or secondhand interpretations introduces ambiguity about which rules are statutory obligations and which are informal commentary. Direct access allows agents to consult official statutory portals and design guidelines directly during planning sessions, verifying requirements at the source rather than guessing or citing unverified intermediaries.

flowchart TD
  accTitle: Outbound compliance research through the devcontainer firewall
  accDescr: Outbound network queries from developer and agent tools pass through the devcontainer firewall. Requests to approved primary compliance sources are permitted, while arbitrary outbound internet traffic is dropped by default.

  A["Agent CLIs<br/>(research & planning)"] --> B{"Devcontainer firewall<br/>(default deny)"}
  B -->|Approved compliance documentation| C["Primary regulatory sources<br/>(official documentation)"]
  B -->|Unapproved outbound traffic| D["Dropped traffic"]

  class C accent
  class D muted

Under the devcontainer’s firewall architecture documented in ADR-0028, adding an allowlisted host requires updating two separate scripts at once. A startup script builds the initial address set when the container boots, while a background refresher continuously re-resolves dynamic hosts to keep pace with changing IP addresses. Because the refresher performs a full rebuild and swap rather than an incremental merge, any domain added only to the startup script gets silently dropped on the background refresher’s next cycle. Adding the new documentation hosts required synchronized edits across both files.

The scripts are mounted read-only from the host into the devcontainer, pinning their inodes at startup. As a result, firewall changes cannot be hot-applied mid-session; they require a clean devcontainer restart to rebuild the address tables and relaunch the refresher against the updated bind mounts. With the official portals reachable, the next task is reviewing existing compliance and accessibility notes to verify that earlier decisions align with official regulatory guidance rather than secondary citations.