Het verificatiecodeprobleem: wanneer jouw agent een persoon moet bereiken

Je bot boekt een locatie. Hij vindt de plek, vult het formulier in, en vervolgens stuurt het systeem van de locatie een bevestigingslink per e-mail en een code per sms naar het geregistreerde nummer. Het geregistreerde nummer is van jou. Dus om 2 uur 's nachts zoemt je telefoon, en de altijd-aan-agent, die je alleen voor inschattingsvragen zou onderbreken, heeft je onderbroken voor een zescijferige code. Dit is de minst besproken beperking van autonome agents, en dat is waarom een OrcaID-handle wordt gespecificeerd met een inbox en een telefoonnummer in plaats van alleen een wallet.

SpaceXAI's framing voor Grok Bot, gelanceerd op 11 augustus 2026, is dat de bots blijven werken nadat je de laptop hebt gesloten en pas naar je terugkomen wanneer iets een menselijke beslissing nodig heeft. Dat is de juiste ambitie. De kloof tussen dat en de werkelijkheid is dat veel taken een stap bevatten, en die stap vereist een kanaal, geen beslissing — en als de agent geen eigen kanaal heeft, wordt elke van die stappen een onderbreking.

Verificatie is geen kwestie van inschatting.

Het is de moeite waard om twee dingen te onderscheiden die op elkaar lijken wanneer je telefoon oplicht.

Een inschattingsbeslissing is een stap waarbij de agent echt een mens nodig heeft: keur deze uitgave van $6.000 goed, is dit de juiste leverancier, willen we ons vastleggen voor een termijn van twaalf maanden. Je hiervoor onderbreken is het product dat correct werkt.

Een kanaalafhankelijkheid is een stap waarbij de agent niets van je nodig heeft behalve toegang tot een communicatie-eindpunt dat toevallig van jou is. Bevestig je e-mailadres. Voer de code in die we je per sms hebben gestuurd. Reageer op deze thread om verder te gaan. Klik op de link in je inbox. Neem de telefoon op zodat we de boeking kunnen verifiëren. Er is geen beslissing vereist; er is een persoon vereist, omdat de identiteit die wordt geverifieerd van een persoon is.

Bijna elke real-world workflow die een agent end-to-end zou kunnen uitvoeren, zit vol met kanaalafhankelijkheden. Je aanmelden voor wat dan ook. Iets boeken. Iets aanvechten. Onboarding bij een leverancier — een van de exacte use cases waarvan SpaceXAI zegt dat de eigen medewerkers er Grok Bot voor gebruikten. Elk hiervan stuurt op een gegeven moment een code of een e-mail naar de eigenaar van de identiteit, en als die eigenaar jij bent, blijft de agent steken en pingt hij jou.

Het resultaat is een agent die in het midden autonoom is en aan beide uiteinden afhankelijk. Hij kan het redeneren en het invullen van formulieren doen; de handshake kan hij niet doen.

Waarom het doorsturen van je inbox naar de agent de verkeerde oplossing is

De voor de hand liggende oplossing is om de bot toegang te geven tot je e-mail en je berichten, zodat hij de codes zelf kan lezen. Dit is gebruikelijk, en het is een veel grotere concessie dan het lijkt.

SpaceXAI is er duidelijk over dat dit het model is. De bots 'loggen in op de tools die je al gebruikt en werken in apps, inboxen en meer' — inboxen worden direct genoemd — en een van de vijf gespecialiseerde richtingen die het opsomt, is inboxbeheer. Het uitgewerkte voorbeeld gaat verder: 'een ops Bot die nieuwe medewerkers inwerkt en facturen verwerkt die in Gmail zijn ontvangen.' Dat is een door de leverancier beschreven agent die als routinematige workflow in het persoonlijke e-mailaccount van een mens opereert.

