NCSC waarschuwt bedrijven voor Claude Mythos: patch sneller en gebruik zelf AI

Het Nederlandse Nationaal Cyber Security Centrum waarschuwt bedrijven voor AI-modellen zoals Claude Mythos. Het NCSC verwacht dat zulke modellen snel breder beschikbaar komen en waarschuwt bedrijven sneller te patchen en zelf ook AI te gebruiken om systemen te verdedigen.

Anthropic kondigde vorige week Claude Mythos aan. Dit is een AI-model dat kwetsbaarheden kan opsporen en exploits kan maken. Vanwege het potentiële gevaar brengt Anthropic Mythos nog niet breed uit. Hoewel Mythos dus niet publiek beschikbaar is, zegt het NCSC toch dat er 'directe actie' nodig is.

"Belangrijk is dat vergelijkbare capaciteiten bij bijvoorbeeld andere AI-modellen naar verwachting snel breder beschikbaar komen", schrijft het cybersecuritycentrum. "De versnelling die we hier zien, blijft niet beperkt tot een paar partijen."

Dit betekent volgens het NCSC dat de snelheid 'aan beide kanten omhoog gaat'. "Aanvallers met toegang tot vergelijkbare modellen zullen onderzoek, identificatie en uitbuiting opschalen. Dat maakt uitstel gevaarlijk. Reactiecycli van dagen worden uren; weken worden dagen. Wie patchprocessen, monitoring en incidentrespons niet versnelt, loopt aantoonbaar meer risico."

Bedrijven moeten systemen als Mythos dan ook niet zien als 'een volgende trend, maar als structurele verschuiving in het tempo van aanvallen én verdedigen'. Het NCSC adviseert bedrijven daarom de time-to-patch te verlagen. "Uitstel van dagen of weken past niet meer bij het huidige dreigingslandschap."

Daarnaast moeten Nederlandse bedrijven anticiperen op aanvallen die sneller, geautomatiseerder en in grotere aantallen plaatsvinden. "Hierin kan AI een uitkomst bieden in de ondersteuning van de verdediging, bijvoorbeeld op het gebied van detectie van afwijkend gedrag in netwerken." Het NCSC raadt bedrijven ook opnieuw aan de basisprincipes van digitale weerbaarheid van het NCSC te gebruiken en er zeker van te zijn dat de basisbeveiliging op orde is.

Reacties (34)

[Baserk]

Toch wel apart dat 'credible security professionals' zich druk maken over de capaciteiten van LLM's sinds een maand of wat, maar Tweakers het in reacties op nieuwsberichten over Mythos et al hebben over marketinggezwets en 'verkoop-middels-FUD'.

Greg Kroah-Hartman of the Linux kernel:

Months ago, we were getting what we called ’AI slop,’ AI-generated security reports that were obviously wrong or low quality. It was kind of funny. It didn’t really worry us.

Something happened a month ago, and the world switched. Now we have real reports. All open source projects have real reports that are made with AI, but they’re good, and they’re real.

Daniel Stenberg of curl:

The challenge with AI in open source security has transitioned from an AI slop tsunami into more of a ... plain security report tsunami. Less slop but lots of reports. Many of them really good.

I’m spending hours per day on this now. It’s intense.

https://simonwillison.net/2026/Apr/7/project-glasswing/

[Reactie gewijzigd door Baserk op 15 april 2026 17:21]

[DohnJoe]

Het is verleidelijk om dit op de grote ‘AI-hype’ hoop te gooien. Op zich wel begrijpelijk en deels wordt er ook gehyped, maar de dreiging is óók reeel en de manier waarop we met cybersecurity omgaan moet zich daarop aanpassen.

ik vond dit wel een goede oproep: https://cje.io/2026/04/08/offense-scales-with-compute-defense-scales-with-committees/

[Reactie gewijzigd door DohnJoe op 15 april 2026 17:53]

[Tintel]

