Wat je securityteam over Polargate moet weten

Met wie je een contract sluit

De contractpartij is POLARGATE, S.L., een Spaanse besloten vennootschap met één bestuurder, statutair en fiscaal gevestigd in Madrid, met een EU-btw-nummer voor werk buiten Spanje. Contracten, facturen en aansprakelijkheid liggen bij die vennootschap.

Polargate bestaat uit twee mensen, geen groot adviesbureau. Pedro Ciordia, oprichter en CTO, doet de architectuur, de bouw en de reviews; Andrés Ciordia, Chief AI Officer, leidt het AI-deel. Per project sluiten specialisten aan. Als jouw inkoopproces een leverancier met een complianceafdeling vereist, vertelt deze pagina je in vijf minuten of we door je poort komen, in plaats van in week drie.

Waar je data staat, en wie er nog meer bij kan

In je eigen accounts, waar het project dat toelaat

We bouwen op Postgres met row level security (Supabase), statische hosting (Vercel) en een private Git-repository. Waar het project dat toelaat, worden die accounts op jouw naam geopend en aan jou gefactureerd, zodat de infrastructuur van jou is en niet van ons wordt onderverhuurd.

Subverwerkers

Alles wat we bouwen heeft een korte lijst subverwerkers: de host van database en backend, de webhost, de host van de broncode, de modelleverancier die we tijdens de bouw gebruiken, een leverancier van embeddings als het project semantisch zoeken bevat, een crawlleverancier als het project marktmonitoring bevat, en het e-mailtransport.

We publiceren geen vaste algemene lijst, want die lijst hangt af van wat we voor jou bouwen. Je krijgt de lijst met namen, inclusief de verwerkingsregio per dienst, schriftelijk voordat je tekent, en die gaat mee het contract in. Verandert er tijdens de opdracht een subverwerker, dan hoor je dat vooraf en niet achteraf.

Dataresidentie

We doen geen algemene belofte dat alle data binnen de EU blijft. De regio wordt per project gekozen en vastgelegd vóór de eerste deploy. Is verwerking uitsluitend binnen de EU een harde eis, zeg dat dan bij de kickoff: het verandert de keuze van leveranciers, en die keuze maken vóór de eerste regel code is goedkoop, daarna duur.

De code en de content zijn van jou

De repository is vanaf dag één van jou, niet pas bij de laatste factuur. Niets van wat we bouwen draait op een CMS van ons, op een licentie die je aan ons moet blijven betalen of op een omgeving die alleen wij kunnen bedienen. Sites worden vooraf gerenderd naar statische HTML en de content staat in je eigen database.

Bij de overdracht krijg je de repository, het eigendom van het backendproject, de DNS-records en de secrets. De toets die we onszelf opleggen is simpel: een ander vakbekwaam team moet het project kunnen overnemen zonder ons te bellen. Standaard stack, standaard deploychain, documentatie in de repository.

Continuïteit als Pedro er niet is

Het eerlijke antwoord: je product blijft draaien, want het draait nergens op iets van ons. De repository is van jou, de infrastructuur staat waar mogelijk in jouw accounts, en de deploychain is standaardgereedschap. Er is geen licentieserver van Polargate, geen propriëtaire runtime en geen sleutel die wij wel hebben en jij niet.

Wat stopt is nieuw werk, niet het product. Dat is het echte risico van één operator, en we schrijven het liever hier op dan dat je risicoteam het zelf ontdekt. Doorlopende support loopt via een urenbundel met een schriftelijk afgesproken reactietermijn, en je ziet het verbruik in je portaal en in de voettekst van elke supportmail, zodat je altijd weet wat er nog over is.

Hoe wij AI inzetten bij de bouw, en wat een mens controleert

We bouwen met AI-agents in de lus, controleren het resultaat daarna met meerdere agents parallel, en elke bevinding wordt eerst aangevallen door onafhankelijke sceptische agents voordat we hem accepteren. Bij een recente audit draaiden 41 agents en kwamen er 17 bevindingen uit, elk getoetst door twee onafhankelijke sceptici. Bij een andere controle liet een mechanische sweep van 300 gevallen zien dat een criterium dat wij correct achtten in 78 procent van de gevallen faalde; de gecorrigeerde versie kwam terug met nul fouten op diezelfde 300.

Een mens beoordeelt en tekent af, en een mens zet de productiedeploy handmatig in gang. Op de platformen die wij draaien, draaien tests bij elke development- en stagingbuild. Niets komt in productie omdat een machine besloot dat het klaar was.

Twee grenzen die we hardop zeggen. Ten eerste: code en documenten die je met ons deelt worden verwerkt door de modelleveranciers die we bij naam noemen, en hun voorwaarden gelden; we noemen ze zodat je team die voorwaarden zelf kan lezen in plaats van ons op ons woord te geloven. Ten tweede: secrets gaan nooit in een prompt of in een repository. Ze staan in een versleutelde, geauditeerde kluis achter één gateway, elke toegang wordt gelogd, rotatie is geversioneerd en van machinetokens wordt alleen de hash bewaard.

