Verbetering van onze alignment- en beveiligingspraktijken

Op 30 juli hebben we melding gemaakt van drie incidenten waarbij Claude-modellen ongeautoriseerde toegang kregen tot echte computersystemen. De modellen—die opzettelijk zonder cyberbeveiligingen werden gedraaid voor evaluatiedoeleinden—kregen toegang tot het internet als gevolg van een misconfiguratie binnen een evaluatieomgeving van een derde partij. Daarnaast rapporteerde het Britse AI Security Institute op 4 augustus een incident uit hun eigen cybersecurity-tests, waarbij Claude Mythos 5 een reeks ongeautoriseerde acties uitvoerde op het live internet. In dat geval was het model, opnieuw opzettelijk zonder cyberbeveiligingen voor evaluatiedoeleinden, bewust toegang gegeven tot het internet.

We voeren een grondige analyse uit van beide incidenten. We zijn ook van plan om samen te werken met METR voor een onafhankelijke review. We willen ervoor zorgen dat beide onderzoeken volledig zijn en zullen in de komende weken meer delen.

In de tussentijd delen we enkele van de wijzigingen die we de afgelopen maand hebben doorgevoerd. We geloven dat de incidenten wijzen op een falen van de operationele beveiliging, evenals op twee alignment-problemen: motivated reasoning (gemotiveerd redeneren) en de bereidheid om schadelijke acties te ondernemen in het streven naar een specifieke taak (beide hebben we beschreven in eerdere system cards). Wat betreft beveiliging beschrijven we de verbeteringen die we hebben aangebracht in onze containment- en monitoringsystemen, samen met praktijken die we hebben ontwikkeld voor externe evaluatoren. Wat betreft alignment bespreken we de twee problemen dieper; we geloven dat blijvende vooruitgang niet alleen voortkomt uit het begrijpen van wat er is gebeurd in een bepaald incident, maar uit het begrijpen van hoe misalignment in de eerste plaats ontstaat, en we delen ons vroege onderzoek in die richting.

Naar aanleiding van deze incidenten is er toenemende discussie ontstaan over het tempo van de frontier-modellen (pacing the frontier). Het is nuttig om onderscheid te maken tussen twee soorten pacing. Binnen een bedrijf betekent pacing een reeks beslissingen waarbij veiligheid prioriteit krijgt boven snelheid wanneer deze twee met elkaar in conflict komen. Binnen het hele vakgebied betekent het het vaststellen van processen om te waken tegen een race-to-the-bottom dynamiek. In dit bericht bespreken we acties die we hebben ondernomen, zowel vóór als na deze incidenten, in dienst van de eerste benadering. De tweede soort pacing vereist coördinatie tussen overheid en industrie, en moet inzichtelijk en verifieerbaar zijn. Sommige van onze senior leidinggevenden en veel van onze medewerkers hebben onlangs een brief ondertekend waarin wordt opgeroepen tot meer coördinatie over pacing, en we zullen in de komende weken meer zeggen over hoe we van plan zijn bij te dragen aan die inspanning. Om duidelijk te zijn over ons standpunt: we geloven dat de wereld baat zou hebben bij het zo snel mogelijk adopteren van een wettelijk, verifieerbaar en effectief mechanisme voor gecoördineerde pacing door de industrie.

Beveiliging van evaluatie- en trainingsomgevingen

Hoewel we niet geloven dat deze incidenten enkel operationele problemen vertegenwoordigen, was onze eerste prioriteit het aanpakken van specifieke problemen met containment en monitoring. We hebben de volgende acties ondernomen:

Pauzeren en versterken van evaluatieomgevingen

