Design setupu AI-agentní vývojové organizace

Finální návrh pro malou organizaci, která bude primárně vyvíjet aplikace pomocí AI agentů na oddělených HW uzlech. Návrh počítá s prostředím Ubiquiti/UniFi, Synology NAS, Mac/PC vývojářskými stanicemi a postupným přidáváním dalších agentních serverů.

Veřejná URL dokumentu: https://132.164.99.216:8443/ai-agent-org/ai-agent-org-setup-design.md

Rychlé shrnutí pro rozhodnutí

Doporučený směr je nebrat agentní HW jako běžné firemní počítače, ale jako polodůvěryhodnou výpočetní vrstvu. Agenti mají mít vlastní fyzické porty, vlastní VLAN, omezený přístup na Synology NAS jen přes konkrétní sdílené složky, per-agent účty, egress přes proxy/logování a žádný přímý přístup do DEV/MGMT sítí.

Tři úrovně implementace

Nejkritičtější pravidla

1. Agentní HW fyzicky oddělit: vlastní porty, ideálně vlastní lab switch, označení a evidence.
2. Logicky oddělit: LAB VLAN nesmí iniciovat spojení do DEV ani MGMT.
3. NAS zpřístupnit agentům jen přes datovou IP a jen na přesně povolené shares.
4. Zdroje a datasety pro agenty držet read-only; zápis povolit jen do vlastního workspace, artefaktů a append-only logů.
5. Nepoužívat jeden sdílený účet aiagent; každý uzel/projekt má vlastní identity.
6. Secrets nedávat na NAS ani do workspace; používat krátkodobé tokeny a externí secrets manager.
7. Každá změna produkčního kódu jde přes Git PR, CI a review.
8. Internetový provoz agentů časem převést přes proxy/allowlist a logovat.
9. Snapshoty a restore testy nejsou volitelné; jsou hlavní obrana proti chybě agenta i ransomwaru.
10. Onboarding nového agentního uzlu musí být checklist, ne ad-hoc akce.

Syntéza parent research výstupů: UniFi segmentace, Synology NAS design, HW/compute design, AI-agentní vývojový workflow a threat model. Návrh je určen pro malou organizaci, která bude primárně vyvíjet aplikace pomocí AI agentů na oddělených HW uzlech.

1. Cíle a předpoklady

Cíle

1. Fyzicky a logicky oddělit agentní HW od běžných Mac/PC stanic.
2. Umožnit řízený, auditovatelný a minimální přístup agentů ke sdíleným datům na Synology NAS.
3. Zabránit laterálnímu pohybu z kompromitovaného agentního uzlu do uživatelské, management nebo NAS admin zóny.
4. Připravit škálovatelný model pro další servery: miniPC, Mac mini/Studio, GPU server, VM hosty.
5. Nastavit provozní model pro agentní vývoj: Git, PR review, CI runner izolace, artefakty, logy, secrets a incident response.
6. Zachovat pragmatickou provozovatelnost pro malý tým: začít jednoduše, ale s jasnou cestou ke zpřísnění.

Předpoklady

2. Logická architektura

Základní princip: agenti jsou nedůvěryhodná výpočetní vrstva. Smí číst schválená data, zapisovat jen do vlastních pracovních prostorů a komunikovat ven pouze přes kontrolované brány.

Zóny důvěry

3. Fyzická architektura

Doporučený cílový model:

Doporučení

4. VLAN/IP plán

Použít jeden interní blok, např. 10.60.0.0/16. VLAN 1 nepoužívat pro produkční provoz. Třetí oktet držet podobný VLAN ID, kde to dává smysl.

IP defaulty

Příklady statik: NAS-DATA 10.60.30.10, NAS-MGMT 10.60.10.10, bastion 10.60.10.20, monitoring 10.60.10.30, proxy 10.60.10.40, agent-node-01 10.60.40.11.

5. Firewall matice

Výchozí politika: deny inter-VLAN. Povolit established/related návratový provoz, DNS/DHCP/NTP jen na určené interní služby a explicitní aplikační prostupy.

Konkrétní pravidla, pořadí shora dolů

6. UniFi nastavení

Networks

V UniFi Network vytvořit samostatnou síť pro každou VLAN:

Port profily

Wi-Fi/SSID

UniFi skupiny objektů

Vytvořit IP groups: NET-MGMT, NET-DEV, NET-NAS, NET-LAB, NET-SANDBOX, NET-IOT, NET-GUEST, NAS-DATA-IP, NAS-MGMT-IP, ADMIN-CLIENTS, BASTION, PROXY, SECRETS, MONITORING, RFC1918.

Vytvořit port groups: DNS, DHCP, NTP, WEB, SSH, SMB, NFSV4, SYNOLOGY-DSM, GIT, METRICS, SYSLOG.

7. Synology NAS nastavení