De controles die we wel hebben

Elk van deze punten is een gedateerde momentopname van een systeem, geen permanente eigenschap ervan.

Isolatie tussen klanten op één platform

Row level security staat verplicht aan, en een wachter zoekt zelf de tabellen op die een klantidentificatie dragen in plaats van te vertrouwen op een handmatige lijst. In augustus 2026 bewaakte die 81 van zulke tabellen en draaide hij in continuous integration, en de kruistest tussen twee echte klanten leverde bij die run geen enkele lek op.

Scheiding tussen klanten in onze eigen systemen

Ons kennissysteem houdt het materiaal van de ene klant weg bij elke andere via vier onafhankelijke lagen: een predicaat in de database, een controle in de applicatie met een test in CI, een tabeltrigger en een hervalidatie van het verzoek. Op 3 september 2026 had die muur 507 bronnen tegengehouden voordat ze zelfs maar bij een classificatie kwamen.

Auditing en uitgavenplafonds

Elke aanroep via onze connector wordt gelogd, 8.463 stuks bij diezelfde meting. Een adversariële audit van ons eigen toegangsmodel leverde 26 bevindingen op, waarvan 19 bevestigd, allemaal verholpen en uitgerold. Een tweede ronde haalde 13 row level security-policies weg die elke interne gebruiker leesrechten op alles gaven, en voegde een plafond toe van 200 AI-aanroepen per gebruiker per dag.

Secrets

Bij de meting van juli 2026 stonden er ongeveer 28 secrets geverifieerd in de kluis, met een audittrail per toegang en geversioneerde rotatie om terug te kunnen. Continuous integration leest daaruit om apps te signeren en te publiceren, zodat er nergens een sleutel geplakt hoeft te worden.

Externe ogen en webhardening

Een externe consultant beoordeelde in juli 2026 de beveiligingspositie van een van onze platformen: 23 punten, 11 gesloten op dat moment. Op sites die wij harden serveren we HSTS, een Content Security Policy, X-Frame-Options, nosniff, een strikte Referrer-Policy en een Permissions-Policy, en verwijderen we serverversie-sporen.

Het gat: geen ISO 27001, geen SOC 2

We hebben geen ISO 27001. We hebben geen SOC 2. Er is geen externe penetratietest uitgevoerd. We publiceren vandaag geen standaard verwerkersovereenkomst. Het anders opschrijven zou een leugen zijn die je auditor toch vindt.

Wat we in plaats daarvan doen: we beantwoorden je vragenlijst met de controles hierboven, gedateerd en met het bewijs erbij; we beoordelen en tekenen jouw verwerkersovereenkomst als onderdeel van het contract; en we staan open voor een penetratietest door jou of door jouw leverancier, op jouw kosten en binnen een schriftelijk afgesproken venster. We laten ons liever testen dan certificeren met bijvoeglijke naamwoorden.

We hebben geen certificeringsdatum voor je, want we zijn dat traject niet gestart. Zodra dat wel zo is, staat de datum op deze pagina. Is een certificaat een harde poort in je leveranciersproces, dan komen we daar vandaag niet doorheen, en dat weet je beter nu dan in week drie.

Inkoop en leveranciersacceptatie

Wat we kunnen aanleveren

• Bedrijfsgegevens voor leveranciersregistratie: statutaire naam, CIF, EU-btw-nummer, vestigingsadres en bankgegevens voor facturatie.
• Een schriftelijke architectuurbeschrijving van jouw project: componenten, datastromen, waar elk onderdeel draait, en de lijst met subverwerkers en hun regio's.
• Het toegangs- en secretsmodel: wie waarbij kan, hoe toegang wordt verleend en hoe die wordt ingetrokken.
• De deploy- en rollbackprocedure, inclusief wie productie in gang zet en hoe een release wordt teruggedraaid.
• Je beveiligingsvragenlijst, ingevuld.

Wat we niet kunnen sturen is wat niet bestaat: certificeringen die we niet hebben en auditrapporten die er nooit zijn geweest.

Hoe we een beveiligingsvragenlijst beantwoorden

Je krijgt een bevestiging met de naam van degene die hem invult en een leverdatum, en dat is de datum waar we op sturen. Een lange maatwerkvragenlijst, of een leveranciersportaal met eigen formulieren, krijgt zijn datum in datzelfde eerste antwoord.

De antwoorden worden geschreven door de engineer die het systeem heeft gebouwd, niet door een complianceteam. Dat is trager op volume en preciezer op detail, en het betekent dat wie vraag 74 beantwoordt ook degene is die kan veranderen waar vraag 74 over gaat.

Met wie je praat

Pedro Ciordia, oprichter en CTO. Alles komt binnen via het formulier op /start en belandt rechtstreeks bij hem. Dezelfde persoon doet de vragenlijst, het architectuurgesprek, de contractbeoordeling en elk incident. Er zit geen laag accountmanagers tussen.