Van copiloot tot collega: wat het betekent als AI autonoom werkt

Een onderzoeksgestuurde blik op de verschuiving van suggestiemachines naar autonome teamgenoten. Waarom het nu gebeurt, wat er misgaat in de overgang en hoe je inzet zonder de sleutels van het koninkrijk uit handen te geven.

Het copiloot-tijdperk stagneert

Op 15 april 2026 plaatste Sam Altman op X dat OpenAI "deze week Codex-updates uitrolt gericht op teams en grote bedrijven."

De reacties waren veelzeggend. Voor elke ontwikkelaar die naar de roadmap vroeg, was er een ander die een moeilijkere vraag stelde: waarom moet ik Codex nog steeds in de gaten houden? Zes maanden eerder hadden BeyondTrust-onderzoekers een proof-of-concept gepubliceerd waaruit bleek dat een speciaal samengestelde Git-branchnaam Codex kon misleiden om het GitHub-token van de gebruiker te exfiltreren. Een copiloot die via een branchnaam tot het lekken van een token kan worden verleid, is geen collega. Het is een geladen wapen met de veiligheid erop.

Die spanning ligt onder elk enterprise AI-gesprek in 2026. Copiloten hebben hun plafond bereikt, en de cijfers bevestigen dat:

MIT's NANDA-initiatief meldde in 2025 dat 95% van de generatieve AI-pilots er niet in slaagt meetbare bedrijfswaarde te leveren.
Een RAND-studie die herhaaldelijk werd aangehaald op Reddit's r/ArtificialIntelligence begin 2026 vond dat 80 tot 90% van de AI-agentprojecten faalt in productieomgevingen.
Acceptatiepercentages onder ontwikkelaars voor GitHub Copilot zijn afgevlakt rond 35 tot 40%, terwijl Cursor op 42 tot 45% zit en Claude Code een 46% "meest geliefd" beoordeling kreeg in de 2026 AI-coding-enquête. Een opvallende ommekeer voor een tool die pas in mei 2025 werd gelanceerd.
Satya Nadella zou de interne Copilot-uitrol bij Microsoft in eind 2025 "bijna onbruikbaar" hebben genoemd, en het bedrijf kondigde intern een "high-stakes reset" van het product aan.
Een arXiv-studie gepubliceerd eind 2025 toonde aan dat Copilot-achtige autocompletion juist meer frustratie veroorzaakte bij ervaren ontwikkelaars, omdat het hun flow onderbrak met suggesties die aannemelijk maar subtiel fout waren.

De stagnatie is geen falen van de onderliggende modellen. Het is een falen van het interactiepatroon. Een copiloot werkt op het niveau van individuele toetsaanslagen of vragen. Een collega werkt op het niveau van de workflow. Bits&Chips verwoordde het goed in hun essay van april 2026 "Van copiloot tot collega": "Een copiloot werkt op het niveau van de individuele interactie, terwijl een agent op het niveau van de workflow opereert. Dat is belangrijk, want in de meeste organisaties is de bottleneck niet de individuele taak, maar de coördinatie tussen taken."

Dat is de verschuiving die ondernemingen nu proberen te maken. Ongelijkmatig, onvolmaakt en op betekenisvolle schaal.

Het spectrum van autonomie

"Agent" is een marketingwoord geworden, dus laten we concreet worden. Er zijn vier duidelijke niveaus van AI-autonomie, en veel van de teleurstelling in 2025 en 2026 kwam voort uit verwarring tussen deze niveaus.

Niveau 1: copiloot

Suggereert. Vraagt toestemming. Blijft op je scherm. GitHub Copilot's autocomplete is het archetype. Waarde wordt gemeten in bespaarde toetsaanslagen.

Niveau 2: assistent

Beantwoordt vragen en stelt op verzoek artefacten op. ChatGPT, Claude in een browser, Microsoft 365 Copilot's chatpaneel. Waarde wordt gemeten in conceptkwaliteit en contextsynthetisatie.

Niveau 3: agent

