ZCode zet uploadpad uit en opent bron; AX maakt agent-isolatie configureerbaar

Z.ai heeft ZCode open source gemaakt en zegt de route voor lokale repositorysnapshots in versie 3.14.0 te hebben verwijderd. Google zet met AX een open agent-orchestrator neer waarin taken onder meer netwerk-egress kunnen beperken. Voor wie agents uitvoert, onderstreept een sandboxingdiscussie tegelijk dat toegangsrechten expliciet moeten zijn — een taalmodel zelf is geen securitygrens.

ZCode opent bron en verwijdert de repositorysnapshot-route

Z.ai meldt dat ZCode nu open source is, nadat de community privacy- en securityvragen had gesteld. Volgens de aankondiging is in clientversie 3.14.0 de Repo-Wiki-functie verwijderd, net als de workflow die lokale repositorysnapshots genereerde en uploadde. Z.ai zegt verder dat de betreffende object store en haar inhoud zijn verwijderd; CAICT en NSFOCUS zouden de remedie hebben beoordeeld. Aankondiging en technische samenvatting

Dit is een concrete verandering sinds de namiddagupdate van vrijdag 18 september, waarin alleen een niet onafhankelijk bevestigde beschuldiging rond mogelijke upload van Git-geschiedenis lag. Er is nu een reactie met een specifieke clientwijziging, een publiekere auditbasis en een broncodepublicatie. Voor teams die ZCode gebruiken is dat belangrijker dan de oorspronkelijke aantijging alleen: inspectie van de client en uitgaand verkeer wordt nu tenminste beter mogelijk.

Dat maakt de kwestie niet automatisch afgedaan. De assessments en claims komen via Z.ai’s eigen mededeling in de beschikbare bron; het volledige rapport zou nog volgen. Open bron bewijst bovendien niet dat iedere gedistribueerde binary overeenkomt met de geaudite code, noch dat een toekomstige versie hetzelfde netwerkgedrag houdt. Wie ZCode inzet, doet er nog steeds verstandig aan een testrepo zonder secrets te gebruiken, netwerkuitvoer te loggen en versie-upgrades expliciet te beoordelen.

Google AX brengt taakcontainers en egress-allowlists naar agentorkestratie

Google heeft AX aangekondigd als open agentic orchestrator. De bewaarde HN-discussie beschrijft een taakmodel waarin je containerimage, commando, compute-limieten en omgevingsvariabelen vastlegt, plus listeners en een allowlist van hosts en poorten die de sandbox mag bereiken. Daarmee kun je een taak bijvoorbeeld beperken tot een modelprovider en een Git-host. Aankondiging en discussie

Dat is praktisch interessant voor een agent die niet alleen code mag lezen, maar ook processen en tools aanstuurt: netwerktoegang wordt onderdeel van de taakdefinitie in plaats van een stilzwijgende eigenschap van de machine. Een egress-allowlist voorkomt niet iedere fout of aanval, maar verkleint wel het bereik van een gecompromitteerde tool, prompt-injection of verkeerde agentbeslissing.

De bron onderbouwt nog niet hoe volwassen AX is, welke isolation guarantees daadwerkelijk gelden of hoe het zich verhoudt tot een apart VM- of microVM-pad. Ook toont de discussie scepsis over de duurzaamheid van Google-producten; dat is geen technische evaluatie. Behandel AX dus als een nieuw ontwerp- en testpunt, niet als bewezen vervanging voor bestaande orchestration. Test vooral mounts, credentials, DNS, netwerkbeleid en herstel na een mislukte taak.

Sandboxing voor agents begint bij expliciete bevoegdheden

Een technische inleiding over software-sandboxing krijgt extra actualiteit door agenttools die shells, compilers en browsers bedienen. In de HN-discussie wordt het kernprobleem kernachtig geformuleerd: klassieke Unix-processen erven standaard veel bevoegdheden. Een strikter patroon is alleen vooraf toegewezen capabilities beschikbaar maken, bijvoorbeeld via geërfde file descriptors en een policy-bewakende RPC-laag; Linux-seccomp kan daarbij een proces sterk beperken. Artikel en technische discussie

Dat is relevanter dan een algemene regel als ‘draai de agent in een container’. Een container met brede mounts, netwerktoegang en een langlevend credential is nog steeds een ruime bevoegdhedenset. Voor een coding agent zijn concrete grenzen zinvoller: read-only broncode waar mogelijk, tijdelijke werkmap, een beperkt Git-token, geen toegang tot SSH-sleutels of browserprofielen, en netwerk alleen naar noodzakelijke endpoints.

Er is geen universele keuze. In de discussie noemen gebruikers Bubblewrap plus seccomp, maar ook volledige VM’s of microVM’s als sterkere scheiding; ieder model heeft operationele kosten en ontslaat niet van patchen. De praktische maatstaf is daarom niet welk framework een ‘sandbox’-vinkje heeft, maar welke files, sockets, processen en credentials na isolatie nog werkelijk bereikbaar zijn.

Verder nog

Een 3090-agent hield drie weken een CUDA-taak vast, maar betaalde fors voor contextbeheer: een gebruiker liet Qwen3.8-27B op één RTX 3090 circa 21 dagen werken aan kernels en benchmarks voor een eigen inference-engine. Het leverde werkende kernels, logs en Git-geschiedenis op, maar geen winst op llama.cpp; 699 compactions kostten volgens de auteur rond 83 uur. De leerzame storing was organisatorisch: een subworker kon de eigen vLLM-backend buiten het afgesproken venster stoppen. Rolgebonden scripts en locks zijn dus minstens zo belangrijk als modelkwaliteit. Eén zelfrapportage, maar met bruikbare cijfers en dump. Opzet, beperkingen en artefacten
Samsung wil HBM4-output sterk opvoeren: volgens een HN-verwijzing zou Samsung de output van HBM4 en HBM4E meer dan verdubbelen. Dat is context voor acceleratorcapaciteit, niet voor een snelle daling van consumenten-RAM-prijzen: HBM is een ander productsegment en de discussie wijst juist op concurrerende fab-capaciteit. Zonder primaire productiecijfers in de beschikbare context blijft dit een vroeg supplychainsignaal. HN-discussie