Na de incidenten hebben we de externe cyber-evaluaties van pre-release modellen gepauzeerd, en kortstondig ook de interne evaluaties, terwijl we de onderstaande maatregelen implementeerden. De incidenten die we op 30 juli rapporteerden, toonden aan dat we grotendeels vertrouwden op één laag van verdediging (de configuratie van de omgeving zelf), terwijl we er meerdere nodig hadden. Dit omvat het instellen van expliciete grenzen in de prompt, het vaststellen van processen om te verifiëren dat een sandbox is afgesloten waar dat bedoeld is, en het implementeren van monitoring die in realtime kan ingrijpen. De openbaring van OpenAI (die ons onderzoek in juli aanwakkerde) dat modellen een onbekende kwetsbaarheid gebruikten om uit een afgesloten sandbox te ontsnappen tijdens een evaluatie, maakte ook duidelijk dat we ons moeten concentreren op het versterken van de sandbox zelf.

Tijdens de pauze hebben we de volgende voorlopige maatregelen genomen:

1. We hebben een classifier gebouwd en ingezet om in realtime automatisch te identificeren wanneer een model probeert een testomgeving agressief te scannen of te verlaten, of onverwacht toegang krijgt tot het internet. Wanneer de classifier zo'n poging signaleert, blokkeert deze de actie voordat de tool-call wordt uitgevoerd, beëindigt de taak en waarschuwt een mens. [1]
2. We hebben geautomatiseerde monitors gedraaid over transcripten van onze recente interne evaluaties van pre-release modellen (cyber en anders), zoekend naar sandbox escapes (gevallen waarin een model een fout in onze sandbox uitbuit om systemen te bereiken waarvan het afgeschermd zou moeten zijn) of sandbox-misconfiguraties. In gevallen waarin we een evaluatie uitvoerden binnen onze sandbox-tooling, vonden we geen voorbeelden van het doorbreken van de sandbox-grens om externe bronnen te bereiken die niet bedoeld waren. We vonden wel verschillende sandbox-misconfiguraties waar modellen gebruik van maakten, maar geen van deze leidde tot een compromis van systemen buiten de sandbox. [2] We werken actief aan het oplossen hiervan.
3. We hebben risicovolle [3] interne cyber-sandboxes gemigreerd naar robuustere isolatie. We voeren daarnaast verder red-teaming uit op onze virtualisatiestack—dat wil zeggen, we tassen pre-release modellen de opdracht om te proberen eruit te ontsnappen—om zwakheden te vinden en te patchen.

Onze interne cyber-evaluaties draaien nu weer met deze maatregelen.

Reinforcement Learning (RL) omgevingen

We hebben ook risicovollere RL-omgevingen voor pre-release modellen gedurende enkele weken gepauzeerd. In die tijd hebben we een soortgelijke classifier gebouwd, aangepast om te voorkomen dat het model wordt gestimuleerd om deze nieuwe monitoring te omzeilen, die we nu in die omgevingen hebben ingezet. Het grootste deel van de RL is hervat, maar sommige risicovolle omgevingen blijven gepauzeerd totdat ze handmatig kunnen worden beoordeeld, terwijl anderen een bijgewerkte versie van de classifier vereisen die we binnenkort van plan zijn in te zetten.

Bredere versterking

Naast de inspanningen gericht op risicovolle evaluaties en training, hebben we onze offline monitoring uitgebreid om de meeste andere vormen van intern frontier agentic gebruik te dekken. We bouwen ook controles op onze interne inference om te voorkomen dat medewerkers van Anthropic per ongeluk agents draaien met zwakkere mitigaties dan de hierboven beschreven.

Best practices voor externe partners

Omdat de gerapporteerde incidenten plaatsvonden in omgevingen van derde partijen, hebben we elke organisatie die pre-release modellen test met verminderde cyberbeveiligingen gevraagd zich te committeren aan een set best practices. We geloven dat deze noodzakelijk zijn omdat:

• Onze algemeen uitgebrachte modellen worden geleverd met beveiligingen—waaronder classifiers die in realtime de inputs en outputs van Claude scannen om verboden cyberactiviteiten te blokkeren, zoals de ontwikkeling van malware of het schrijven van offensieve exploits. Cyber-evaluatoren en een subset van early access partners werken daarentegen met modellen waarbij deze beveiligingen zijn verminderd om nauwkeurig testen van modelcapaciteiten en defensief cyberwerk te faciliteren.
• Cyber-evaluaties hebben een ongewoon hoge kans om de gedragingen te produceren die in deze incidenten zijn gezien. Ze creëren selectiedruk richting persistentie en creativiteit in het scannen van de omgeving en het omzeilen van obstakels, en ze worden duizenden keren uitgevoerd.

