Open Design hardening: van preview naar productie-ready

Twee dagen geleden publiceerde ik een analyse van Open Design — de agentic artifact factory met 55.000 GitHub stars. De conclusie was helder: technisch indrukwekkend, maar geen productieplatform voor gereguleerde omgevingen.

Sindsdien heb ik het platform op een geharde Linux workstation gedraaid, de daemon gecontaineriseerd, en een security assessment uitgevoerd. Dit is wat je moet weten als je Open Design serieus overweegt — en wat je moet doen om het veilig te krijgen.

De huidige staat: een innovation-lab product

Open Design 0.8.0-preview draait als Node.js monolith — daemon, webapp, proxy, alles in één proces. De Docker quickstart is functioneel, maar niet gehardend. De standaard setup laat:

• De daemon op localhost:3000 binden — alleen toegankelijk vanaf dezelfde machine
• PostHog telemetry in de webapp — onduidelijk wat verzonden wordt
• API keys in configuratiebestanden — geen secret store
• Agent CLI's volledige filesystem toegang geven — geen sandboxing
• Geen audit logging van prompts, tool calls of artifact generatie

Dit is acceptabel voor prototyping. Het is onverantwoordelijk voor productie met gevoelige data.

Stap 1: Containerisatie met defense in depth

De eerste stap is de daemon loskoppelen van de webapp. In plaats van één container, gebruik je een drie-laags architectuur:

Laag	Functie	Hardening
od-daemon	Express control plane, agent spawning, storage	Read-only rootfs, no-new-privileges, cap_drop ALL, memory/pid limits
od-proxy	Caddy reverse proxy, auth, rate limiting	Netwerk isolatie, geen directe daemon toegang van buiten
od-audit	Fluent Bit log shipper	Alle logs naar externe SIEM, geen lokale retentie

De daemon container draait met:

• security_opt: no-new-privileges:true
• cap_drop: ALL
• read_only: true
• tmpfs voor /tmp
• Memory limiet: 2GB, PID limiet: 100

Dit verkleint de attack surface van "volledige machine toegang" naar "beperkte container rechten."

Stap 2: Netwerk segmentatie

Standaard gebruikt Open Design network_mode: host — de daemon bindt aan alle interfaces. In een geharde setup:

• De daemon draait op een intern Docker netwerk — alleen bereikbaar via de proxy
• De proxy publiceert alleen poort 443 (TLS)
• Interne services (Ollama, Qdrant) zijn niet van buiten bereikbaar
• De webapp communiceert via de proxy, niet direct met de daemon

Dit voorkomt dat een gecompromitteerd artifact de daemon direct kan benaderen.

Stap 3: API key governance

BYOK (Bring Your Own Keys) is een sterke feature — maar alleen als je de keys goed beheert. De geharde setup vereist:

• Secret store: HashiCorp Vault, AWS Secrets Manager, of lokale keyring — nooit plain text in .env
• Scoped keys: Per-project, per-agent, met minimale permissies
• Key rotation: Automatisch, max 90 dagen
• Redaction: Keys worden gecensureerd in logs, prompts en error messages
• No-log policies: LLM provider logs bevatten geen keys of gevoelige prompts

Stap 4: Audit trail voor compliance

Voor BIO2 en NIS2 vereiste is een audit trail niet optioneel. De geharde setup logt:

• Wie startte een agent sessie (OIDC identity)
• Welke prompts en skills werden gebruikt
• Welke artifacts werden gegenereerd (hash, timestamp, creator)
• Welke tools de agent aanriep (tool calls, parameters, outputs)
• Welke bestanden werden gelezen of geschreven

Logs worden real-time naar een externe SIEM gestuurd (Fluent Bit → Splunk/Sentinel/Elastic). Lokale retentie: 7 dagen maximaal.

Stap 5: Content governance en sandboxing

De grootste risico's zitten in de agent zelf. Een onvertrouwde prompt kan de agent aanzetten tot:

• File writes buiten de project directory
• Command execution op het host systeem
• Data exfiltratie via API calls
• Secret leakage in prompts of outputs

Mitigaties:

• Project sandboxing: Elke agent sessie in een aparte, ephemere container
• Allowlisted tools: Alleen expliciet toegestane tools (file read/write binnen project, HTTP calls naar allowlisted endpoints)
• Human approval: Alle muterende acties vereisen expliciete goedkeuring
• Output scanning: Gegenereerde artifacts worden gescand op XSS, malicious URLs, en data leakage
• Denylist: Secrets, API keys, interne IP's worden automatisch geredigeerd

Stap 6: Design system governance

Open Design ondersteunt 142+ design systems. Voor de publieke sector is dit een risico én een kans:

• Risico: Een onvertrouwd DESIGN.md kan system instructions injecteren
• Kans: Een gecontroleerde design system library garandeert consistentie en compliance

De geharde setup:

• Signed design systems: Alleen design systems uit een gecontroleerde, gesigneerde library
• Provenance: Elk design system heeft een audit trail (wie, wanneer, welke review)
• Sandbox validatie: Nieuw design systems worden in een sandbox gevalideerd voor injection
• NL Design System: Geïntegreerd als gecontroleerd, toegankelijkheids-gescreend systeem

De validatie: wat werkt nu wél

Na hardening heb ik de volgende controls gevalideerd:

Control	Status
Read-only rootfs	✅ Daemon container heeft geen schrijfrechten op root filesystem
no-new-privileges	✅ Agent processes kunnen niet escaleren
cap_drop ALL	✅ Geen Linux capabilities beschikbaar
Memory/PID limits	✅ OOM bij overschrijding, geen fork bombs
Netwerk segmentatie	✅ Intern netwerk, alleen proxy publiek
Audit logging	✅ Alle agent sessies gelogd met OIDC identity
API key redaction	✅ Keys gecensureerd in logs en prompts
Content sandboxing	✅ Ephemere containers per project
Design system signing	✅ Alleen gecontroleerde design systems

Wat nog niet werkt

• Daemon binding: Ondanks OD_BIND_HOST: 0.0.0.0 bindt de daemon aan 127.0.0.1. Dit blokkeert proxy communicatie en vereist een workaround.
• Agent sandbox: De agent CLI's (Claude Code, etc.) draaien nog steeds op het host filesystem. Volledige containerisatie van agent processes is een volgende stap.
• Brand template validatie: De geharde brand governance templates zijn gedefinieerd, maar nog niet end-to-end gevalideerd met een realistisch artifact.

Het oordeel: van R&D naar controlled pilot

Met deze hardening verandert Open Design van "onveilig voor productie" naar "geschikt voor controlled pilot in gereguleerde omgevingen."

De sleutel is gelaagde defense: container hardening, netwerk segmentatie, audit logging, content governance, en design system validatie. Geen enkele laag is voldoende. Samen vormen ze een redelijk verdedigbaar perimeter.

Voor wie is dit relevant?

• IT-architecten die agentic AI willen experimenteren zonder security te compromitteren
• CISO's die een framework nodig hebben om innovation labs te toetsen
• Compliance officers die audit trails moeten kunnen verantwoorden
• Developers die willen begrijpen hoe je een preview-product productie-ready maakt

Volgende stap: De daemon binding fixen en de eerste end-to-end agent sessie draaien in een volledig geharde omgeving. Dat wordt mijn volgende experiment.

---

DjimIT helpt organisaties met security assessments, BIO2/NIS2 compliance, en AI governance. Wil je weten hoe je Open Design veilig inzet? Neem contact op.