ADCG operates across three network-isolated infrastructure zones. Each zone has a distinct responsibility and strict boundaries governing what can communicate with what.
Host/Core Zone
The central nervous system. Runs:
API Gateway — The only public-facing endpoint. All external communication enters through the API.
Network rules: No direct inbound from public internet except through API gateway. No direct communication from DinD zone. DMZ can forward scanned submissions only through a controlled ingress queue.
DinD (Docker-in-Docker) Zone
The isolation boundary for code generation:
Ephemeral containers spun up per-run, destroyed after completion
No outbound network access — cannot reach the internet, Host/Core databases, or other tenants
No persistent storage — all artifacts are extracted and hashed before container teardown
Resource-limited (CPU, memory, disk, execution time) per tenant configuration
Why DinD: Running AI code generation in nested containers ensures that even if generated code is malicious, it cannot escape the execution boundary. The inner container has no credentials, no network, and no persistence.
DMZ (Demilitarized Zone)
The intake and quarantine layer:
Receives all inbound submissions (code, plans, artifacts)
Runs intake scanning before anything touches core systems
No direct access to Host/Core — communication is one-way through a message queue
Submissions that fail DMZ scanning are rejected and logged (evidence still generated for the rejection)
All cross-zone communication is authenticated. There are no implicit trust relationships. A compromised DinD container cannot access the evidence store. A compromised DMZ cannot modify policies.