Shared folders

Vytvořit samostatné Btrfs shared folders. Nepoužívat jednu velkou složku data.

Skupiny a účty

Servisní účty vytvářet per uzel a účel, ne jeden sdílený účet aiagent:

svc-agent-node01-ro
svc-agent-node01-ws
svc-agent-node01-logs
svc-agent-node02-ro
svc-agent-node02-ws
svc-ci-builder01
svc-dataset-publisher

Protokoly

Snapshoty, WORM, backup

8. Agent HW onboarding

Každý nový agentní uzel musí projít opakovatelným onboardingem. Cílem je, aby kompromitace jednoho uzlu neznamenala kompromitaci NAS, Git hostingu nebo ostatních agentů.

Onboarding checklist

9. Bezpečnostní model

Hlavní hrozby

Policy brány pro agentní vývoj

Secrets model

1. NAS není aktivní secrets manager pro agenty.
2. Dlouhodobé secrets držet v 1Password/Vault/SOPS/age, přístup přes krátkodobé tokeny.
3. Per-agent a per-projekt identity; žádné sdílené klíče.
4. Secrets nikdy neukládat do 30_agent_workspaces, repozitářů, logů ani artefaktů.
5. Po incidentu rotovat všechny tokeny daného uzlu/projektu.

10. Provozní postupy

Denní/týdenní provoz

Incident runbook: kompromitovaný agentní uzel

1. V UniFi přepnout port do PORT-QUARANTINE nebo vypnout port.
2. Zablokovat servisní účty svc-agent-nodeXX-* na NAS.
3. Revokovat Git/CI/secrets tokeny daného uzlu.
4. Zachovat disk/logy pro forenziku, neprovádět destruktivní reinstalaci před exportem důkazů.
5. Zkontrolovat NAS audit: přístupy, mazání, velké čtení/zápis.
6. Zkontrolovat proxy/DNS logy: neobvyklé domény, objemy dat.
7. Obnovit data ze snapshotu jen pokud je potvrzen tampering/ransomware.
8. Re-onboarding uzlu provést jako nový HW, ne z původních credentials.

Git/CI workflow default

11. Roadmapa implementace

Fáze 0: okamžité minimum, 1-3 dny

Fáze 1: dobrý základ, 1-2 týdny

Fáze 2: zvýšení bezpečnosti, 2-6 týdnů

Fáze 3: škálování, průběžně

12. Varianty

13. Otevřené otázky

1. Jak citlivá budou data na NAS: zákaznická PII, zdrojové kódy, interní know-how, veřejná data?
2. Budou agenti používat cloud LLM/API, lokální modely, nebo hybrid?
3. Který Git hosting bude primární: GitHub Cloud, GitLab self-managed, Forgejo/Gitea?
4. Má Synology dost NIC/VLAN podpory pro oddělení DSM admin a datových služeb?
5. Bude potřeba GPU server a jak bude řešena jeho fyzická bezpečnost, chlazení a spotřeba?
6. Jaká je tolerovaná míra friction: přísný allowlist vs pragmatický monitorovaný egress?
7. Kdo bude vlastníkem datové kurace a publikace do *_ro shares?
8. Kdo schvaluje agentní změny dependencies a produkční deploye?
9. Jak dlouho se mají držet agent logs a proxy logs?
10. Existuje požadavek na compliance, audit, zákaznické NDA nebo geografické omezení zpracování dat?

14. Doporučené defaulty pro první implementaci

1. Startovat s VLAN plánem 10.60.0.0/16, nepoužívat VLAN 1.
2. Agentní stroje jen kabelově do PORT-AGENT-NODE; Wi-Fi agenty nepoužívat.
3. Firewall: deny LAB -> DEV/MGMT, deny DEV -> LAB, povolit LAB -> NAS jen SMB/NFS na NAS-DATA-IP.
4. NAS: 10_sources_ro, 20_datasets_ro, 30_agent_workspaces, 40_build_artifacts, 50_agent_logs jako minimum.
5. Per-agent servisní účty: svc-agent-nodeXX-ro/ws/logs.
6. Snapshoty zapnout hned; immutable/WORM přidat pro kritická data ve fázi 2.
7. Secrets ukládat mimo NAS, nepředávat agentům dlouhodobé klíče.
8. Všechny agentní změny do kódu přes PR + CI + review.
9. Logovat UniFi firewall, NAS audit, proxy egress a agent runtime.
10. Každý nový agentní uzel projde onboarding checklistem a testem firewall deny pravidel.

15. Minimální setup: bezpečný start bez zbytečné složitosti

Cíl minimálního setupu je rychle zavést nejdůležitější izolační hranice bez toho, aby malý tým musel hned provozovat enterprise stack. Minimum není finální bezpečnostní stav; je to kontrolovaný první krok.

Minimální topologie

Minimální VLAN/subnet plán

