Google heeft de toegang tot Gemini 4 Carbon uitgebreid en laat tegelijk zien wat er mogelijk is wanneer AI-agenten niet alleen code doorzoeken, maar ook formeel verifiëren. In een nieuwe aanpak koppelden onderzoekers AI aan wiskundige bewijzen voor de implementatie van het Signal-protocol—waarmee juist de privacy- en beveiligingsbeloften van de software extra hard gemaakt worden.
Voor ontwikkelaars en beveiligingsteams is dit interessant, omdat het laat zien hoe “bewijsbaarheid” dichterbij komt dan klassieke, dure verificatie-trajecten. Tegelijk blijft het relevant om de context te begrijpen: Google publiceerde ook specificaties en bewijzen, maar de resultaten gaan uit van de onderzochte builds en methoden.
Wat is Gemini 4 Carbon en waarom breidt Google de toegang uit?
Tot nu toe was Carbon vooral beschikbaar voor een selecte groep cyberverdedigers binnen het Fairwind-programma. Dat verandert: Google geeft ontwikkelaars en bedrijven de mogelijkheid om Carbon te gebruiken via de Gemini API en via Gemini for Business. Daarnaast krijgen Google AI Ultra-abonnees toegang.
Google hanteert introductietarieven van $2 per miljoen inputtokens en $10 per miljoen outputtokens, met een geldigheid tot 30 november. Daarna verdubbelen de tarieven.
Een praktische takeaway: als je werkt aan beveiligingsanalyses, proof-of-concepts of het ondersteunen van patchbeslissingen, wordt Carbon daarmee toegankelijker als bouwsteen.
Van vulnerability spotting naar bewijs voor beveiligingsgaranties
Google positioneert Gemini 4 Carbon niet alleen als “snelle cyber-assistent”, maar ook als middel om kernbeveiligingsclaims in code formeel te onderbouwen. In eerdere voorbeelden stelde Google dat Carbon is ingezet door teams om de haalbaarheid van kwetsbaarheden te bevestigen en om bugs sneller op kritisch niveau te laten classificeren.
Zo beschrijft Google een inzet waarbij de Cloud Vulnerability Research (CVR)-teams twee bugs in een open-source project konden bevestigen als exploiteerbaar. De ernst werd daarbij vergeleken met eerder misbruik van PHP-kwetsbaarheden (waarmee aanvallers al succes hadden). Google noemt bovendien dat CVR, door het bouwen van een proof of concept, maintainers hielp de bug opnieuw te classificeren als kritiek en vervolgens snel een patch te laten uitrollen.
De onderliggende boodschap voor beveiligingspraktijk: AI kan de drempel verlagen om te bewijzen wat er technisch kan—en om sneller tot herclassificatie en remediation te komen.
AlphaProof Code: AI en menselijke experts voor formele verificatie
Naast Gemini 4 Carbon introduceerde Google DeepMind AlphaProof Code. Dat is een methode waarbij menselijke experts en AI-agenten samenwerken om software formeel te verifiëren met behulp van wiskundige bewijzen. Het idee is dat je niet alleen kijkt of iets “waarschijnlijk veilig” is, maar dat je een afgebakende set eisen mathematisch aantoont.
In dit onderzoek werd de methode toegepast op libsignal, de referentie-implementatie van het Signal-protocol. Google benadrukt dat versies van dat protocol ook draaien binnen WhatsApp en Google Messages.
Hoe ging het proof-traject in zijn werk?
- Humane experts werkten samen met agenten om de specificaties op te stellen: wat precies moest worden bewezen.
- De AI-agenten—waaronder Carbon-gebaseerde agenten—genereerden vervolgens een enorme hoeveelheid bewijslijnen (ongeveer 6,5 miljoen regels Lean proofs).
- Lean wees de ongeldige bewijzen af, waardoor alleen correct gevalideerde bewijspaden overbleven.
Google geeft aan dat vijf onderzoekers het bewijswerk in vier weken afronden, terwijl specialisten dit volgens Google traditioneel jaren zouden doen.
Welke beveiligingsgaranties zijn aangetoond?
De bewezen garanties hebben betrekking op eigenschappen die in het Signal-protocol centraal staan. Volgens Google gaat het onder meer om:
- Forward secrecy
- Post-compromise security
- Authenticatie
Belangrijk detail: de methode richtte zich niet uitsluitend op het ontwerp. De garanties werden ook onderbouwd voor de gecompileerde machinecode. Dat verschilt van verificaties die vooral op conceptueel niveau plaatsvinden.
Daarnaast beschrijft Google dat de onderzoekers “side channels” uitsloten van delen van de analyse. Ook is de scope afgebakend: de resultaten gaan over de onderzochte Google-build, via een kleine command-line wrapper, en niet over de Signal-applicaties zelf.
De methode getest met oude, gepatchte bugs
Om te laten zien dat de aanpak niet alleen theoretisch klopt, reïnjecteerden de onderzoekers twee oude libsignal-bugs die eerder al waren gepatcht. Daarna bewezen ze dat deze aangepaste builds de beveiligingsgaranties zouden breken.
Daarmee wil het team aantonen dat de verificatieprocedure echte fouten kan terugvinden: wanneer er iets mis is, faalt de bewijsvoering op de garanties.
Google zegt de resultaten openbaar te maken door de specificaties en proofs te publiceren.
Wat betekent dit voor security teams?
Als je in beveiliging werkt—of je nu aan software supply chain, audit, of exploitatieanalyse doet—dan is dit soort formele verificatie een interessante richting. Het laat zien dat AI-agenten mogelijk kunnen helpen om “bewijswerk” sneller en uitvoerbaar te maken, vooral wanneer je specifieke security-eisen goed kunt formuleren.
Tegelijk blijft het verstandig om het resultaat te lezen met de juiste bril: de bewijslast hoort bij de onderzochte implementatie, de gebruikte specificaties en de gekozen grenzen van de analyse.
Wil je dit koppelen aan bredere transparantie in beveiliging? Bekijk ook Bron: https://www.securityweek.com/google-widens-gemini-4-carbon-access-after-ai-agents-verify-signal-code/