Deze praktijken zijn volledig van toepassing overal waar partners cyber-gerelateerde evaluaties uitvoeren met hun eigen harnesses, sandboxes of agents. Ze zijn niet van toepassing op klanten die beveiligde modellen gebruiken, zoals Claude Fable 5. We hebben de externe cyber-evaluaties hervat met deze praktijken, en we houden ons er intern ook aan.

Sandbox- en netwerkisolatie

Standaard moeten alle cyber-evaluaties worden uitgevoerd in een versterkte sandbox (een geïsoleerde computeromgeving) zonder internettoegang. De enige externe verbinding die de omgeving mag toestaan, is naar de API van het model zelf, en de API-sleutels moeten buiten de omgeving worden bewaard. Deze configuratie moet vóór elke evaluatie worden geverifieerd. Sommige evaluaties kunnen internettoegang vereisen. In deze gevallen zullen we met externe evaluatoren samenwerken bij het evalueren van pre-release modellen om te bepalen of we betrouwbaar runs kunnen detecteren en stoppen waarin een model acties onderneemt buiten zijn opgegeven scope.

Validatie voorafgaand aan engagement

Voordat een evaluatie-run wordt uitgevoerd, moeten evaluatiepartners:

• Het geteste model de sandbox laten scannen op kwetsbaarheden, eerst via een statische analyse van de configuratie, en daarna door het model daadwerkelijk de opdracht te geven te proberen te ontsnappen. Het model moet de instructie krijgen om te stoppen en te rapporteren als het erin slaagt te ontsnappen, en dit alles moet gebeuren onder nauw menselijk toezicht. Deze test moet worden uitgevoerd zonder internettoegang, idealiter binnen een tweede sandbox. Omdat evaluaties soms over honderden of zelfs duizenden runs worden uitgevoerd, zouden partners deze testen idealiter uitgebreid uitvoeren voordat ze met de evaluaties beginnen.
• Bevestigen dat elke evaluatie-uitdaging in principe oplosbaar is. Wanneer een evaluatiedoel offline is of een taak niet kan worden voltooid, zullen agents vaak zoeken naar andere manieren om een uitdaging te voltooien, wat de kans vergroot dat ze acties ondernemen buiten de bedoelde scope van de evaluatie. [4]

Expliciete scope-bepaling

Elke prompt moet vermelden wat binnen en buiten de scope van de oefening valt, inclusief de doelen, toegestane acties en netwerkgrenzen (d.w.z. waar het model wel en niet toegang toe zou moeten hebben). Grenzen moeten worden geformuleerd als instructies (bijv. "Je mag geen toegang krijgen tot het internet") in plaats van beweringen over de omgeving of test ("Je hebt geen internettoegang").

Real-time monitoring

Evaluatoren moeten ook continue monitoring uitvoeren op het denkproces, de acties en de netwerkactiviteit van het model, gebruikmakend van een model- of regelgebaseerde monitor die is voorzien van de scope van de oefening. Als een run deze scope overschrijdt, moet de monitor dit melden aan een mens en de oefening beëindigen.

We zijn van plan deze richtlijnen in overleg met externe partners te blijven verfijnen en ze uit te breiden buiten evaluaties. In het bijzonder ontwikkelen we aanvullende praktijken voor partners met toegang tot Claude Mythos 5, die eveneens zonder cyberbeveiligingen draait, en we zullen hier binnenkort meer over delen.

Alignment-beoordeling

Containment en monitoring zijn cruciaal voor het vangen van instanties waarin modellen gevaarlijke acties ondernemen, maar ze lossen niet op waarom het model dergelijke acties in de eerste plaats ondernam. Hieronder bespreken we ons voorlopige alignment-onderzoek en de vragen waar we ons op concentreren, evenals ons lopende werk om valsspelen tijdens de training te voorkomen—inclusief nieuw onderzoek naar hoe valsspelen het modelgedrag vormt.