Minimální firewall pravidla

Minimální NAS struktura

Minimální checklist před prvním agentem

• [ ] VLAN 10/20/30/40/99 existují v UniFi.
• [ ] Agentní port je access port jen do VLAN 40.
• [ ] Nepoužité porty jsou disabled nebo v QUARANTINE VLAN 99.
• [ ] Firewall blokuje LAB-AGENTS -> DEV a LAB-AGENTS -> MGMT.
• [ ] NAS má samostatné shares pro sources, datasets, workspaces, artifacts a logs.
• [ ] Existuje per-agent servisní účet, ne sdílený účet.
• [ ] Snapshoty jsou zapnuté alespoň pro sources, datasets, artifacts a logs.
• [ ] První agent prošel testem: nedostane se na DEV/MGMT, dostane se jen na povolené NAS shares.

16. Doporučený setup: cílový baseline pro malou organizaci

Doporučený setup přidává provozní a bezpečnostní vrstvy, které jsou u AI agentů zásadní: egress kontrolu, audit, centralizované logy, opakovatelný onboarding, secrets model a oddělení běžných agentů od sandboxu.

Doporučená architektura řízení provozu

Doporučené komponenty

Doporučený denní provoz

• [ ] Ráno zkontrolovat alerty UniFi, NAS, proxy a CI.
• [ ] Zkontrolovat neobvyklé egress objemy z LAB VLAN.
• [ ] Review agentních PR před mergem.
• [ ] Nepouštět automatické dependency změny bez diffu lockfile a security scanu.
• [ ] Kontrolovat failed logins na NAS a Git/CI.

Doporučený týdenní provoz

• [ ] Patch agentní OS a runtime image.
• [ ] Ověřit, že snapshot joby běží.
• [ ] Zkontrolovat nově přidané UniFi porty a neznámá zařízení.
• [ ] Projít top egress domény agentů.
• [ ] Projít nové servisní účty a tokeny.

17. Budoucí rozšíření: škálování agentní organizace

Až poroste počet agentů, projektů a citlivost dat, hlavní problém nebude jen síťová segmentace, ale řízení identity, politik, auditů a reprodukovatelnosti prostředí.

Cílový rozšiřitelný model

Rozšíření podle priority

18. Detailní akční plán implementace

Fáze 0: inventura a příprava

Fáze 1: síťová segmentace

Fáze 2: NAS a data

Fáze 3: agentní workflow

Fáze 4: zpevnění a škálování

19. Testovací scénáře před předáním do provozu

Síťové testy

NAS ACL testy

Workflow testy

• [ ] Agent vytvoří branch a PR, ale neumí mergovat do main bez review.
• [ ] Agent nemá produkční deploy token.
• [ ] Dependency PR ukáže změnu lockfile a security scan.
• [ ] Při zablokování agentního portu v UniFi okamžitě skončí přístup na NAS.
• [ ] Po deaktivaci servisního účtu na NAS agent ztratí mount/přístup.
• [ ] Restore snapshotu je vyzkoušený na testovacím souboru.

20. Rizika a rozhodnutí k potvrzení

Rozhodnutí, která je dobré udělat před realizací

1. Jaký datový klasifikační model použít: public/internal/confidential/customer?
2. Budou agenti primárně používat cloud LLM, lokální LLM, nebo hybrid?
3. Který Git hosting a CI budou zdrojem pravdy?
4. Je potřeba oddělit projekty už od začátku, nebo stačí per-agent izolace?
5. Jaká je akceptovatelná míra friction u egress allowlistu?
6. Jak dlouho držet agent logs, proxy logs a NAS audit logs?
7. Kdo schvaluje přístup agentů k citlivým datasetům?
8. Kdo vlastní incident response a rotaci secrets?

21. Finální doporučení

Začít minimálním setupem, ale navrhnout ho tak, aby nepřekážel doporučenému setupu. Prakticky to znamená hned zvolit stabilní IP/VLAN plán, oddělené NAS shares, per-agent identity a deny-by-default firewall. Následně během 1-2 týdnů doplnit egress proxy, monitoring, jasný Git/CI workflow a opakovatelný onboarding.

Největší hodnota je v jednoduchých hranicích: agentní HW je mimo DEV/MGMT, NAS je přístupný jen řízeně a každý agent má omezenou identitu. Tím se výrazně sníží dopad kompromitace agentního uzlu, chybného promptu, škodlivé dependency nebo runaway automatizace.

22. Užitečné reference

• Ubiquiti UniFi Network documentation
• Ubiquiti firewall and traffic rules
• Synology DSM Knowledge Center
• Synology Snapshot Replication
• OWASP Top 10 for Large Language Model Applications
• NIST Cybersecurity Framework
• GitHub Actions security hardening
• OpenSSF Scorecard
• Trivy vulnerability scanner