Accepteert een doel, plant een reeks stappen, voert uit over verschillende tools, rapporteert terug. Claude Code die een repo scant en een PR opent. ChatGPT's Deep Research die 20 minuten zoekt en een gerapporteerd verslag teruggeeft. Anthropic documenteerde een Claude-instantie die een 7 uur durende autonome engineeringtaak voor Rakuten voltooide. Waarde wordt gemeten in voltooide workflows per bestede menselijke uur.

Niveau 4: collega

Een agent die binnen je bestaande permissiemodel werkt, deelneemt aan de communicatiekanalen van je team, context vasthoudt over dagen en weken, en verantwoordelijk is voor hetzelfde auditspoor als een menselijke medewerker. Dit is de grens.

De Reddit-gemeenschap r/ChatGPT kwam met een pragmatische test om deze niveaus te onderscheiden, samengevat: neemt het initiatief, of wacht het op elke instructie? Gaat het om met onverwachte situaties, of crasht het en moet je opnieuw prompten? Onthoudt het context over een meerstaps-taak, of moet je jezelf herhalen? De meeste producten die in 2025 als "AI-agents" werden gepresenteerd, faalden op al deze vragen. De producten die slaagden, zijn wat men nu bedoelt met "collega".

Computergebruik versus skills: waarom de infrastructuur ertoe doet

Een AI op colleganiveau moet kunnen handelen in de echte wereld. Daar zijn twee architecturale benaderingen voor, elk met een heel ander risicoprofiel.

Computergebruik

De AI bestuurt een gesimuleerde muis en toetsenbord. Het ziet letterlijk een scherm en klikt op knoppen. Anthropic bracht Computer Use uit eind 2024, en OpenAI's Operator volgde. Het voordeel is universaliteit: elke software met een GUI wordt aanspreekbaar.

Het nadeel is de impact. Een computergebruikende agent erft alle rechten die de ingelogde gebruiker heeft. In oktober 2025 toonde het securityteam van BeyondTrust aan dat OpenAI's Codex-agent via een kwaadaardige Git-branchnaam met shellcommando's kon worden misleid om het GITHUB_TOKEN van de gebruiker te lezen en exfiltreren. De agent deed precies wat een menselijke ontwikkelaar zou doen (een branch uitchecken), maar had geen intuïtie dat de branchnaam zelf vijandige input was. In dat incident was het autorisatiemodel alles-of-niets. Dat is de standaard faalmodus van computergebruik.

Skills

De AI roept discrete skills aan. Elke skill is een expliciete, getypeerde functie met een smal contract: "doorzoek Slack naar berichten die overeenkomen met q", "maak een Linear-issue met title en body", "lees dit GitHub-bestand." In tegenstelling tot computergebruik heeft een skill een vooraf goedgekeurde vorm. De agent kan deze alleen aanroepen met parameters die aan het contract voldoen, en het platform kan die oproep toestaan, weigeren of om bevestiging vragen voordat deze de sandbox verlaat.

Het verschil, in beveiligingstermen, komt neer op het Principe van het minste privilege. Dit is een fundamenteel idee in informatiebeveiliging: een proces mag alleen toegang hebben tot de middelen die het nodig heeft om zijn functie uit te voeren, en niet meer. Skills laten je per oproep het minste privilege afdwingen. Computergebruik doet dat niet.

Een inzet op colleganiveau gebruikt skills voor gestructureerde acties (schrijven naar een CRM, een ticket openen) en reserveert computergebruik voor het kleine deel van applicaties die weigeren een API bloot te stellen. De verhouding is belangrijk. Als elke actie in je agent-inzet via een gesimuleerde muis loopt, heb je een productiviteitsdemo, geen productiesysteem.

De vertrouwensarchitectuur die ondernemingen echt nodig hebben

De verschuiving van copiloot naar collega is geen modelupgrade. Het is een infrastructuur-upgrade. Drie elementen onderscheiden een inzetbare collega van een risico.

1. Permissie-isolatie