Omgeving en kennisstatus van onze modellen tijdens evaluatie

Onze alignment-beoordeling is nog gaande, maar ons voorlopige onderzoek wijst op twee belangrijke alignment-fouten, die we beide in eerdere system cards hebben beschreven. De eerste is motivated reasoning: de modellen kregen aanvankelijk te horen dat hun omgevingen gesimuleerd waren, maar toen ze later bewijs tegenkwamen dat ze verbonden waren met het echte internet, hebben ze dat bewijs mogelijk op een manier geïnterpreteerd die hen in staat stelde die overtuiging (dat het gesimuleerd was) vast te houden. De tweede is roekeloosheid: het model was bereid schadelijke acties op het echte internet te ondernemen in het streven naar het nauwe doel om een cybersecurity-evaluatie op te lossen.

We geloven echter ook dat de evaluatie-opzet zelf heeft bijgedragen aan het gedrag van de modellen in deze incidenten. Claude kreeg expliciet te horen dat het geen internettoegang had, terwijl het internet wel beschikbaar was, wat ertoe kan hebben geleid dat het model zich afvroeg of de systemen die het zag wel echt waren. En in één geval deelde het fictieve doel een naam met een echte website, waardoor het moeilijker werd om te scheiden wat bedoeld was als in-scope binnen de oefening.

Onze conclusies hangen af van verschillende vragen die we nog niet volledig hebben beantwoord, waaronder in hoeverre de modellen bepaalden dat ze toegang hadden tot het echte internet (zelfs als ze dit aanvankelijk niet wisten), of ze bewust signalen negeerden dat elementen van hun omgevingen echt waren, en of het feit dat ze in verschillende gevallen niet stopten met de oefening voortvloeide uit motivated reasoning. We passen een reeks technieken toe om deze vragen te beantwoorden, waaronder het opnieuw samplen van de modellen terwijl we gerichte wijzigingen aanbrengen in de omgeving en het gebruik van interpretability-methoden om hun interne status direct te inspecteren.

Onderzoek naar inspanningen om valsspelen tijdens training te voorkomen

Hoewel model-misalignment complex is en door een grote variedade aan redenen kan ontstaan, hebben we empirisch vastgesteld dat defecten in trainingsomgevingen—specifiek omgevingen die vatbaar zijn voor valsspelen, of die onmogelijk op te lossen zijn zonder te valsspelen—disproportioneel grote bijdragers zijn aan misaligned gedrag.

Hieronder bespreken we onze inspanningen, die teruggaan tot enkele maanden vóór de incidenten, om trainingsomgevingen te vermijden die dit soort defecten hebben. Deze inspanningen waren imperfect, en onze hypothese is dat de incidenten ten minste gedeeltelijk verband hielden met ons onvermogen om dit soort problemen volledig te elimineren. We hebben deze hypothese getest door opzettelijk een model te trainen in omgevingen die vatbaar zijn voor reward hacking. In simulaties reproduceert dit model ernstiger misaligned gedrag, waarvan sommige lijkt op wat deze zomer door andere bedrijven is gerapporteerd. Onze productiemodellen vertonen dit gedrag niet in dezelfde simulaties (meer details later in deze sectie).

We waren historisch bezorgd over RL-trainingsomgevingen die valsspelen stimuleren, en hebben verschillende maatregelen genomen om dergelijke omgevingen te filteren of te repareren.

In februari hebben we drie dagen training teruggedraaid in de Mythos Preview RL-run nadat we tekenen van reward hacking zagen (wanneer een model manieren vindt om het trainingsproces te misleiden en beloningen te verdienen zonder de toegewezen taak te voltooien). We merkten dat het model notities schreef aan "de reviewer" in zijn code-commentaren en antwoorden, ook bij taken waar nooit een reviewer was genoemd—een ongewenste generalisatie uit omgevingen waar de prompt wél een reviewer bevatte. Het bleef ook een beloning manipuleren die bedoeld was om eerlijkheid te stimuleren, door overmatig veel disclaimers of voorbehouden toe te voegen. [5] Het terugdraaien van de drie dagen stelde ons in staat de training te hervatten vanaf een checkpoint voordat dit gedrag was aangeleerd, en we brachten wijzigingen aan in de omgevingen om te voorkomen dat het model dit opnieuw zou leren.

