Gitagent: je AI-agent als git-repo — briljant concept, nog niet productie-klaar

Een AI-agent die géén configuratiebestanden in je project strooit, maar zélf een git-repository is — met agent.yaml, SOUL.md, RULES.md en memory/MEMORY.md als version-controlled bestanden. git log je agent's geheugen. git diff de regels. git branch een alternatieve persoonlijkheid. Dat is Gitagent: agents als code.

Het klinkt als precies wat de Rijksoverheid nodig heeft. En in concept is het dat ook. Maar de praktijk is genuanceerder.

Agents as repos — het goede idee

Gitagent (MIT, 3 maanden oud, 426 stars) definieert een agent als directorystructuur:

my-agent/
├── agent.yaml          # Model, tools, compliance, delegatie
├── SOUL.md             # Identiteit en persoonlijkheid
├── RULES.md            # Gedragsregels
├── memory/MEMORY.md    # Git-committed geheugen
├── compliance/         # Regulatory-map + validatieschema's
├── hooks/hooks.yaml    # Lifecycle hooks
├── skills/             # Composable skill-modules
└── plugins/            # Uitbreidingen via plugin-systeem

Het idee erachter is sterk, en dicht bij mijn "Model + Harness = Agent"-denklijn: agentgedrag hoort beheerd te worden als configuratie-object, vergelijkbaar met infrastructuur-als-code en policy-as-code. Dat geeft je:

• Traceerbaarheid: wijzigingen in regels, skills en tools via PR-review en branch protection
• Portabiliteit: de agent-definitie staat los van runtime — Claude Code, OpenClaw, of je eigen harness
• Governance-fit: RULES.md, hooks, compliance-configuratie en audit logs sluiten aan op BIO2 en EU AI Act evidence trails

Dit is de belofte. Maar beloftes zijn geen security boundaries.

De security-realiteit: bouwblokken, geen fort

Gitagent geeft agents standaard toegang tot filesystem, shell, repo's en plugins. De ingebouwde cli-tool voert shell-commands uit. De write-tool maakt bestanden aan. In de praktijk betekent dat: zonder harde sandbox en policy enforcement is de agent kwetsbaar voor een hele reeks aanvallen.

Het risicoregister dat ik hanteer:

Prompt injection via repo-content. Issues, README's, comments of gegenereerde documenten kunnen de agent sturen. De repo-content moet behandeld worden als untrusted input. Mitigatie: preToolUse-policies en context labeling.

Tool abuse via shell execution. De standaard cli-tool is onbeperkt. rm -rf, git push --force, netwerktoegang — alles kan. Mitigatie: allowedTools/disallowedTools, command allowlisting, sandbox-container.

Credential exposure. Environment variables, PAT's en API keys zijn bereikbaar. De agent heeft ze niet nodig maar kan ze wél lezen — tenzij je expliciet isoleert.

Supply-chain via plugins en remote extends. De plugin-architectuur (gitagent plugin install, npm-dependencies, extends in agent.yaml) is een aanvalsoppervlak. Mitigatie: pin commits en tags, signed releases, geen auto-install, dependency scanning.

Memory poisoning. memory/MEMORY.md kan door de agent zelf worden aangepast. Een kwaadwillende prompt kan persistent gedrag wijzigen. Mitigatie: memory-PR review, signed memory updates, retention policy.

Ongewenste auto-commit/push. De agent kan automatisch naar sessiebranches pushen. Op zich veilig als het bij sessiebranches blijft — maar zonder CODEOWNERS en branch protection is dat een risico.

Exfiltratie via tools. Declaratieve én programmatische tools kunnen data naar buiten sturen als er geen egress-restricties zijn.

Wat Gitagent wél goed doet

De beheersmechanismen zijn er. Alleen zijn het bouwblokken — je moet ze zelf assembleren tot een complete security boundary.

• allowedTools / disallowedTools: tool allowlisting en denylisting
• Hooks: pre_tool_use, on_error, pre_query — kunnen tool-aanroepen blokkeren, modificeren of toestaan
• Sandbox-modus: draait de agent in een VM
• Compliance-metadata: risk_level, human_in_the_loop, data_classification, regulatory_frameworks, recordkeeping
• Audit logging: schrijft naar .gitagent/audit.jsonl met tool invocation traces
• OpenTelemetry: spans voor LLM calls, tool execution en agent sessions — mét token usage, kosten, toolstatus, foutmeldingen en sessieduur