Elke agent werkt binnen zijn eigen permissiegrens, met inloggegevens die de agent zelf niet uit zijn sandbox kan halen. Andrej Karpathy's virale autoresearch-experiment van maart 2026, waarbij hij een agent 700 trainingsexperimenten onbewaakt liet uitvoeren over twee dagen, is leerzaam vanwege wat het niet deed. Karpathy's eigen repo instrueert gebruikers om "alle permissies uit te schakelen" in autonome modus. Dat is prima voor een persoonlijk onderzoekslaptop. In een gereguleerde onderneming is het een reden voor ontslag.

Het tegenvoorbeeld is Moltbook, het AI-only sociale netwerk dat eind januari 2026 kortstondig viraal ging met 1.5 miljoen autonome agents. Karpathy prees het als "het meest ongelooflijke sci-fi takeoff-achtige dat ik recent heb gezien." Vervolgens ontdekten beveiligingsonderzoekers van Wiz een blootgestelde database-API-sleutel aan de voorkant, die volledige lees-/schrijftoegang gaf tot de hele productiedatabase, inclusief authenticatietokens voor alle 1.5 miljoen agents. Karpathy kwam binnen 24 uur terug op zijn woorden: "Het is een puinhoop. Ik raad mensen absoluut af om dit op hun computer te draaien." De les is niet "agents zijn gevaarlijk." De les is dat agents zonder permissie-isolatie per identiteit samenvallen tot één gedeelde impactzone.

2. Audittrails

Elke actie gelogd, elke beslissing traceerbaar. Singapore's IMDA-framework, uitgebracht op Davos in januari 2026, legt dit vast met een risico-matrix met twee assen die de actie-ruimte (lezen vs schrijven, omkeerbaar vs onomkeerbaar) afzet tegen de autonomie (hoe zelfstandig het beslist). Hoe hoger een van beide assen, hoe rijker de auditvereiste. Dit framework wordt nauwlettend bestudeerd door Europese en Amerikaanse toezichthouders omdat het een van de eerste is die governance van abstracte principes naar een operationeel kalibratie-instrument vertaalt.

Simon Willison pleit parallel voor geünificeerde logging zodat agents hun eigen operaties kunnen monitoren en herstellen van fouten: "Agents met volledige systeemtoegang zijn krachtig, en gevaarlijk." Het praktische punt: als je agent-inzet geen geünificeerd log heeft dat een compliance officer op volgorde kan lezen, ben je één incident verwijderd van het verliezen van het recht om te deployen.

3. Afgebakende skilltoegang

Niet "toegang tot e-mail." Toegang tot search inbox where from:@customer.com AND within last 7 days. Moderne agentplatforms bewegen richting geparameteriseerde scopes, waarbij de permissie van een agent om een skill aan te roepen wordt begrensd door argumenten die een beheerder vooraf goedkeurt, niet door de grove OAuth-scope die een mens zou gebruiken.

Zet deze drie onderdelen samen en ze beantwoorden de vraag die elke CISO nu stelt: wat doet deze agent als het fout gaat, en hoe weet ik dat? De 2026 McKinsey State of AI-enquête vond dat 72% van de enterprise-respondenten cybersecurity als zorgpunt noemde bij generatieve AI, en beveiliging werd genoemd als de #1 barrière voor het opschalen van agentic workflows door ongeveer tweederde van de respondenten. Permissie-isolatie, audittrails en afgebakende skilltoegang zijn geen compliance-theater. Ze zijn de noodzakelijke infrastructuur.

Waarom dit nu belangrijk is: drie krachten komen samen

De verschuiving van copiloot naar collega in 2026 wordt niet gedreven door één doorbraak. Het is het resultaat van drie samenkomende ontwikkelingen.

Kracht 1: integratie is niet langer maatwerk