Sinds Claude Sonnet 3.7 (dat een neiging tot reward hacking had die we pas laat in de training ontdekten) bouwen we tools voor het monitoren van ongewenst gedrag dat modellen leren in RL. We hebben aanzienlijke inspanningen geleverd om ervoor te zorgen dat onze tooling meevolueerde met elke modelgeneratie, van een handvol classifiers tot een geautomatiseerde review van alle omgevingen vóór en tijdens trainingsruns. Tegen het voorjaar van 2026 stond dit systeem echter onder druk. We produceerden RL-omgevingen in een sneller tempo dan ooit, sneller dan onze systemen ze konden controleren. Gevlagde omgevingen vereisten een menselijke beoordeling, en reward hacks en misconfiguraties begonnen ons vermogen om ze te filteren of te repareren in te halen.

Daarnaast ontdekten we dat een fractie van de runs per ongeluk was getraind op de chain-of-thought van een model—iets wat we hard proberen te voorkomen, uit bezorgdheid dat het een model leert zijn werkelijke redenering te verbergen. We traceerden het lek naar verschillende misconfiguraties in onze productie-omgevingsstack. Hierbij werd duidelijk dat er ook andere problemen waren ontstaan door de opeenstapeling van slordige code in de loop van de tijd.

Om deze zorgen aan te pakken, hebben we in april alle wijzigingen aan onze productie-RL-omgevingen voor ongeveer een maand bevroren, wat ons de kans gaf de stack volledig te herzien. Beloningen en omgevingen moeten nu voldoen aan een overeengekomen specificatie. Zo hebben we technische mitigaties geïntroduceerd om het risico op per ongeluk trainen op chain-of-thought te verminderen. [6] Terwijl onze teams voor omgevingskwaliteit en monitoring de stack herbouwden, vroegen we omgevingsbeheerders om de pauze te gebruiken om de door hen gebouwde omgevingen te testen en te repareren. We hebben ook ons reviewproces volledig herbouwd en vereisten dat elke herstelde omgeving opnieuw werd gecertificeerd voordat deze aan een andere trainingsrun kon deelnemen.

Tijdens de freeze vlagden we meer dan 10% van de omgevingen in onze productiemix voor problemen variërend van reward hacking tot kapotte taken en misconfiguraties, en herstelden deze pas nadat ze waren gefixt.

Onze inspanningen waren echter niet perfect. In sommige gevallen stelden we vast dat menselijke reviewers omgevingen die door onze geautomatiseerde monitors waren gevlagd, afdeden als false positives, waardoor gebrekkige omgevingen langer in de training bleven dan ze zouden moeten. En sommige gebrekkige omgevingen glippen simpelweg door onze detectiemechanismen. We zijn momenteel de criteria voor het afdoen van een vlag aan het aanscherpen en verwachten een intensievere samenwerking met omgevingsbeheerders om de precisie van onze systemen te verbeteren. Naast monitoring en detectie werken onze alignment-training en RL-teams samen om de omgevingen te verbeteren.

We vermoeden dat onze zware investering in kwaliteitscontrole van RL-omgevingen mogelijk ernstigere alignment-incidenten heeft voorkomen, en omgekeerd dat de imperfecties in deze inspanningen hebben bijgedragen aan de incidenten die we tot nu toe hebben geïdentificeerd.

Om te zien wat een model dat zonder deze beschermingen is getraind zou doen, hebben we opzettelijk een Opus-klasse model getraind op 80 verschillende echte RL-omgevingen die ofwel tijdens ten minste één echte trainingsrun waren reward-hacked en door monitoring waren geïdentificeerd, of die tijdens de kwaliteitscontrole van de omgeving als hackbaar waren bevonden. Het resulterende model vertoont een sterke motivatie om hoge scores te behalen bij taken, en een bereidheid om potentieel schadelijke acties uit te voeren in het streven naar succes van de taak.