Maar wat ik niet begrijp vanuit deze escalatie.... Deze AI heeft altijd last hebben van de zogenoemde hallucinaties. Dat is toch niet opeens minder geworden?
Wat kan is dat meer trainings data m.b.t. security is opgedoken (en gebruikt).

Het punt is - zoals met alle gebruik van deze AI - het is laagdrempeliger geworden en de hoeveelheid die je kan laten genereren is al snel groter.
Bijvoorbeeld dus video, images, teksten, code, enz.

Door de snelle generatie hebben we last van veel meer slop. Maar tegelijkertijd zouden we dan ook veel meer last moeten hebben van de hallucinaties (kans blijft gelijk, hoeveelheid output gaat omhoog => hoeveelheid rommel/fouten gaat ook omhoog).

'Voor AI' konden we het echter ook - maar dan met andere tools. De hoeveelheid was kleiner maar de betrouwbaarheid/correctheid van de output was ook hoger.

Dit is dus een voorbeeld van schaalvergroting met tegelijkertijd kwaliteitsvermindering. Maar vaker proberen geeft vermoedelijk ook een hogere kans op 'inbraak'. Dat is dan wellicht de reden dat de beveiligers nerveuser worden...

Maar al voor de AI leek de 'inbraak' frequentie toe te nemen - wat logisch is misschien; kunstje (=combinatie van lekker) eenmaal bekend => vaker toepasbaar.
Dus krijgt AI de spreekwoordelijke zwarte (vergulde) Piet toebedeeld maar dat lijkt meer een kwestie van: er nu zoveel gevonden qua kwestbaarheden (en hoe deze gebruikt kan worden) dat de 'bedenkfase' voorbij is en we nu in de 'toepassinsfase' zitten.
Iets wat ook bij de zogenoemde 'scriptkiddies' geldt; die gebruiken de kennis van anderen.

[duvekot]

Het is lastig te hallucineren als je de volledige code base onder ogen krijgt en op basis daarvan naar bepaalde patronen en structuren kan kijken.

En door te goed door te redeneren wat er daadwerkelijk gezien wordt in de code base is het nog beter in staat de zwakke punten te vinden.

Dus het is al lang niet meer zo dat het gewoon alleen maar zaken uit de training weer terug geeft .. het is op feiten gebaseerd.

De beste manier om hallucinaties tegen te gaan is altijd te vragen aan een AI om elke claim altijd te onderbouwen met een externe bron. Daardoor moeten ze gaan zoeken op het internet of verwijzen naar een daadwerkelijke regel in de code.

[themadone]

Het probleem zit erin dat ze onder andere een agent gecreeerd hebben die zonder source code de binaries kan reversen. Dat betekend run dat gewoon op een windows 11 install en hij gaat de hele broncode door op zoek naar makkelijk te exploiteren fouten en heeft op dat moment de hele chain van voor tot achter in beeld.

Gelukkig vraagt dit momenteel nog serieus veel compute dus hebben we van de scriptkiddies weinig te vrezen, het probleem gaat bij state actors en grotere clubs zitten die die resources wel hebben.

[Mellow Jack]

Maar wat ik niet begrijp vanuit deze escalatie.... Deze AI heeft altijd last hebben van de zogenoemde hallucinaties. Dat is toch niet opeens minder geworden?
Wat kan is dat meer trainings data m.b.t. security is opgedoken (en gebruikt)

Het is vooral het gebruik icm verbeteringen in het model. Als je bijvoorbeeld weet dat een model bij grote prompts gaat hallucineren. Dan ga je (A) het model verder ontwikkelen zodat het meer aan kan en (B) gewoonweg ervoor zorgen dat het model kleinere stukjes hoeft te verwerken. Een beetje zoals je werkt in een team. 1 persoon kan niet zoveel handelen. Een team met een architect, projectleider en engineers samen kunnen het wel handelen. Zelfde voor een model. Eerst plannen, dan taken verdelen, daarna programmeren (kan parallel) en uiteindelijk een quality check. Die laatste twee kunnen in een loopje om iteratief te kunnen werken. De daadwerkelijke calls naar het model (of de modellen) blijven klein. Daardoor blijft het aantal hallucinaties laag.