Je inbox is geen kanaal; het is een opslagplaats voor inloggegevens. Het bevat wachtwoordherstellen voor elk account dat je bezit, wat betekent dat leestoegang ertoe functioneel gezien neerkomt op de mogelijkheid om het grootste deel van je digitale leven over te nemen. Dat toevertrouwen aan een always-on agent om te voorkomen dat het je om bevestigingscodes moet vragen, ruilt een kleine frictie in voor een onbegrensde blootstelling. Het is ook op een specifieke manier onomkeerbaar: zodra de agent een maand lang je e-mail heeft gelezen, kun je niet controleren wat het heeft gelezen.

OpenClaw makes the shape of this risk concrete, because it does exactly that by design — it reads and sends your email as a core capability, running on your own machine. Independent reporting through 2026 has documented more than 135,000 exposed OpenClaw instances, CVE-2026-25253 at CVSS 8.8, and a supply-chain campaign against the ecosystem. Those are not arguments against OpenClaw's usefulness; they are a demonstration that when the agent's access is your inbox, an agent compromise and an identity compromise are the same event.

Het tweede probleem met het routeren van je inbox naar de agent is dat het zelfs de telefoon niet oplost. Spraakverificatie, sms naar een nummer dat een leverancier al in het bestand heeft, en terugbellen door een mens aan de andere kant vallen allemaal buiten wat e-mailtoegang kan bereiken.

Wat een inbox en een eigen nummer daadwerkelijk mogelijk maken

De vier functionaliteiten van OrcaID omvatten er twee die meer over communicatie gaan dan over geld, en dit is het artikel waarin ze het meest van belang zijn.

De inbox wordt op de site beschreven als het bestrijken van het volledige domein van de agent — "het hele domein is van de agent zelf — elk adres erop" — en, belangrijker nog, "gescand voordat iets het model bereikt". Het aspect van het hele domein is de nuttige ontwerpkeuze: een agent die eigenaar is van name.orcaid.ai kan per leverancier, per taak, per tegenpartij een afzonderlijk adres gebruiken, zonder iemand te vragen iets in te richten. Dat geeft de agent een plek om bevestigingslinks te ontvangen die niet jouw mailbox is, en het geeft je een natuurlijke manier om te zien welke tegenpartij welke agent mailt.

Het nummer wordt beschreven als spraak en sms, "voor wanneer het een persoon moet bereiken", altijd opgenomen en altijd getranscribeerd. Dat dekt de verificatiecodes, en ook het moeilijkere geval: de leverancier wiens proces eindigt met een telefoongesprek. De standaard van opname en transcriptie is het onderdeel waar een operator om zou moeten geven — een kanaal dat de agent beheert is alleen aanvaardbaar als wat erop gebeurt achteraf voor jou leesbaar is.

Hier doet status ertoe en de site is er duidelijk over: het nummer is gelabeld als 'bij verificatie' en de inbox 'bij lancering'. Geen van beide is vandaag actief. Wat er bestaat is de reservering, die gratis is en geen account opent of facturering start.

Bevestig je e-mailadres. Vandaag, met een geleende identiteit: De link komt in je persoonlijke inbox terecht. Met een toegewezen handle: Landt op een adres dat de agent bezit.

SMS-verificatiecode. Vandaag, met een geleende identiteit: Laat je telefoon trillen. Met een toegewezen alias: Komt aan op het nummer van de agent.

Leverancier antwoordt op een topic. Vandaag, met geleende identiteit: Gemengd in uw e-mail. Met een toegewezen gebruikersnaam: Bewaard op het eigen adres van de agent.

Een mens moet bellen. Vandaag, met geleende identiteit: Alleen jij kunt antwoorden. Met een toegewezen naam: Stemlijn, opgenomen en getranscribeerd.

Scheiding per leverancier. Vandaag, met geleende identiteit: Eén adres voor alles. Met een uitgegeven handle: Een afzonderlijk adres per tegenpartij.

Het scan-detail is het interessante.

"Gescant voordat er iets het model bereikt" is één bijzin en het gaat over datgene wat agent-inboxen werkelijk gevaarlijk maakt.

Een agent die zijn eigen mail leest, is een agent wiens instructies van vreemden kunnen komen. Iedereen die het adres te weten komt, kan tekst sturen die de agent verwerkt, en een agent die handelt naar wat hij leest, is één zorgvuldig opgesteld bericht verwijderd van iets doen wat hem nooit is gevraagd. Dit is prompt-injectie met een publiek toegangspunt, en een agent een inbox geven zonder filter ervoor zou een groter probleem opleveren dan het probleem dat het oplost.