Die OTEL-output is voor mij het interessantst. Je kunt er cost-per-task, tool failure rate, retry-loops en model-placement mee meten. Dát maakt het bruikbaar voor governance-demonstraties richting CISO's en architectuurtafels — niet alleen in theorie, maar met meetbare data.

De compliance-validatie in agent.yaml is functioneel maar waarschuwend, niet blokkerend:

| Regel | Conditie | Type | | --- | --- | --- | | high_risk_hitl | high/critical risk zonder human-in-the-loop | warning | | critical_audit | critical risk zonder audit logging | error | | regulatory_recordkeeping | frameworks zonder recordkeeping | warning | | audit_retention | audit logging zonder retention_days | warning | | data_classification | regulated zonder classificatie | warning |

Er staat "error" bij critical — maar dat is een validatiewaarschuwing, geen runtime-block. Dat moet je zelf toevoegen in hooks.

Positionering: governance-laag, geen runtime-vervanger

Gitagent is geen "betere Claude Code" en ook geen vervanger van je bestaande agent-stack. Het is een agent definition and governance layer — een neutrale verpakkingslaag boven Claude Code, OpenClaw, OpenCode, en andere runtimes.

Mijn adoptiemodel kent drie ringen:

Ring 0 — Read-only lab. Agent-definities inspecteren, skills en rules genereren, repo's analyseren. Read-only token, geen secrets, geen productiecode. Alleen read-tool, geen cli tenzij sandboxed.

Ring 1 — Controlled engineering. Agent mag branches maken en PR's openen. Fine-grained GitHub token, alleen specifieke repo's. CODEOWNERS, branch protection, signed commits, required checks, SAST en secret scanning.

Ring 2 — Governed automation. Agent mag gecontroleerde refactors, documentatie en compliance evidence bijwerken. Policy engine, OPA/Rego-gates, OTEL, audit retention, change windows, human-in-the-loop, runtime sandbox en egress restrictions.

Wat je nooit moet doen: Gitagent direct op productie-repo's draaien met write-access en algemene PAT's. Dat is vragen om problemen.

Het rebranding-probleem

Een praktisch maturiteitssignaal: de GitHub package.json toont @open-gitagent/gitagent v0.2.0, terwijl release-informatie meldt dat het project is hernoemd naar GitAgentProtocol/Open GAP en nieuwe ontwikkeling onder gapman plaatsvindt. De oude npm-package blijft op 0.2.0, de nieuwe CLI heet anders. Geen showstopper, maar voor supply-chain betrouwbaarheid is dit een rood vlaggetje. Pin je versie, volg de ontwikkeling, ga niet blind mee met latest.

Mijn conclusie

Strategisch relevant, technisch nog jong. Wel adopteren als concept en lab-bouwsteen. Niet blind vertrouwen als runtime-standaard zonder extra security wrapper.

Praktische scores:

| Dimensie | Score | | --- | --- | | Strategische relevantie | 8.5/10 | | Technische volwassenheid | 6/10 | | Security-by-default | 5/10 | | Governance-potentie | 8/10 | | Fit voor DjimIT-stack | 8/10 | | Enterprise readiness | 5.5/10 |

De kernwaarde zit niet in "weer een agent-framework" — die hebben we al genoeg. Het zit in de portable agent specification layer. Het idee dat je agent-definities versiebeheert, reviewed, branched en auditeert zoals je met alle software doet. Dat is de transitie die de Rijksoverheid moet maken van "AI als experiment" naar "AI als beheerde software supply-chain entiteit".

Voor DjimIT zie ik drie toepassingen: een secure agent template catalogus (Secure Code Reviewer, AI Governance Analyst, DPIA Agent, MCP Security Auditor), een governance-demonstrator voor overheid en enterprise, en een bovenliggende packaging-laag voor Claude Code/OpenClaw-skills.

Maar eerst: testen in een disposable devcontainer, niet op het hoofdwerkstation met secrets. Pin de versie. Bouw een djimit-secure-agent-template. Draai 'm tegen een testrepo in Ring 0. Meet tokengebruik, tool calls, foutpercentage en hallucination rate. Pas daarna opschalen naar Ring 1.

Een briljant concept verdient een zorgvuldige adoptie.