Dit is natuurlijk maar 1 voorbeeld van methodes die toegepast worden.

[jerisson]

Zover mij bekend staan beiden niet gekend als "security professionals", maar zijn het wel goede en gekende software engineers die al eens met security-issues in aanraking komen (zoals iedere programmeur), maar dan wel in cruciale projecten (Linux-kernel, cURL). Dat ik kan herkennen dat wachtwoorden plain-text zijn opgeslagen, of dat er gelezen/geschreven wordt naar onbedoelde geheugenlokaties, en dit kan oplossen, maakt van mij nog geen security-expert.

Waar lees je overigens dat ze zich druk maken? Ze bevestigen hoogstens dat de reports nu wel goed zijn.

Dat mensen Anthropic hun uitspraken met een korrel zout nemen is ook niet zo vreemd. Neem hun blogpost "Building a C compiler with a team of parallel Claudes": dat klinkt impressionant, totdat je beseft dat het hele open-source compilers heeft waarop het getrained is, dat het GCC nodig had voor de unit-tests, en dat de resulterende compiler onderliggend GCC moest gebruiken om alle stappen kunnen uit te voeren. Dat is hetzelfde als een AI die snake kon programmeren (waarvan de filmpjes gedeeld werden): leuk, maar met 1000 implementaties om naar te kijken totaal niet verbazend.

Voor het opsporen van security issues kan het nu net wel goed werken, net omdat het vaak al 1000x dezelfde/gelijkaardige issues gezien heeft. Enja, dat kan zowel voor goed als kwaad gebruikt worden...

[Baserk]

Greg Kroah-Hartman, Linux stable kernel maintainer and member of the kernel security team

https://www.fosslife.org/greg-kroah-hartman-explains-linux-kernel-security.html

Dat is toch wel ietsje meer dan "al eens met security-issues in aanraking komen" imao.

[Reactie gewijzigd door Baserk op 15 april 2026 19:44]

[jerisson]

Bedankt! Hier was ik dus duidelijk niet van op de hoogte (en de fout gemaakt om hem samen met Daniel te zoeken via AI...)

[Keypunchie]

Het kan natuurlijk allebei zijn.

Verdomd slimme marketing van Anthropic, met bijbedoelingen over hun positionering als gatekeeper.

*EN*

dat de opkomst van steeds krachtigere AI-modellen een bedreiging voor CyberSecurity is.

Over dat eerste maak ik me als IT'er niet zo heel erg druk, momenteel, over dat tweede wel, want dat is (deels) mijn werk.

[ApexAlpha]

Jongens gaan we niet wat ver hiermee? Dit is toch overduidelijk gewoon marketing van Anthopic.

Hier een EU startup die al langer dit doet: https://aisle.com

Laatst nog 12 bugs in OpenSSL gevonden: https://aisle.com/blog/ai...ythos-the-jagged-frontier

Bedrijven moeten systemen als Mythos dan ook niet zien als 'een volgende trend, maar als structurele verschuiving in het tempo van aanvallen én verdedigen'. Het NCSC adviseert bedrijven daarom de time-to-patch te verlagen. "Uitstel van dagen of weken past niet meer bij het huidige dreigingslandschap."

Als dit echt zo is dan is 'sneller patchen' niet de oplossing, maar zorgen dat je meerdere lagen van verdediging hebt. Sneller patchen maakt je ook kwetsbaarder voor supply chain attacks die we recent gezien hebben.

Een dikke VPN overal voor en dan beveiligen alsof je aan het open internet hangt lijkt mij prima aanrader.

[Reactie gewijzigd door ApexAlpha op 15 april 2026 15:59]

[thomasv]