De scan tussen de e-mail en het model plaatsen is dus geen aardige extra — het is de voorwaarde dat de inbox überhaupt een goed idee is. Het is ook het onderdeel dat bij de lancering het meest de moeite waard is om te onderzoeken, omdat 'gescand' een breed scala aan strengheid dekt, en het verschil tussen spamheuristieken en verdediging tegen instructie-injectie groot is.

Wat nu hiermee doen?

Grok Bot is in bèta op bestaande betaalde abonnementen zonder gepubliceerde datum voor bredere beschikbaarheid, en de inbox en het nummer van OrcaID zijn nog niet live. Dit is dus een ontwerpnotitie in plaats van een migratie.

Als je agents bouwt of gebruikt die transacties uitvoeren, tel dan eerst de kanaalafhankelijkheden in je drie belangrijkste workflows voordat je iets anders telt — dat getal voorspelt hoe autonoom de agent daadwerkelijk kan zijn, en het ligt meestal hoger dan mensen verwachten. Waar mogelijk, geef de agent vandaag nog een mailadres dat niet het jouwe is, zelfs een gewoon alias; het is een fractie van het voordeel, maar het voorkomt dat het bevestigingsverkeer in je eigen mail terechtkomt. Weersta de verleiding om een agent leestoegang tot je primaire inbox te geven om verificatie op te lossen, want je ruilt een begrensde frictie in voor een onbegrensde. En als je een agent toch een inkomend kanaal geeft, plaats dan filtering vóór het model, niet erna.

De kern

Het plafond voor agentautonomie in 2026 is niet de kwaliteit van het redeneren. Het is dat de wereld mensen verifieert, en een agent die iemands identiteit leent, stuit in bijna elke echte workflow op een stap met menselijk contact. Grok Bot's belofte om je alleen te onderbreken voor oordeelsbeslissingen wordt ondermijnd door het feit dat de meeste onderbrekingen helemaal geen oordeelsbeslissingen zijn — het zijn codes, links en callbacks die aankomen op kanalen die de agent niet bezit.

Een account met een eigen inbox voor een heel domein en een eigen opgenomen telefoonlijn is een direct antwoord daarop, en het is de helft van de OrcaID-propositie die minder aandacht krijgt dan de wallet, terwijl het waarschijnlijk meer taken blokkeert. Beide zijn vandaag pre-registratie, respectievelijk gemarkeerd als 'bij lancering' en 'bij verificatie'. Het idee is degelijk genoeg dat het bij de lancering niet gaat om te controleren of de inbox bestaat, maar hoe serieus de scanning die eraan voorafgaat is genomen.

Bronvermelding: de lanceerdatum van Grok Bot (11 augustus 2026), het always-on-gedrag, de formulering "we komen pas bij je terug als er een menselijke beslissing nodig is", het model van inloggen op je eigen tools, het onboarding-gebruiksscenario en de beschikbaarheid van een betaald bètaniveau zijn eigen claims van SpaceXAI. Het ontbreken van een gepubliceerde datum voor een bredere uitrol is afkomstig uit onafhankelijke berichtgeving. De mogelijkheid van OpenClaw om e-mail te lezen en te verzenden en het lokaal draaiende model zijn afkomstig uit de eigen beschrijving van het project; de 135.000+ blootgestelde instanties, CVE-2026-25253 (CVSS 8.8) en de supply-chaincampagne zijn onafhankelijk gerapporteerd, geen claims van het project. De inbox van OrcaID ("het hele domein is eigen", "gescand voordat er iets het model bereikt") en het nummer ("spraak en sms", "altijd opgenomen, altijd getranscribeerd"), en hun labels "Bij lancering" en "Bij verificatie", zijn afkomstig van orcaid.ai, gecontroleerd op 22-08-2026 — claims van vóór de registratie. Er is geen integratie tussen OrcaID en Grok Bot aangekondigd.