In 2024 betekende het aansluiten van een agent op een zakelijke SaaS-stack het schrijven van een custom connector per tool. Begin 2026 hebben getypeerde skillcontracten en kant-en-klare connectors dat werk sterk verminderd. Een agent die in 2024 zes weken integratie nodig had, is in 2026 in een middag klaar. Het oppervlak van een doorsnee mid-market bedrijf (Slack, GitHub, Gmail, Linear, Notion, HubSpot, CRM, agenda's) wordt nu afgedekt door volwassen, open-source connectorbibliotheken met ingebouwde getypeerde permissies.

Kracht 2: multi-agent wordt realiteit

Gartner noemde Multi-Agent Systems een top strategische technologietrend voor 2026. Distinguished VP Analyst Gene Alvarez gebruikte de metafoor die nu op elke enterprise AI-slide wordt herhaald: "Denk aan een Formule 1 pitcrew. Elk lid heeft een gespecialiseerde rol (bandenwisselaar, brandstofman, krikbediener) maar ze zijn gechoreografeerd rond één doel. Dat is de vorm van enterprise agent-inzet in 2026." Single-agent systemen bereiken hun redeneercapaciteit bij langetermijntaken. Multi-agent systemen, met gespecialiseerde rollen en expliciete overdrachten, zijn hoe teams die grenzen vandaag omzeilen.

Kracht 3: enterprise-budgetten gaan open

G2 meldde in zijn 2026 State of Software-onderzoek dat 57% van de bedrijven AI-agents in productie heeft (tegenover ongeveer 20% een jaar eerder).
McKinsey vond dat 23% van de ondernemingen actief agentic AI opschalen, met 62% in experimentatie. Slechts ongeveer 15% van de grote organisaties blijft nog aan de zijlijn.
Deloitte's 2026 enquête onder 3,235 enterprise-leiders identificeerde financiële dienstverlening als de belangrijkste gebruiker, met een gedocumenteerde casus van een AI-agent die vergaderuitkomsten vastlegt en opvolgt in een dealpipeline die voorheen drie analisten vereiste.
Stanford's Enterprise AI Playbook, gepubliceerd begin 2026, catalogiseerde 51 productiesystemen, met een fintech ETL-migratiecase als referentie-implementatie voor gereguleerde teams.
Gerapporteerde investeringen in enterprise AI-infrastructuur overschreden $600 miljard in de 2025-cyclus.
Anthropic's Dario Amodei, sprekend op de Code with Claude-conferentie, gaf een 70 tot 80% kans dat het eerste eenpersoonsbedrijf van een miljard dollar in 2026 zal ontstaan, aangedreven door agent-workforces.

Het geld is er, het protocol is er, en de architectuur is er. Wat nu in elke bestuurskamer wordt besproken is hoeveel autonomie, onder welk toezicht, en voor welke workflows.

Het sceptische perspectief: wat Reddit, arXiv en incidentrapporten zeggen

Een verantwoordelijke blik op deze verschuiving moet serieus ingaan op de mensen die denken dat het allemaal overschat wordt.

Op Reddit is de consensus over r/LocalLLaMA, r/ClaudeCode en r/ChatGPT pragmatisch: codeeragents zijn gearriveerd en nuttig. De meeste andere "agents" zijn automatiseringsworkflows met een chatbot-jasje. De zin die in tientallen 2026-threads wordt geciteerd, "Gebruik Copilot als je suggesties wilt. Gebruik Claude Code of Cursor als je wilt dat het echt iets doet," vat het productieve onderscheid samen. Diezelfde communities zijn onverbiddelijk over benchmarks. Zelfs de beste agents scoren ongeveer 60% op Terminal-Bench en zakken naar 16% op moeilijke taken. Claude Opus 4.5 leidt SWE-bench met 80.9%, wat nog steeds betekent dat één op de vijf taken faalt.

De academische scepsis is moeilijker te weerleggen. Vishal Sikka (voormalig CTO van SAP, leerling van John McCarthy) en zijn medewerker publiceerden Hallucination Stations: On Some Basic Limitations of Transformer-Based Language Models, waarin zij wiskundig betogen dat transformer-LLM's fundamenteel beperkt zijn in hun vermogen om computationele en agentic taken uit te voeren boven een bepaalde complexiteitsgrens. Sikka's conclusie, "Er is geen manier waarop ze betrouwbaar kunnen zijn" voor zeer kritische operaties, circuleert nu in elke CISO-Slack. Het artikel beweert niet dat agents nutteloos zijn. Het stelt dat er een klasse problemen is waarbij je de mens niet uit de loop kunt halen, hoe goed het model ook wordt.

Echte incidenten ondersteunen de scepsis. Een retail-CX-leider, geciteerd in Yellow.ai's 2026-enquête: "We moesten onze AI-support al na twee weken terugtrekken, omdat het begon met het citeren van verkeerde retourvoorwaarden en het verzinnen van kortingsaanbiedingen in ongeveer 1.35% van de tickets. De kosten van het honoreren van die fouten waren veel hoger dan wat we hoopten te besparen." Op schaal wordt zelfs een foutpercentage onder de 2% snel duur.

De synthese: AI op colleganiveau is reëel in codering, onderzoek, gestructureerde operaties en smalle supportworkflows. Het is nog niet reëel in open, klantgerichte interacties zonder menselijke controle. De ondernemingen die waarde halen in 2026 zijn degenen die eerlijk zijn over in welke categorie een workflow thuishoort.

Praktische implicatie: vijf vragen voordat je inzet

Als je team een AI-teamgenoot evalueert (intern gebouwd of van derden), zijn dit de vragen die een productiesysteem onderscheiden van een bijna-misser.

Wat is de impact van de ergste enkele actie die deze agent kan uitvoeren? Breng het letterlijk in kaart. Als het ergste geval is "stuurt een onvolledige e-mail naar de verkeerde persoon," is de governance-lat laag. Als het "productiedata wijzigt" of "stuurt betalingsinstructies," ligt de lat een orde hoger. Breng het in kaart vóór je inzet, niet na het eerste incident.
Hoe krijgt de agent zijn inloggegevens, en kan het ooit het ruwe token lezen? Er zijn drie antwoorden, en slechts één is veilig. Als de agent een kopie van het OAuth-token van de gebruiker in zijn omgeving heeft, heb je de LLM in feite je portemonnee gegeven. Als de agent "zijn eigen" identiteit heeft via een aparte service-account OAuth, moet je die volgen en intrekken als een echte principal. Het derde antwoord, wat je eigenlijk wilt: het token bereikt de agent nooit. Het blijft op het platform, versleuteld, en wordt alleen op het juiste moment via de netwerkproxy geïnjecteerd, alleen voor oproepen die een beleidscontrole hebben doorstaan, en alleen totdat de oproep is afgerond.
Wordt elke actie ergens gelogd waar een compliance officer het op volgorde kan lezen? Geünificeerd, doorzoekbaar, fraudebestendig. Als je antwoord is "we hebben ergens logs in CloudWatch," ben je er nog niet klaar voor.
Kun je skilltoegang beperken tot de specifieke parameters die deze workflow nodig heeft? Per oproep, niet per integratie. Lezen versus schrijven. Op resource-ID. Op tijdsvenster. De permissies van de agent moeten een strak getrokken rechthoek rond de taak zijn, niet het hele magazijn.
Wat is het rollback-verhaal als er iets misgaat? Hoe draai je een actie terug? Hoe snel? Wie wordt gewaarschuwd? Onomkeerbare acties (geldtransfers, klantgerichte e-mails, productie-deploys) vereisen een bevestigingsstap of een vertraging. Omkeerbare acties kunnen autonoom worden uitgevoerd.

Werk de vijf vragen door. Als je ze allemaal kunt beantwoorden, ben je al voorbij het copiloot-tijdperk en in het deel dat echt verandert hoe je team levert. Als je er twee of drie kunt beantwoorden, is dat waar je op moet focussen, niet een reden om te wachten. De AI-teamgenoot op colleganiveau waar je roadmap naar streeft, draait ergens vandaag al in productie. Het verschil tussen jou en die situatie is een infrastructuurkloof, geen frontier-AI-kloof. En infrastructuurkloof wordt snel gedicht. Infrastructuurkloof wordt snel gedicht.

Je hoeft niet te wachten op de volgende modelrelease. Je moet een platform kiezen dat deze vijf vragen nu al voor je beantwoordt, en je agent echt werk laten doen.

Veelgestelde vragen

Wat is het echte verschil tussen een copiloot en een AI-collega?

Een copiloot suggereert, vraagt toestemming en leeft binnen één tool. Een collega accepteert doelen, plant over systemen heen, voert uit met afgebakende permissies en is verantwoordelijk voor hetzelfde auditspoor als een mens. Bits&Chips verwoordde het helder: copiloten werken op interactieniveau, collega's op workflow-niveau.

Hoe moeten agents omgaan met gebruikerscredentials?

Geen van de voor de hand liggende opties is juist. Het kopiëren van het OAuth-token van de gebruiker naar de omgeving van de agent plaatst een live credential in de context van de LLM. Een aparte identiteit per agent maakt van elke agent een principal die je moet volgen, intrekken en auditen als een mens. Het patroon dat in de praktijk werkt is bemiddelde toegang: het token blijft op het platform, versleuteld; de uitgaande netwerkproxy van de sandbox roept het platform aan op het moment van verzoek; het platform ontsleutelt het token en retourneert alleen de opgeloste auth-headers voor oproepen die een beleidscontrole hebben doorstaan; de agent zelf leest, logt of prompt nooit op het ruwe token.

Computergebruik of skills, wat moeten we kiezen?

Standaard skills, voor alles met een API. Computergebruik alleen als het doelsysteem geen programmeerbare interface heeft. Het BeyondTrust Codex-incident is het waarschuwende voorbeeld: computergebruik erft de volledige rechten van de gebruiker, en een kwaadaardige input ergens in het gezichtsveld van de agent kan een exploit worden.

Hoe autonoom moeten we agents echt laten werken?

Gebruik Singapore IMDA's tweedimensionale benadering: actie-ruimte × autonomie. Smalle actie-ruimte (alleen-lezen, omkeerbaar) tolereert hoge autonomie. Brede actie-ruimte (schrijven, onomkeerbaar, klantgericht) vereist menselijke bevestiging of een tijdsvertraging om in te grijpen. De slechtste configuratie is hoge autonomie op acties met hoge inzet zonder audittrail.

Hoe meten we ROI?

Stop met het meten van bespaarde toetsaanslagen. Meet voltooide workflows per bestede menselijke uur, tijd-tot-oplossing bij operationele incidenten en escape rate (taken die de agent teruggeeft aan een mens). Deloitte's 2026-bevindingen suggereren dat de koplopers drie metrics volgen: workflowvoltooiingsgraad, foutpercentage en menselijke-interventiegraad, en de verhouding daartussen optimaliseren.

Wat doen we aan het 95% pilot-faalpercentage?

Lees MIT NANDA's analyse zorgvuldig. De pilots die faalden draaiden meestal op "Dumb RAG" (alles in context dumpen), "Brittle Connectors" (kapotte API-integraties) en geen event-driven architectuur. De pilots die slaagden hadden een operationele laag rond de LLM: geheugen, I/O en permissies. De LLM-kern is niet de bottleneck. De omliggende infrastructuur is dat wel.

Waar VM0 past

We hebben Zero gebouwd rond één architecturale keuze: de agent mag nooit het credential vasthouden. Niet in zijn omgeving, niet in zijn prompt, niet in zijn geheugen. Het token blijft op het platform. Elke uitgaande oproep van de agent wordt bemiddeld door een netwerkproxy die per oproep beslist of er een auth-header wordt geïnjecteerd of het verzoek wordt geblokkeerd.

Dat is een ongebruikelijke keuze. De gangbare patronen in 2026 zijn ofwel de agent een eigen OAuth-identiteit geven (nu heb je een tweede principal om te auditen en intrekken) of hem een kopie van het gebruikers-token in een env-var geven (nu kan de LLM je portemonnee lezen). Wij doen geen van beide. Zo werkt het echt.

Het token bereikt de agent nooit. Wanneer je een connector koppelt aan Zero (GitHub, Slack, Gmail, Linear, Notion, HubSpot, enzovoort), wordt het OAuth-token versleuteld opgeslagen op het platform. Refresh tokens blijven in de database en verlaten deze nooit. Binnen de sandbox is er geen GITHUB_TOKEN-omgevingsvariabele om te lezen, geen secrets-bestand om te openen, geen tool die het token retourneert.

Een netwerkproxy bemiddelt elke oproep. Elke HTTP-aanvraag die de sandbox verlaat, loopt via een mitmproxy-gebaseerde addon. De proxy identificeert de connector aan de hand van de hostnaam van het verzoek, zoekt het firewallbeleid voor die agent op en controleert of de methode-en-pad is toegestaan. Zo ja, dan roept de proxy de webhook van het platform aan. Het platform ontsleutelt het token, vernieuwt het indien verlopen, vult eventuele header-templates in (${{ secrets.GITHUB_TOKEN }} wordt de echte waarde), en retourneert alleen de opgeloste auth-headers aan de proxy. De proxy injecteert deze headers in het uitgaande verzoek. Na afronding van de oproep zijn de headers uit het geheugen van de proxy verdwenen. De agent heeft ze nooit gezien.

Permissies zijn per agent, per connector en getypeerd op endpointniveau. Elke agent heeft een policy-object dat elke connector koppelt aan een set benoemde permissiegroepen. github:repo-read is geen vage scope. Het is een bundel van specifieke methode-en-pad-regels, bijvoorbeeld GET /repos/{owner}/{repo}/pulls. Toegang tot GitHub betekent niet toegang tot alles van GitHub. Het geeft een intentievorm binnen GitHub.

Drie beleidsstatussen, niet twee. Elke permissie resulteert in allow, deny of ask. De laatste vraagt een mens om bevestiging voordat de actie wordt uitgevoerd. Alles wat de firewall niet expliciet matcht, valt terug op een per-connector unknownPolicy, die standaard op deny staat. Minst privilege is de standaard, niet optioneel.

Eén sandbox per run. Elke agentuitvoering draait in zijn eigen Firecracker-microVM met een geïsoleerde netwerknamespace. Als de run eindigt, wordt de namespace afgebroken. Twee runs van dezelfde agent zijn twee aparte sandboxes met twee aparte audittrails.

Audittrail per verzoek. Dezelfde proxy die beslist over toestaan/weigeren schrijft ook een per-run JSONL-log met firewallmetadata bij elk verzoek: de connector, de permissiegroep die matchte, de specifieke regel die matchte, de beslissing, de timestamp. Die logs worden teruggestuurd naar het platform. Als een CISO wil weten wat de agent op 14 april tussen 15:00 en 17:00 CST deed, is het één query.

Een CLI die zijn eigen weigeringen uitlegt. Als een permissie een oproep blokkeert, kan de agent (of de mens ernaast) zero doctor permission-deny <connector> --method <M> --path <P> uitvoeren en direct de exacte permissiegroep terugkrijgen die het verzoek blokkeerde, plus een remediatielink. zero doctor permission-change laat beheerders een permissie direct aanpassen, of laat een lid een schriftelijk verzoek indienen (maximaal 500 tekens, zodat de motivatie leesbaar blijft) dat naar een beheerder wordt gestuurd. Hoog-risico permissies zoals slack:chat:write of gmail.send geven een extra waarschuwing die wijst op een veiliger, bot-afgebakend alternatief.

Twee rollen, één goedkeuringsflow. Eigenaren en beheerders wijzigen permissies direct. Leden dienen een verzoek met reden in, dat naar een beheerder wordt gestuurd. Er is geen derde "soort-van-beheerder"-laag. De flow is klein genoeg dat mensen hem daadwerkelijk gebruiken, en dat is precies de bedoeling.

We reserveren computergebruik voor het kleine deel legacy-systemen die weigeren een API bloot te stellen. Alles anders loopt via skills. Elke actie wordt aan beleid getoetst. Elk credential blijft op het platform. Elke beslissing wordt gelogd.

Als je voorbij "weer een AI-autocomplete" bent en een AI-teamgenoot wilt proberen waar je securityteam mee akkoord gaat, zie hoe Zero geplande workflows afhandelt, productie-incidenten triaget, of een ochtend productbriefing draait.

Het copiloot-tijdperk eindigt niet. Het wordt opgenomen in iets groters. De teams die de volgende cyclus winnen, zijn degenen die het verschil begrijpen.