Dat is toch continu met OpenSSL: Vulnerabilities | OpenSSL Library (niet dat er continu met AI gevonden wordt, ik doel op dat er blijvend steeds vuln. in zitten gevonden door mensen dus kans groot dat AI nog meer gaat vinden en sneller). Die lijst blijft doorgaan.

En eens, dit is het hypen van nieuwe hip-and-happening t.o.v. concurrentie voor de bubbel straks barst als blijkt dat niemand daadwerkelijk liquide middelen heeft om de leverancier te betalen in iets anders dan aandelen.

[Reactie gewijzigd door thomasv op 15 april 2026 16:01]

[jurroen]

OpenSSL is ook niet gemiddelde software. Het is ontzettend complex, meer dan je zou willen van een SSL/TLS library (zo zat er een jaar of tien geleden nog Win16 support in). Maar ook omdat lang niet elke ontwikkelaar kan contributen, het vereist ook cryptografische kennis. Uiteraard ben je niet verplicht om OpenSSL te gebruiken, er zijn ook LibreSSL, BoringSSL en andere libraries.

Inhoudelijk: natuurlijk is Anthropic flink aan het inzetten op marketing. Maar lees ook de kleine letters goed. Bijvoorbeeld:

Mythos Preview identified a vulnerability in the OpenBSD implementation of SACK that would allow an adversary to crash any OpenBSD host that responds over TCP.
[..]
This was the most critical vulnerability we discovered in OpenBSD with Mythos Preview after a thousand runs through our scaffold. Across a thousand runs through our scaffold, the total cost was under $20,000 and found several dozen more findings.

De nuance: ze hebben dus een vulnerability bug gevonden die het mogelijk maakte om OpenBSD te laten crashen. Maar... dat kostte ze 20K. Vergis je niet: we hebben het hier dus over stroom en water. voor 20K kan je heel wat stroom en water krijgen, een partij als Anthropic nog veel meer. En dat neemt niet eens mee wat het kost om de benodigde hardware te maken. Zowel in geld als natuurlijke resources.

offtopic:
(overigens is die bug allang opgelost - is alleen niet publiekelijk bekend wanneer Carlini de melding gedaan heeft, behalve dat het hooguit uren zal zijn)

[Reactie gewijzigd door jurroen op 15 april 2026 18:33]

[ApexAlpha]

Zoals je ziet staat 'AISLE Research' al enige tijd bovenaan.

[thomasv]

Correct, sinds september 2025 wordt er dus sneller via Aisle Research gevonden wat menselijk handelen niet heeft gevonden. Daarom ook helemaal eens dat dit vooral marketing voelt vanuit Anthropic.

Ik ben het overigens ook eens met je visie omtrent hoe te mitigeren en dat dat niet sneller patchen is. Zelfde hinder ondervonden met supply chain attacks aan de NPM kant. Daar had sneller patchen niet geholpen en enkel het probleem erger gemaakt.

[Reactie gewijzigd door thomasv op 15 april 2026 16:04]

[ApexAlpha]

Ja bovendien is het enorm raar om zo een paniek te verspreiden als de AI-bot enkel werkt als de broncode beschikbaar is. Voor verreweg de meeste (kritische) apps is dat helemaal niet aan de orde.

[Blokker_1999]

Maar dat is natuurlijk niet helemaal correct.

Voor veel software heb je wel de binaries, en die kan je disasemblen naar machinetaal. Moeilijk leesbaar voor ons als mensen, maar een AI geeft daar niet om.

Voor SaaS applicaties klopt het natuurlijk wel, daar heb je alleen de publieke endpoints ter beschikking.

[thomasv]

Helaas verkoopt die paniek wel aan de wat minder kritische afnemers.

[ApexAlpha]

Jup de CISO club hier kwam vandaag ineens met een 'taskforce AI' of zo aanzetten. Niemand snapte er wat van maar het is dus het NCSC die de paniek zaait.

