Hoe Gigflow zijn supportagents, zijn stagingdatabase en zijn geheugen achter één poort zette.

Gigflow is negen mensen. We bouwen een product, we ondersteunen het en we hebben niemand die security als job heeft. Wat we wel hadden: een VPN die iedereen deelde, een adminpaneel met één login, een stagingdatabase die twee agents konden bereiken omdat iemand een connection string in een Cursor-config had geplakt, en een supportagent op Claude die technisch gezien het recht had om klanten te verwijderen.

Niets daarvan was een beslissing. Het waren negen mensen die snel werkten. Toen een klant ons in een securityvragenlijst vroeg welke AI-systemen toegang hadden tot hun data, schreef ik "geen" en ging ik daarna kijken. Deze post gaat over wat er gebeurde nadat ik had gekeken.

Voor

• Eén WireGuard-config voor het hele team. Toen onze eerste developer vertrok, hebben we hem geroteerd. De tweede keer deed niemand dat.
• De stagingdatabase en het interne adminpaneel bereikbaar via die VPN voor iedereen, vanaf elke laptop, ook die ene die op de trein was blijven liggen.
• Een supportagent op Claude met een volledige API-key voor onze eigen backend, zodat hij bestellingen kon opzoeken. Opzoeken, en ook annuleren, terugbetalen en verwijderen, want dat doet een volledige key.
• Cursor-agents op drie laptops met de staging connection string. Elke agent onthield zijn eigen context; geen enkele deelde die; allemaal vergaten ze hem op maandag.
• Nergens een log waarmee ik de vragenlijst eerlijk kon invullen.

Wat we nu draaien

Alle vier. Dat was niet het plan; we begonnen met de tunnel en vonden telkens het volgende ding in dezelfde console.

De tunnel. Een connector naast de stagingdatabase en één naast het adminpaneel. De VPN is weg. Mensen loggen in met Google Workspace, het adminpaneel controleert de groep en onze twee freelancers krijgen precies het adminpaneel en niets anders. Het verhaal van de treinlaptop kan niet opnieuw gebeuren, want er staat niets op een laptop dat een deur opent.

Het uniforme endpoint. De supportagent verbindt met mcp.flowplane.eu/gigflow als de supportmedewerker die hem gebruikt. We hebben de OpenAPI-spec van onze eigen backend geüpload en kregen tools met namen als orders.get en orders.refund. Get mag voor support. Refund mag voor twee mensen en vereist dat de agent namens een van hen handelt. Delete is geen tool. Het kostte één namiddag, en het was de eerste keer dat ik onze eigen API-spec van begin tot eind las.

Geheugen. Hier was ik sceptisch over. We maakten een teamvault voor support: eigenaardigheden van het product, bekende problemen, de manier waarop we dingen verwoorden. Elke supportagent leest die, als de persoon die hem draait, en schrijft erin alleen als die persoon het bevestigt. Daarna kreeg elk van ons een persoonlijke vault. Cursor op mijn laptop onthoudt mijn conventies en die van niemand anders. De staging connection string staat in geen enkele ervan, want dat hoeft niet; de database is nu een tool.

Watchtower. We zetten hem aan in week vier, vooral uit nieuwsgierigheid. In week vijf stuurde hij dit.

Het was Tom, die een nieuwe prompt testte die de agent vroeg om "recente bestellingen te bekijken" zonder te zeggen hoeveel. Niets kwaadaardigs. Maar het was de eerste keer dat een AI-systeem in ons bedrijf iets vreemds deed en een mens het binnen een minuut wist, via een systeem dat niets anders had gelezen dan de log.

De vragenlijst vroeg welke AI toegang heeft tot wat. Nu exporteer ik een CSV en voeg ik die toe.

Wat het ons kostte

• Twee namiddagen voor de tunnel en het endpoint, één voor geheugen, tien minuten voor de Watchtower.
• Negen seats en vier agents op het teamtarief. Minder dan de VPN-appliance die we al lang wilden vervangen.
• Eén eerlijke securityvragenlijst, die we ondertekend terugkregen.

Als je een klein team bent met agents en zonder securitypersoon, is mijn advies niet "koop dit". Het is: ga na wat je agents op dit moment echt kunnen. Dan weet je of je één poort nodig hebt, en als dat zo is, is dit degene die wij kozen.