Als Parego een code agent inzet, wil ik twee dingen tegelijk: snelheid én controle. In de terminal krijg je vooral snelheid, maar controle wordt snel een aanname. Een CLI-agent draait namelijk in jouw ontwikkelomgeving en kan in de praktijk dezelfde dingen als jij: bestanden lezen, commando’s uitvoeren, git gebruiken, en soms ook “per ongeluk” verder kijken dan je bedoeld had.

Voor klanten is dit belangrijk omdat het raakt aan twee vragen:

1. Kan dit jullie project sneller opleveren? Ja.
2. Kan dit ook nieuwe risico’s introduceren? Ook ja.

“Lees mijn .env niet” is beleid, geen slot

Veel mensen zetten in een instructiebestand (bijv. CLAUDE.md) dat een agent geen secrets mag lezen. Dat helpt als gedragsregel, maar het is geen harde beveiligingsgrens.

Er zijn publieke bugmeldingen waar Anthropic’s Claude Code toch .env kon lezen ondanks configuratie die dit zou moeten blokkeren. 

En er is recente berichtgeving die hetzelfde probleem bespreekt, inclusief het negeren van .gitignore in sommige routes. 

De les (ook richting klanten): instructies zijn “policy”, maar echte veiligheid komt van technische afbakening.

Wat zijn de echte risico’s, in normale mensentaal

Zodra je agents koppelt aan tools (bijvoorbeeld via MCP), worden ze minder “tekstgenerator” en meer “uitvoerder”. Dat is nuttig, maar dit zijn de bekende risicoklassen die steeds terugkomen in MCP security guidance:

• Prompt injection / indirect injection: kwaadwillenden verstoppen instructies in content die een agent leest (pagina’s, docs, tickets), waardoor de agent ongewenste acties gaat uitvoeren. 
• Tool poisoning: de misleiding zit niet in de content, maar in de toolbeschrijving of parameters, waardoor de agent denkt dat iets veilig is of “moet”. 
• Over-permissioned tools: tools met te veel rechten (filesystem lezen, arbitrary SQL, POST naar willekeurige endpoints) vergroten schade en datalekrisico als er iets misgaat. 
• Authz/authn fouten: MCP servers zonder strakke authenticatie, scopes, throttling en logging zijn een direct aanvalspunt. MCP heeft daarom een OAuth 2.1 authorization model en security best practices. 

Dit is precies waarom terminal-agents extra spannend zijn: als een agent eenmaal misleid is, kan hij vaak meteen “doen”, niet alleen “zeggen”.

Hoe wij dit bij Parego doen

Wij gebruiken code agents zo dat ze ons helpen, maar niet stiekem ons risicoprofiel vergroten:

1. Web + GitHub, niet de terminal als standaard In een webflow die direct op GitHub werkt, ziet de agent primair wat er in de repo staat. Dat past bij hoe wij werken: private repos, en nooit secrets in git.
2. PR-first De agent maakt een branch en Pull Request. Wij reviewen de diff, draaien checks, en mergen pas als alles klopt. Dat is dezelfde discipline als bij een extra developer in het team.
3. Minimale rechten, minimale output Als we tooling toevoegen (bijv. audits), dan liefst read-only, met samenvattingen in plaats van complete dumps van content of data.

En MCP dan, is dat klantwaarde of vooral techniek?

MCP kan wél klantwaarde zijn, maar alleen als je er een concrete, veilige feature van maakt (bijv. SEO/schema auditrapportage, content QA, editor-assistent met guardrails). Laravel positioneert MCP ook expliciet als manier om tools/resources/prompts te definiëren voor AI-clients. 

Belangrijk is dat Laravel ook duidelijk maakt hoe je dit moet beveiligen met bekende patronen: middleware plus OAuth 2.1 en Sanctum. 

En Microsoft heeft een goede defense-in-depth uitleg specifiek voor indirect prompt injection in MCP context. 

Helder standpunt

• Een terminal-agent kan prima, maar dan moet je hem behandelen als hoog risico tooling: sandboxing, echte file access controls, least privilege, en nooit vertrouwen op “ik heb het in een .md gezet”.
• Voor klanten zetten wij liever in op een gecontroleerde workflow: repo-gebaseerd, PR-first, en alleen productized AI-features als we ze ook echt veilig kunnen maken.