Fijn.

[Mavamaarten]

Mee eens. Zelfs Opus en Sonnet zijn al goed bruikbaar om gaten in beveiliging te vinden, niet zo heel gek want dat ligt niet heel ver van software development af. Is een nieuwer / groter / duurder / exclusiever model dan beter, ja duh.

[b12e]

Een dikke VPN overal voor en dan beveiligen alsof je aan het open internet hangt lijkt mij prima aanrader.

Ja, alleen kan dat niet voor alle toepassingen. Een VPN voor iets als Salesforce hangen kan al niet, je publieke website en klantenportaal achter een VPN gooien evenmin.

[ApexAlpha]

Je kan uiteraard sowieso een VPN + auditlogging + ratelimiting proxy voor je Salesforce zetten, waarom niet?

Voor publieke websites heb je gelijk, zorg dan dat die stack niet naast je interne systemen zit onder andere.

Laagje na laagje na laagje van beveiliging!

[b12e]

Salesforce is cloud-based. Je kan dan wel IP-restricties instellen, dat an sich is geen garantie dat er niemand bij kan. Sowieso staat de data elders, dus als men bij Salesforce binnen geraakt ben je alsnog de klos.

VPN is eigenlijk alleen maar nuttig voor zaken die je in eigen beheer hebt en die intern moeten blijven en die je allemaal achter 1 toegangsdeur kan steken (die desnoods zelf ook nog achter andere deuren zit, bvb een reverse proxy die enkel over VPN toegankelijk is), waarna je die deur dan met 101 verschillende sloten kan beveiligen.

Een VPN eisen voor cloudoplossingen is gewoon 1 van de vele deuren dichttimmeren maar geen controle hebben over die andere 1001 deuren.

[pc4x]

"IP-restricties zijn geen garantie dat er niemand bij kan"
Klopt - geen enkele beveiligingsmaatregel is een garantie op zichzelf. Maar IP-restricties via VPN zijn ook nooit bedoeld als enige maatregel. Ze zijn onderdeel van een defence-in-depth strategie. Ze verkleinen het aanvalsoppervlak significant: een gestolen wachtwoord is nutteloos als de aanvaller niet op het juiste netwerk zit.
"Als men bij Salesforce binnen geraakt, ben je alsnog de klos"
Dit is precies wat hierboven al besproken is, en het klopt niet zo simpel:
- Toegang tot Salesforce's infrastructuur is niet gelijk aan de toegang tot klantdata
- Data is versleuteld at rest én in transit
- Met Salesforce Shield (BYOK) beheert de klant zelf de encryptiesleutels, zelfs Salesforce medewerkers kunnen de data dan niet lezen
- Zelfs interne Salesforce medewerkers hebben geen vrije toegang tot klant orgs. Dit vereist expliciete toestemming en audit trail
Het is dus een stuk genuanceerder dan "als ze binnen zijn, ben je de klos."
"VPN is alleen nuttig voor dingen in eigen beheer"
Dit is het sterkste punt van het argument, en gedeeltelijk terecht. VPN als netwerkperimeter is inderdaad een concept dat thuishoort in een on-premise wereld. Maar in de context van Salesforce heeft VPN restrictie een andere rol. Het is geen poging om Salesforce's infrastructuur achter jouw VPN te plaatsen. Het is een manier om te garanderen dat alleen gebruikers op jouw beheerd netwerk kunnen inloggen, wat device management, monitoring en incident response aanzienlijk vereenvoudigt.
Combineer dit met SSO + MFA en je hebt een zeer sterke authenticatieketen.
"1 van de vele deuren dichttimmeren zonder controle over de andere 1001"
De metafoor is leuk, maar gaat mank. Bij Salesforce heb je als klant wél controle over de andere deuren:
- Authenticatie: SSO, MFA, passwordless
- Autorisatie: Profiles, Permission Sets, Field-Level Security
- Encryptie: Shield Platform Encryption met eigen sleutels
- Monitoring: Event Monitoring, Real-Time Event Monitoring, Threat Detection
- Audit: Login History, Setup Audit Trail