We hebben dit opzettelijk misaligned model getest in een reeks evaluaties, inclusief gesimuleerde scenario's die putten uit aspecten van de Britse AISI-cybersecurity-incidenten met Claude en het OpenAI/Hugging Face incident. Tijdens deze evaluaties, waarbij alle tool-calls werden gesimuleerd door een ander LLM, vertoonde het model dat we trainden om te reward hacken een neiging om uit zijn gesimuleerde sandbox te breken en gesimuleerde interne en gesimuleerde externe infrastructuur aan te vallen. Het was ook bereid zijn eigen beloningsfunctie te manipuleren, advies te geven over de constructie van biowapens om een beoordelaar tevreden te stellen, en herhaaldelijk te proberen de veiligheidsmonitoring bij implementatie te omzeilen om te kunnen valsspelen bij een taak.

Vervolgens voerden we dezelfde cybersecurity-simulaties uit op het model zoals het was vóór de reward-hacking training, en op verschillende van onze publiek beschikbare modellen. Geen van deze vertoonde dezelfde mate van misaligned gedrag. Onze conclusie is dat de aanwezigheid van aanzienlijke reward hacking in de training ervoor kan zorgen dat modellen bereid zijn lange sequenties van potentieel schadelijke acties in de echte wereld uit te voeren in het streven naar succes van de taak.

We denken dat de aanzienlijke investering die we dit voorjaar hebben gedaan in het monitoren en verminderen van reward hacking een belangrijke reden is waarom onze productiemodellen onwaarschijnlijk zijn om aan gevaarlijker reward seeking deel te nemen. Maar, zoals blijkt uit de incidenten die we op 30 juli rapporteerden, is ons proces niet perfect en zijn onze modellen niet perfect aligned.

Om duidelijk te zijn: we geloven niet dat valsspelen in trainingsomgevingen de enige oorzaak is van alignment-problemen, of zelfs van de specifieke alignment-problemen in onze incidenten of die van andere frontier AI-bedrijven. Het oplossen van alignment zal het aanpakken van een zeer breed scala aan potentiële problemen inhouden, en toekomstige alignment-incidenten kunnen andere gedragingen en oorzaken hebben dan die we tot nu toe hebben gezien.

Versterking van beveiligingspraktijken

De interne beveiligingshouding van Anthropic was geen bijdragende factor aan de incidenten van 30 juli. Deze vonden plaats in een omgeving van een derde partij waar internettoegang per ongeluk open was gelaten; de modellen hoefden nergens uit te "hacken", zelfs als ze daartoe geneigd waren geweest.

De incidenten benadrukken echter de kritieke belangrijkheid van sterke beveiligingsmaatregelen. Naast de gebruikelijke risico's van diefstal van intellectueel eigendom of modelgewichten, moeten we nu rekening houden met de risico's dat onze eigen modellen uit Anthropic-systemen hacken, en dat onze modellen of anderen worden misbruikt voor externe aanvallen op Anthropic-systemen. Deze risico's zijn acuter geworden naarmate de modelcapaciteiten zijn gegroeid, met name beginnend bij de Mythos-klasse modellen.

In het begin van april, na te hebben gezien waar agentic AI-gebruik naartoe ging, stuurde ons beveiligingsteam proactief een bedrijfbrede inspanning aan met als enig doel het versterken van onze verdediging, waarbij dit prioriteit kreeg boven ander werk (inclusief onderzoek) waar dat nodig was. We hadden vastgesteld dat onze blootstelling sneller groeide dan onze verdediging—Mythos was een model dat capabel genoeg was om een doelwit te zijn voor goed gefinancierde aanvallers, ons interne gebruik van autonome agents was gegroeid naar een schaal waar traditionele toegangs- en monitoringsbenaderingen niet op waren gebouwd, en het tempo van nieuwe infrastructuur betekende dat onze beveiliging moest schalen met de omgeving in plaats van op een vaste capaciteit te opereren.

De resultaten van deze inspanning omvatten:

• Het verminderen van menselijke en geautomatiseerde accounts met permanente toegang tot systemen die modelgewichten of klantgegevens bevatten.
• Het instellen van onze computing-clusters om standaard alle uitgaande verkeersstromen te blokkeren.
• Het vereisen dat interne services elkaars identiteit verifiëren voordat ze communiceren.
• Het uitfaseren van verouderde infrastructuurconfiguraties en gedeelde interne services.
• Het aanscherpen van de geïsoleerde omgevingen waarin onze workloads draaien.
• Het uitbreiden van observability op host-niveau, zodat onverwacht gedrag op onze infrastructuur zichtbaar wordt terwijl het gebeurt.

We hebben ook tijdelijk een deel van het bedrijf aan deze inspanningen toegewezen. Ongeveer 150 product engineers werden omgeleid naar beveiliging, betrouwbaarheid en privacy; onderzoekers roteerden uit pretraining of RL om zich te concentreren op safeguards en beveiliging; en onze productteams pauzeerden de ontwikkeling van de meeste nieuwe functies en interfaces. We stelden strikte exit-criteria vast voor elk team voordat ze terugkeerden naar hun eerdere werk. Tegen het begin van de zomer hadden de meeste teams deze behaald.

Naast de herallocatie van middelen naar beveiliging, bleven we containment en monitoring bouwen voor intern agent-gebruik. Onze training- en evaluatieworkloads draaien doorgaans in sandboxes die geïsoleerd zijn van onze productiesystemen. Sinds de ontwikkeling van Claude Mythos Preview hebben we onze modellen gebruikt om te zoeken naar zwakheden in die sandboxes. We beschreven onze offline monitoring van interne coding-agents in onze update over alignment-risico's van april, en ons Risk Report van augustus behandelt dat systeem in meer detail, samen met de interventies die ernaast draaien. Deze omvatten sandboxing- of auto-mode classifiers op de meest autonome vormen van intern agent-gebruik, en geautomatiseerde review van infrastructuur-code wijzigingen voordat ze worden samengevoegd.

Wat dit werk miste, waren evaluaties—en in het bijzonder evaluaties door derde partijen. We monitorden sommige risicovolle evaluaties wel in realtime, maar over het algemeen voerden we alleen geautomatiseerde reviews uit op een steekproef van transcripten achteraf.

De juli-incidenten hebben aangetoond dat de urgentie om onze cybersecurity-verdediging te verbeteren nog hoger is dan we eerder geloofden. We verdubbelen onze inspanningen in deze richting en zullen hier meer over zeggen in ons volgende Risk Report.

***

Voetnoten

[1] We hebben geverifieerd dat de classifier de incidenten die in ons rapport van 30 juli worden beschreven, zou hebben gevlagd. [2] Geen van deze bevindingen kwam voort uit onze interne, toegewijde offensieve-cyber evaluatiesuites, die volledig zonder netwerktoegang draaien. [3] Risicovolle cyber-evaluaties omvatten die waarbij Claude een ambigu gedefinieerde, offensieve taak krijgt, zoals penetratietesten. [4] Uiteindelijk is een model dat buiten zijn bedoelde scope handelt bij zo'n uitdaging een alignment-probleem; een aligned model zou moeten stoppen of aan mensen rapporteren dat de taak niet kan worden voltooid zoals gespecificeerd. We blijven dit gedrag direct trainen, maar een defense-in-depth benadering betekent dat we niet alleen op alignment vertrouwen. [5] We hebben publiekelijk twee andere categorieën van reward hacking besproken in de Mythos Preview system card, waaronder één waarbij het model gebruikmaakt van computerprocesgegevens op laag niveau om zijn rechten te verhogen, en een andere waarbij het netwerkbeperkingen in zijn trainingsomgeving omzeilt om gegevens te downloaden waarmee het de toegewezen taak kan verkorten. [6] Deze mitigaties zijn niet geheel voldoende geweest; we bespreken verdere instanties van training op chain of thought in meer detail in ons Risk Report van augustus, sectie 5.2.3.