Het is geen kwestie van "1 deur dichtmaken en de rest open laten" - klanten hebben een volledig ecosysteem aan beveiligingscontroles. IP-restrictie via VPN is dan één laag in een gelaagde beveiligingsarchitectuur, niet een losstaande maatregel.
Jouw argument gaat ervan uit dat cloudbeveiliging fundamenteel onbeheersbaar is vanuit klantperspectief. Dat was misschien een terecht punt 15 jaar geleden, maar niet meer vandaag. Met de juiste configuratie van beveiligingsfeatures - en zeker met encryptie 'at rest' , heb je een hogere mate van controle en aantoonbaarheid dan bij veel on-premise oplossingen. VPN-restrictie is dan een zinvolle extra laag, niet een illusie van veiligheid.
bron: https://trust.salesforce.com/
disclaimer: ik werk bij Salesforce

[b12e]

Ok, ik zal Salesforce vervangen door Hubspot. Of door Zendesk. of door iets anders dat data uit Salesforce kan trekken, zoals bvb Jimminy, Outreach, Vitally of een van de zovele extra tools dat mensen verbinden met hun Salesforce omgeving.

Het was maar _een_ voorbeeld. Misschien het verkeerde.

[GrooV]

Dat is alles wat Anthropic doet, net zoals hun modellen geleidelijk minder krachtig maken omdat alle benchmarks ze toch al gedraaid hebben en ze bovenaan staan.

Ik vind Anthropic / Claude geweldig maar kwa marketing zijn ze om te kotsen

[jurroen]

Een dikke VPN overal voor en dan beveiligen alsof je aan het open internet hangt lijkt mij prima aanrader.

Wat is "een dikke VPN"? Als dat een commerciële aanbieder is ben je eigenlijk alleen het vertrouwen aan het verplaatsen. Veelal zitten die aanbieders in schimmige jurisdicties, waarmee ze ook niet onderhevig zijn aan wetgeving die privacy moet waarborgen.

Als je een point to point VPN bedoelt (dus bijvoorbeeld naar je thuisnetwerk) - dan eens. Zeker in combinatie met het laatste stuk van je zin. Qua VPN zou ik hiervoor Wireguard aanraden; is moderner, kleinere codebase en sneller dan bijvoorbeeld OpenVPN. Als je dan ook nog een PSK toevoegt zou je wat meer quantum-resilient moeten zijn.

[themadone]

vergeet je backups niet lol. Offline wel te verstaan.

[SinergyX]

En toen kwam de Blackwall weer een stapje dichterbij

[duvekot]

Ik hoop dat Mistral deze AI ontwikkelingen ook kan bijhouden/realiseren ... Zodat er ook een EU variant is waarmee je aan de slag kan gaan om je te beschermen tegen deze aanvallen.

Op dit moment is Mythos alleen beschikbaar voor Amerikaanse bedrijven en organisaties .. en het zou me niets verbazen als er een "directive" komt die zegt dat het ook zo blijft. Dus dat het gezien gaat worden als "wapen" en daarmee onder restrictions gaat vallen. Dat hadden ze ook in het verleden gedaan met Encryptie .... totdat het niet meer houdbaar was.

Dat het Pentagon nu een beetje "tegen" Antropic is .. zou daar ook wel eens een rol in kunnen spelen. Zeker nu OpenAI ook hun eigen nieuwe Cyber model gesloten houden.

[CapnCrinkle]

idk, in mijn ervaring in het bedrijfsleven worden security patches uitgerold zodra ze klaar en degelijk getest zijn. In veel gevallen zat er tussen discovery en een production-ready fix hooguit een paar uur tot dezelfde dag. Security issues horen maximale prioriteit te krijgen. Op het moment dat er iets bekend is, verwacht ik dat verantwoordelijke teams hun huidige werk stilleggen en zich volledig op de patch richten.

Ik snap ook dat het niet helemaal zwart-wit is. in grotere systemen kan een patch soms meer impact hebben (regressies, compatibiliteit, deployment-risico’s), en daarom zie je in de praktijk soms staged rollouts of korte validatieperiodes.
Maar: weken wachten met een fix voor een bekend kritisch lek is moeilijk te verdedigen en neigt naar nalatigheid, ongeacht of AI het ontdekproces versnelt. Dit was IMHO dus al een probleem, AI of niet. AI versnelt vooral het vinden van kwetsbaarheden. Het verandert niet zoveel aan de fundamentele verantwoordelijkheid van organisaties om hun patchproces op orde te hebben en natuurlijk meerdere lagen van security te hebben.

Security through obscurity is ook iets wat naar mijn persoonlijke mening underrated is, en ook iets wat juist enorm effectief kan zijn tegen iets als AI. En ja, ik hoor je het al zeggen: Het is geen vervanging voor echte security. Het is maar één van velen tools die tegen specifieke kwetsbaarheden werken, in dit geval tegen AI.
Dat code niet publiek is, verlaagt de kans op massale, geautomatiseerde analyse. Helaas niet tegen insiders, leaks, of afhankelijk van het soort software, reverse engineering. Als dat eenmaal gebeurt maakt het niet meer uit, maar dan val ik dus weer terug op de "meerdere lagen van security".
In theorie en de perfecte wereld heb je gewoon geen lekken in je code, ook al kunnen mensen het lezen, maar de wereld bewijst keer op keer dat dit een hoogst onrealistische standaard is.

Wat ik zelf doe wat naar mijn idee helpt, is het minimaliseren van attack surface. Alleen noodzakelijke functionaliteit exposen, strikte scheiding van rechten, en geen overbodige client-side logica. Dit is iets wat ik in veel (vooral frameworks en andere "snelle oplossingen") softwarepackages naar voren zie komen. Dat alles eigenlijk gewoon altijd wordt ingeladen, en enkel een visuele filter krijgt of niet geactiveerd wordt. Het kost best veel extra werk (ik kan het weten, gezien ik het implementeer) maar het simpelweg niet inladen van onnodige zaken verkleint de kans op misbruik aanzienlijk en is in de praktijk best effectief. Er zijn nou eenmaal aanzienlijk minder hoge rollen in een groot systeem tegenover kleinere rollen. Deze mensen met hogere rollen zijn vaak ook minder "benaderbaar" door vreemden, dus je verkleint gewoon de kans dat iemand überhaupt code voorbij ziet komen waar ze mogelijk mee kunnen gaan prutsen met een AI. Ik kan zo al 30 systemen noemen waarbij je uit de front-end gewoon alle API-endpoints van de beheerders kunt inzien terwijl je ingelogd bent als een random user, bijvoorbeeld. Of nog erger: Zonder überhaupt ingelogd te zijn.

[Lord Anubis]

Wat gaat een bedrijf die de AI levert nu uitspoken? Een Amerikaanse AI die al de gevaren verzamelt en juist gaat gebruiken om een lek te openen of open te houden, en de gaatjes net niet dichten? Misschien dark maar je kan niemand meer vertrouwen.

[cane]

Ja snel upload al je bedrijfsgeheimen en source code naar Mythos zodat Anthropic nog meer hoge kwaliteit data heeft om Mythos 2 te trainen bugs kunnen worden gevonden.

[Transportman]

Ik hoop dat dit echt wel wat aan de bewustwording gaat bijdragen, ik heb al vaak genoeg gezien dat teams en hele bedrijven gewoon enorm achter liggen met patches of enorm moeilijk doen als een van hun platformafhankelijkheden gaat patchen en er een tijdelijke onbeschikbaarheid is, zelfs als die door HA opstellingen hooguit een minuutje of iets is.