News

• Politico: Cypto Piles up in Senate 'Trainwreck'
• ABA Banking Journal: Washington state attorney general advises caution when donating to help wildfire victims
• ABA Banking Journal: The evolution of financial scams
• ABA Banking Journal: State attorneys general voice support for ‘know your customer’ communications requirements
• CISA News: Anthropic: Investigating three real-world incidents in our cybersecurity evaluations

SDBA Updates

• 2027 Scenes of South Dakota Calendars: PRE-ORDER TODAY!

SDBA Events

• 2026 Fraud Academy
• 2026 USD Banking Day
• 2026 GSB Financial Managers School
• 2026 SDBA Annual Security Seminar

Online Education

• Additional Educational Opportunities

Politico: Cypto Piles up in Senate 'Trainwreck'

With just hours remaining before the Senate’s scheduled August recess, the path forward for the Clarity Act is murkier than ever.

The sweeping cryptocurrency bill is caught in a multi-car pileup of legislative business that Senate GOP leaders hope to complete before leaving Washington until mid-September. Majority Leader John Thune (R-S.D.), who described the situation as a “trainwreck” on Wednesday, says he still wants to hold at least an initial vote on the bill. But with a bipartisan deal remaining elusive, growing GOP wariness about pivotal pieces of the legislation and a laundry list of other Republican priorities still on the table, it’s unclear whether the bill will get the floor vote that its crypto industry backers have spent months chasing.

The GOP supporters of the bill are eager to force a procedural vote on it — whether it succeeds or not — believing that Democrats will never sign on until the eleventh hour.

“I have no idea how it’s going to turn out, but it’s time to vote,” Sen. Cynthia Lummis (R-Wyo.) said Wednesday. She added that she is “sure” a vote is “going to happen.”

But a growing number of Republicans — many grappling with the 616-page bill for the first time — are expressing uncertainty about parts of the legislation that have drawn the ire of law enforcement groups and banks. That could be a problem for the bill as GOP leaders weigh whether it’s worth it to keep senators tethered to Washington into the weekend — or even next week — to take up the measure, which would create the first regulatory framework for digital assets.

GOP senators are getting bombarded with concerns from their local banks, which are historically one of the most powerful interests on Capitol Hill but have struggled to match up against the aggressive lobbying tactics of crypto firms that have dumped hundreds of millions of dollars into political spending in recent years. Banking groups are pushing for the bill to include stronger restrictions on rewards programs offered by crypto companies that lenders say could lead customers to pull deposits from traditional checking and savings accounts.

“The lobbying’s definitely having an impact,” said Sen. Kevin Cramer (R-N.D.), who sits on the Senate Banking Committee. He and other Republicans on the panel are ready to defy the banking industry on the bill, believing that a compromise crafted by Sens. Thom Tillis (R-N.C.) and Angela Alsobrooks (D-Md.) is enough to address banks’ concerns.

“If we’re waiting for a moment when the banks are going to say, ‘OK, now it’s good enough,’ that moment’s not happening,” Cramer said. “No is their default. Personally, I don’t give them a veto over my vote.”

But other Republicans are warier. Sen. Josh Hawley of Missouri revealed he plans to vote against the measure unless changes are made to address concerns raised by banking and agriculture groups in his state, which are worried about deposit flight threatening local lending. And moderates including Sens. Susan Collins of Maine and Lisa Murkowski of Alaska are also signaling caution about some aspects of the bill.

“I am reviewing it,” Collins, a moderate who faces a tough re-election campaign this fall, said in an interview. “My inclination, unless I see something that is alarming, is to vote to proceed. But I need more information on the impact on law enforcement — where there appears to be a split between the police and the sheriffs — and I’m also looking at the impact on small community banks.”

Asked about the bill on Wednesday, Murkowski immediately pointed to “a big push to include something in Clarity that would make clear” the Commodity Futures Trading Commission’s oversight of prediction markets doesn’t override tribal gaming authorities. Traditional gambling groups — including tribal interests — have sought to use the legislation as a vehicle to clamp down on prediction markets that they say are flouting state gaming laws.

“I don’t think that that’s something that is going to be possible, but it was raised, and I think it’s an important issue,” she said.

GOP concerns aside, the fate of the bill ultimately rests on whether Republicans can hammer out a bipartisan deal with Democrats to enact the measure. Three big issues remain outstanding: law enforcement concerns regarding illicit finance that Democrats want to address; changes they want to the commodities portion of the bill overseen by the Senate Agriculture panel; and, most importantly, an ethics provision that they want to see crack down on the Trump family’s crypto businesses.

The ethics provision is the thorniest issue of the bunch. Tillis, who drafted a bipartisan counteroffer last week after Democrats rejected ethics language the Trump administration signed off on, said Wednesday afternoon his office is in talks with the White House on the matter.

“The fact that they want to have a discussion is good,” Tillis said.

He, too, wants a vote before leaving. If lawmakers depart without taking it up, he warned, “you just run out of time.”

Full Article

Back to Top

ABA Banking Journal: Washington state attorney general advises caution when donating to help wildfire victims

The Washington Attorney General’s Office today issued guidelines for donating to reputable charities, as scammers will likely try to take advantage of individuals seeking to help families and businesses affected by the wildfires currently burning in parts of the state.

Three wildfires in Spokane County, Washington, have resulted in evacuation orders for at least 65,000 people and possibly damaged or destroyed as many as 1,100 structures, according to USA Today. Several charities are accepting donations to help those affected.

Scammers often take advantage of natural disasters by posing as charitable organizations raising funds for victims. The Washington Attorney General’s Office offered several tips for avoiding scams. For example, legitimate charities must first register with the Washington Secretary of State’s Office, which maintains an online database of registered nonprofits. The attorney general’s office also warned against “high-pressure asks” demanding immediate payment and scanning QR codes, as the codes could lead to fake or malicious websites.

The office also noted that several crowdfunding campaigns have been launched to help wildfire victims. It encouraged people to first research the crowdfunding organizers, and cautioned that donations to individuals are not regulated like donations to charities.

As for reputable charities, the office noted that the city of Spokane is accepting donations through its H.O.M.E. Starts Here Fund. The Washington Bankers Association has encouraged bankers to consider donations to organizations such as the American Red Cross and the Innovia Foundation. In addition, the Spokane news channel KHQ has compiled a list of charitable organizations accepting donations to help those affected.

Full Article

Back to Top

ABA Banking Journal: The evolution of financial scams

What a century of fraud can teach banks about the next generation of risk.

Scams do not disappear. They migrate. Criminals reuse the same human levers: trust, urgency, reward, fear and confusion, then pair them with the most efficient communication and payment tools of the day. For banks, the lesson is clear: Fraud risk management must anticipate how technology and social behavior change together, not merely respond after losses occur.

A familiar story in new clothing

A financial scam is more than a bad transaction. It is a relationship built on deception. The relationship may last minutes, as with an urgent text message or phone call, or it may develop over weeks or months, as with romance and investment schemes. In every case, the criminal’s objective is the same: Use trust, fear, reward or complacency to persuade the victim to act against his or her own interests.

That is why the history of scams matters. Fraud is often discussed as if each new method is a different problem requiring a different response. In reality, many modern scams are old confidence tricks delivered through faster, broader and more anonymous channels. The actors change, the technology changes and the payment rails change, but the underlying manipulation remains remarkably consistent.

For banks and fraud professionals, this history is more than a useful narrative. It is a control lesson. Each major shift in technology or culture creates new opportunities for criminals to scale deception. Each shift also gives financial institutions an opportunity to reassess client education, operational friction, payment controls, employee empowerment and cross-sector information sharing before losses become the proof that the risk was real.

From ownership dreams to confidence tricks

In the late 19th and early 20th centuries, one of America’s most famous con men, George C. Parker, reportedly convinced victims that he owned landmarks such as the Brooklyn Bridge. The story endures because it captures the basic mechanics of the confidence game. Parker did not need complex technology. He used charm, forged documents, false offices and a believable narrative. His victims were not simply buying a bridge. They were buying opportunity, status and trust in a country where ownership represented security and success.

Parker’s alleged bridge sales are often treated as colorful history, but they illustrate a modern fraud principle: Criminals exploit the aspirations and pressures of the society around them. In a paper-based world, fabricated ownership documents and face-to-face persuasion were enough. In a digitized world, the same idea can be recreated through fake websites, forged digital documents, paid advertisements, spoofed communications and synthetic identities. The scammer no longer has to stand in front of the victim. Technology creates distance, scale and deniability.

The investment promise: from Ponzi to Madoff

The 1920s gave the financial world the name that still defines a category of investment fraud: Charles Ponzi. Ponzi claimed he could profit from arbitrage involving international reply coupons. The premise sounded technical enough to be credible and profitable enough to be irresistible. The core reality was simpler: Earlier investors were paid with money from newer investors, creating the illusion of a successful enterprise until withdrawals and scrutiny exposed the scheme.

Ponzi schemes remain powerful because they convert hope into proof. Early payments, fabricated statements, testimonials and the appearance of exclusivity can make fraud feel legitimate. Decades later, Bernard Madoff showed how the same architecture could operate in a far more sophisticated financial environment. Madoff’s investment advisory business collapsed in 2008 and is widely described by law enforcement as history’s largest known Ponzi scheme. The scale was different, but the psychology was familiar: Trust a respected figure, believe in steady returns and ignore warning signs because the relationship appears credible.

The banking lesson is that investment scams are rarely defeated by disclosure alone. Victims often believe they are acting rationally based on evidence the criminal has manufactured. Controls and education must therefore focus on behavioral red flags: secrecy, guaranteed returns, pressure to add funds, difficulty withdrawing, changing explanations and requests for additional fees to access supposed gains.

The telephone era: pressure at scale

The mass adoption of the telephone changed the economics of persuasion. Scammers could reach victims without travel, repeat scripts quickly and use urgency to keep targets from seeking outside advice. Boiler room operations became a defining example. These were high-pressure sales environments where callers pushed speculative, worthless or manipulated securities, frequently relying on cold calls, misleading claims and pressure to act immediately.

Modern enforcement cases show how durable that model remains. The Securities and Exchange Commission has charged boiler room-style operations that allegedly used cold calls and high-pressure tactics to target investors, including seniors, with misrepresentations about penny stocks and other securities. The technology has changed from rotary phones to virtual call centers, email campaigns and social media messages, but the central tactic is unchanged: Isolate the target, accelerate the decision and make delay feel costly.

Charity scams followed a similar path. Disasters, wars and public tragedies create genuine empathy, and criminals exploit the moment. A caller, email, crowdfunding post or social message may appear to represent a legitimate relief effort and may request payment by cash, gift card, wire or cryptocurrency. The emotional trigger is immediate: Help now. For banks, this is a reminder that scam detection must consider context, not just payment type or authentication status.

Checks, cards and the first digital cracks

The mid-century and late-century evolution of payments created new fraud opportunities. Check fraud expanded through forgery, counterfeit checks, check kiting, stolen mail and check washing, where legitimate checks are altered and rewritten. Frank Abagnale Jr. became one of the best-known public figures associated with check fraud, even as some details of his broader story have been disputed. The enduring lesson is not the celebrity of the case, but the vulnerability of negotiable instruments when trust, paper and processing gaps intersect.

Credit card growth created another opening. As cards became more common, criminals adapted through counterfeit cards, stolen cards, altered cards, application fraud and merchant or insider schemes. Issuers and networks responded with stronger physical security features, improved authorization controls, fraud monitoring and eventually chip technology. This cycle, attack followed by adaptation, is a recurring theme in fraud history.

The early digital era also gave new life to advance-fee fraud. The classic promise was simple: pay money now to receive more money later. Fax machines and early email gave these messages reach. The so-called Nigerian prince email became the public shorthand, but the broader model remains visible in relationship investment scams, fake grant offers, inheritance scams and recovery scams that ask victims to pay additional fees to retrieve funds they have already lost.

The internet era: Identity becomes the target

The 2000s accelerated the shift from physical fraud to digital impersonation. Phishing emails created the appearance of trusted institutions and asked consumers to provide credentials, account information, Social Security numbers or payment card data. The criminal did not need to break into a system if a consumer could be persuaded to hand over the keys.

Online auction and marketplace fraud also grew with e-commerce. Non-delivery schemes asked buyers to pay for goods that never arrived. Non-payment schemes exploited sellers. Fake listings, spoofed escrow services and manipulated reviews showed how trust mechanisms built for legitimate commerce could be turned into fraud infrastructure.

Identity theft became a central concern because data had become both portable and reusable. A name, address, Social Security number, date of birth, credential set or card number could be used to open accounts, take over existing accounts, file false claims, commit tax fraud or support a broader synthetic identity. For financial institutions, the key shift was from verifying a document or a person at a single point in time to evaluating whether the full pattern of behavior remains consistent over time.

Mobile, social media and the rise of engineered trust

The 2010s brought mobile banking, social media, peer-to-peer payments and always-on digital communication. These tools improved convenience, but they also gave criminals new ways to enter victims’ lives. Social engineering became central because attackers could study targets, impersonate trusted brands or authorities and communicate through channels that felt personal.

Tech-support scams are a clear example. The victim is told there is a problem with a device, account, virus protection or purchase. The scammer offers help, then requests payment, credentials or remote access. The victim may believe they are resolving a security issue when they are actually creating one.

Cryptocurrency and online investment schemes added another layer. Criminals could build relationships through text messages, social platforms or dating apps, then introduce an investment opportunity involving crypto assets, AI trading tools or proprietary platforms. Some victims were allowed to make small withdrawals early, reinforcing belief in the investment. Later, the account was frozen or withdrawals were blocked unless the victim paid taxes, fees or recovery charges. This long-form manipulation is often described as pig butchering because the victim is groomed over time before the financial loss occurs.

The 2020s: AI, deepfakes and industrialized deception

The current era is not defined by entirely new fraud types. It is defined by speed, scale and believability. Generative AI can help criminals write cleaner phishing messages, create more convincing scripts, generate fake images or documents, clone voices, develop synthetic profiles and adapt messages to the victim’s responses. Deepfake audio or video can make impersonation more credible, especially where the target believes they are interacting with an executive, a family member, a vendor or a trusted financial contact.

Synthetic identity fraud illustrates the same direction of travel. Criminals can combine real and fabricated information to create identities that pass some checks but do not correspond to a real person in the way the institution expects. The risk is not only that false identities are created, but that they can be nurtured, aged and used across systems in ways that make them appear normal.

Real-time and faster payments add urgency to the control challenge. When money moves immediately, the time available to detect, investigate, recall or recover funds shrinks. In that environment, a completed authentication event does not necessarily mean the customer understood the true purpose of the transaction. Fraud strategy must therefore distinguish between verifying identity, confirming intent and detecting manipulation.

What banks should take from the history

The common thread across every era is that fraud exploits the gap between trust and verification. Parker used forged paper. Ponzi used a technical investment story. Boiler rooms used pressure. Phishing used brand impersonation. Social engineering uses emotion. AI now helps criminals make all of those tactics faster and more convincing.

This history points to several practical conclusions for financial institutions. First, new technology should be treated as a fraud risk event, not merely an innovation event. Second, fraud controls should be reviewed when customer behavior changes, payment speed changes or communication channels change. Third, fraud operations should be designed to create a pause when speed is the criminal’s advantage. Fourth, frontline employees need clear authority to escalate, slow or question suspicious activity when the human context suggests manipulation. Finally, banks cannot solve scam origination alone. Many scams begin outside the bank, including on telecommunications networks, social media platforms, online marketplaces and messaging services. Effective mitigation requires information sharing and shared accountability across the ecosystem.

Conclusion: Prevention requires memory and anticipation

The evolution of financial scams shows that criminals are early adopters of both technology and human opportunity. They do not abandon old methods. They update them. A door-to-door fraud becomes a fake website. A boiler room becomes a distributed call center. A forged document becomes a synthetic identity. A confidence game becomes a deepfake-enabled payment request.

Fraud risk management must therefore combine institutional memory with forward-looking risk assessment. Waiting for losses to prove that a control is necessary creates its own risk, particularly when payments move quickly and scams originate outside bank-controlled channels. The better approach is to ask, with every major change in technology, culture or payment behavior: how will criminals use this to create trust, pressure the victim and move money before anyone can intervene?

Banks are strongest when they treat fraud prevention as both a technology discipline and a human discipline. Systems can identify anomalies, but people identify context. Controls can slow a transaction, but trained employees can recognize coercion. Education can prepare customers, but timely intervention can interrupt a scam in the moment. The future of fraud prevention will depend on bringing those capabilities together before the next generation of scams becomes the next generation of losses.

At-a-glance timeline: How scam delivery has evolved

Full Article

Back to Top

ABA Banking Journal: State attorneys general voice support for ‘know your customer’ communications requirements

In a joint letter, 50 state and territorial attorneys general said they support a Federal Communications Commission proposal to bolster “know your customer” obligations for voice service providers that originate calls, arguing that stronger requirements will help fight fraud and scams.

The FCC has proposed strengthening KYC rules to require originating providers to collect a robust set of information from business callers before allowing those callers access to a provider’s network. The American Bankers Association is among the groups that support the proposal, sharing data showing some providers fail to adequately investigate the companies using their networks, which facilitates fraud.

The attorneys general said that the FCC should ensure that originating providers conduct business only with entities that they know are legitimate and are engaged in legitimate business practices.

“As principal gatekeepers to the U.S. communications network, originating providers are best positioned to scrutinize those who seek entry to the network primarily to profit from harm caused to the network and our constituent consumers,” they said. “The U.S. communications network should be a place for efficiency, but not for shortcuts.”

The attorneys general also urged the FCC to require providers to understand their customers’ business practices and reputations, to hold providers of all sizes to KYC standards, and to mandate that providers collect additional information on high-risk customers.

Full Article

Back to Top

CISA News: Anthropic: Investigating three real-world incidents in our cybersecurity evaluations

In a review of our cybersecurity evaluation transcripts, we found three incidents in which a Claude model reached the internet from within or while interacting with a third-party evaluation environment, and then gained unauthorized access to the real systems of three different organizations.

Below we describe what happened, how it happened, and what we’re changing. We encourage other AI labs to perform similar reviews. This post reflects our current understanding; we'll update it if any details change. 

On July 21, OpenAI disclosed that several of their models had broken out of an isolated test environment by exploiting a previously unknown (“zero-day”) vulnerability. The models went on to access the production infrastructure of Hugging Face, a platform for open-source machine learning models and AI datasets.

In response to this incident, we began a large-scale retrospective review of our own cybersecurity evaluations. In particular, we looked for evidence that Claude—like the OpenAI models that accessed Hugging Face—was able to access the internet from within testing environments that should have been sealed off.

After reviewing 141,006 evaluation runs where Claude could have obtained internet access, we identified three incidents in which a model accessed the internet from within or while interacting with the evaluation environment of Irregular, one of our third-party evaluation partners, and then gained unauthorized access to the production infrastructure of three different organizations.

In all three incidents, Claude had been tasked with a capture-the-flag challenge, one of the ways we assess a model’s cyber capabilities. The model is given a fictional scenario and told that a piece of secret information (the “flag”) has been hidden on a different machine on the network, and its objective is to break in and retrieve it. The challenge is left open-ended, and no particular method is prescribed.

In all cases, Anthropic’s evaluation prompt specified to Claude that its environment was a simulation and that it had no internet access. Due to a misunderstanding between us and our evaluation partner, this was not the case, and internet access was available. Because of this, when Claude’s search led it to real systems on the open internet, it treated them as part of the exercise. (Cybersecurity evaluation ranges commonly include realistic details in order to accurately assess what models are capable of in real settings; a realistic-looking target would not itself be clear evidence to a model that the target is not part of a simulation.)

Operating under the false belief that all accessible entities were intended to be in-scope for the exercise, Claude compromised the impacted organizations’ infrastructure using basic techniques, such as exploiting weak passwords and unauthenticated endpoints. It did not find or exploit any complex vulnerabilities, and in each case, Claude continued working to complete only the specific capture-the-flag task its evaluation had assigned. However, in some cases, our older model continued its attack even after getting evidence it was running on the open internet; our latest model stopped once it recognized it was on the internet. In none of these situations did Claude exfiltrate itself or deliberately attempt to escape its test environment.

The incidents involved three different Claude models: Opus 4.7, Mythos 5, and an internal research test model.¹ The earliest incidents date to April. The models in each of these evaluations ran without the standard safeguards we deploy when we make the model generally available (that is, they did not have the classifiers and monitoring we usually implement to prevent misuse). The models did, however, have their model-specific safety training (that is, they were not the “helpful-only” versions of the models that we sometimes use in testing). All the evaluations described here run on dedicated infrastructure, which is separate from and has no access to Anthropic’s sensitive internal systems or customer data.

We began our transcript review on Thursday, July 23, and stopped all cyber evaluations the same day after identifying transcripts where Claude may have accessed the internet. We identified all three incidents the next day. We notified our evaluation partner Irregular and the three affected organizations on Monday, July 27. The two organizations we were able to reach had not previously detected the activity or contacted us, and we are now working with them to remediate. We are continuing to reach out to the third.

We conducted this review in collaboration with Irregular. We’re grateful to them for working closely with us to understand and resolve these incidents; they are also conducting their own investigation. We believe this type of collaboration is increasingly critical to ensuring safe, rigorous evaluation of models. We look forward to our joint work on security.

In what follows, we provide more details on each incident and how we’re responding moving forward.

Background on cyber evaluations

We regularly run cybersecurity evaluations that involve simulating real offensive cybersecurity challenges. These evaluations are a critical step in developing and releasing models—a nuanced understanding of model capabilities allows us to design appropriate safeguards and ultimately release models safely.

We began running cybersecurity evaluations in February 2025 with Claude Sonnet 3.7 on Cybench, which consisted of 40 different capture-the-flag challenges. Over time, we’ve increased the number of benchmarks we use as new ones are released and model capabilities evolve. In the Mythos 5 System Card, for example, we included CyberGym and ExploitBench, benchmarks that evaluate the ability of language models to find novel vulnerabilities.² In most of these evaluations, the environments are not connected to the internet, and the model is told as much.

We frequently work with external partners who create and assist in running some of these cybersecurity evaluations. External partners offer environments and scenarios more diverse than we could build alone, and provide independent, third-party assessments of our models.

What happened

Of the 141,006 evaluation runs we reviewed, we identified three separate incidents (involving six total runs, four of which impacted the same organization; the other two incidents each happened in independent evaluation runs). Each incident involved a different fictional capture-the-flag scenario—for example, in one, Claude played an employee of a made-up company, attacking that company’s internal systems inside a private test environment.

In all cases, our evaluation prompt stated explicitly that Claude had no internet access, but didn’t give Claude any limits on where to look for the flag. However, a misconfiguration left the machines that Claude accessed as part of the evaluation with live internet access. Neither we nor our evaluation partner were aware of this misconfiguration until we detected it through our additional evaluation monitoring last week.

Several defense-in-depth measures, on both our side and our partner’s, could have prevented these incidents, or at least reduced their likelihood of occurring. Careful validation of all internet access paths before evaluations began and real-time monitoring of the evaluation logs would have helped to surface the problem sooner. Both we and our partner also could have reviewed evaluation transcripts or network logs more thoroughly. It’s also possible that a prompt which told Claude it did have internet access would have changed how Claude behaved when it came into contact with real systems.

Claude did what capture-the-flag exercises train cyber experts to do: look for ways to reach the flag. That search led it to discover that its machine could reach the internet, but having been told in the system prompt that there was no internet access, Claude believed everything it initially encountered was part of the simulation, and treated the real systems it found as pieces of the exercise. The three incidents involved three different models, and each responded differently once signs emerged that the targets were real, as we describe below.

Incident 1

In one evaluation, the fictional target company chosen by our evaluation partner shared a name with an active website domain name. This evaluation container had unintended direct internet access, due to the misunderstanding discussed above.

In four runs of this evaluation, Claude ran into difficulty reaching its simulated target within the evaluation environment, but then discovered that the real company was reachable via the internet. Assuming this was the intended target in the capture-the-flag task, Claude sought, identified, and exploited vulnerabilities within the company’s infrastructure, believing it to be part of the exercise. These four runs extracted information like application and infrastructure credentials, and obtained access to a database containing several hundred rows of production data. This represented the most serious impact we identified.

This incident involved Claude Opus 4.7, and was the only case in which the model continued to attack a system after learning it was likely operating in a real environment. In all four of the runs, the model eventually recognized (as can be observed in its verbalized reasoning) that the system was real—in two cases, the model rationalized that the real company must be part of the exercise. However, none stopped the attack on that basis.

Incident 2

In another evaluation, Claude found a document inside the fictional environment that appeared to be another made-up company’s setup instructions for new developers. Those instructions told employees to install a Python package from PyPI—the public registry where Python software is published—that did not actually exist.

Claude spotted this as a potential opening: if it published its own package under the same name, the fictional company’s systems would download and install it automatically. So, Claude built and published a malicious (essentially booby-trapped) Python package with the same name in an attempt to win the capture-the-flag challenge.

Claude went to extensive lengths to carry out this attack—lengths that would likely have indicated to a human participant that this was no longer just an evaluation, and that they were in fact uploading a real PyPI package. For instance, in one case, in order to create a PyPI account, Claude needed an email address. And in order to create an email address, it needed a phone number. To get a phone number, after failing to find a free phone number service, it tried—and failed—to obtain funds to pay for a phone number through several different means. It finally backtracked, found a free, non-blocked email provider, used this to register a PyPI account, and then used this account to upload malware to PyPI.

Claude believed the package registry it was using to be part of the simulation, but in reality the package was made freely available online for roughly one hour. During that window, the package was downloaded and run on 15 real systems. One of these systems was a scanner belonging to a real security company (separate from the fictional company introduced in the scenario) that routinely installs Python packages and scans them for malware. When that company’s scanner installed the package, Claude’s hidden code executed. We believe the company’s security scanner treated PyPI packages as safe to install, and as a result, Claude was able to exfiltrate the company’s credentials to a collection point it had set up. Claude then used these credentials to access further infrastructure from this company.

Claude didn’t directly target this company—it did not even know the company existed when it uploaded the package. But because the code was published to the open internet, it impacted any system that ran it. (The package that Claude uploaded was automatically removed from PyPI by PyPI’s own security systems. We’ve notified the PyPI team of this incident, and provided them with the relevant indicators.)

This attack was carried out by Claude Mythos 5. Early in the run, Claude’s own reasoning correctly identified the consequences of its actions. It noted that if this were the real internet, publishing the package would be a real-world attack—“NOT okay, and surely not the intended solution.” However, it convinced itself it was still in a simulation on the grounds that it didn’t recognize the (in reality genuine) certificate authorities securing its connections. In addition, the calendar date of 2026 on the systems proved, according to Claude, that the environment was staged. Claude never revisited this conclusion; when automated scanners began installing the package, for example, Claude took them to be scripted actors within the evaluation.

It is our view that, regardless of what it believed about its environment, the lengths Claude went to in order to publish the PyPI package fall short of ideal behavior, and this is an area where we will focus more training.

Incident 3

In this evaluation, when Claude was unable to reach its intended fictional target, it looked for alternatives online, scanning roughly 9,000 targets. It eventually found and compromised one company’s internet-facing application, using basic and well-known cyberattack techniques like reading credentials from an exposed debug page and SQL injection.

This attack was carried out by an internal research test model. For most of the run, Claude treated the (real) hosts it reached as just parts of the exercise; it assumed them to be simulated and believed its actions were therefore harmless. However, later in the run, Claude realized that the compromised host sat in a cloud account with no connection to the capture-the-flag challenge. On its own, it concluded that the target was in fact real, and ceased its attack.

Our analysis of Claude’s behavior

In each of these cases, Claude was explicitly told by our prompt that it had no internet access. Through most of each run, as it encountered real-world systems, Claude assumed these to be parts of the exercise (though it sometimes recognized they were real production systems). And because a capture-the-flag scenario is by design an instruction to attack an external system, doing so was in line with the task Claude had been given.

Against this shared backdrop, the three models behaved differently once signs emerged that their targets were real. Opus 4.7, our oldest model, recognized that it had reached production systems but continued its attack. Mythos 5 correctly intuited that it was accessing the open internet, but reasoned its way back to the conclusion that it was still in a simulation. Our latest model, an internal research test model, also considered whether its targets were in fact real. When evidence emerged that they were, it stopped the exercise.

These are three isolated incidents and were not part of a controlled, experimental comparison. We must therefore be cautious about drawing conclusions from them. Still, the behavior we most want to see—recognizing that a target is real and stopping without being prompted—occurred only in the most recent of the three models (and even that model went further before stopping than we would want). The pattern is consistent with more advanced models responding more appropriately, but we would need to perform more testing to be confident in this conclusion.

We are also in dialogue with METR, an independent AI evaluation organization, to conduct a third-party review, including access to all transcripts and sampling access to the relevant models. In the meantime, within the next week, we will release a lightly redacted transcript in which Claude built a malicious PyPI package. To protect the organizations affected, we are unable to release more transcripts at this time, but will work to make these available once we are able.

How we’re responding

We draw several lessons from these incidents.

First, evaluation environments that involve powerful autonomous capabilities also require significant controls. Safety testing happens before a model is released precisely because we don’t yet know what it is capable of. Evaluation environments increasingly need to be held to the same security standard as any other system our models run in.

A cyber evaluation range that contains only fictional scenarios may appear to be low-risk—after all, nothing inside them is real. However, we need to change how we model such threats as AI capabilities advance. Advanced agents in environments without access to sensitive information nevertheless present a substantial threat on their own. We need to better co-design evaluation environments, and do better monitoring of evaluation results, to meet this threat. Some of the solutions here may even be simple fixes; it’s likely, for instance, that Claude wouldn’t have accessed the internet to begin with if the prompt had clearly explained which systems were in and out of scope for the evaluation.

This applies not only to internal environments but to third-party vendors as well—the infrastructure built by evaluation vendors requires the same increased monitoring and hardening. We encourage other labs to perform similar reviews. Additionally, the field would benefit from a broader conversation about how to evaluate increasingly powerful AI agents both safely and realistically, including how to weigh the realism provided by internet access during pre-deployment testing against the risks it introduces.

Second, the line between an aligned action and a harmful one is dependent on the model’s understanding of its situation. We saw no evidence in any run described here of a model pursuing a goal of its own. Instead, the models did what their evaluation asked—though in most cases, they did so while holding a false belief about whether the environment was real. In the runs where the model recognized the system as real and kept going, it did so because it assumed that to be part of the challenge. Situational awareness is one factor that allows the model to make aligned decisions, but in this case, Claude’s was wrong.

Finally, these incidents demonstrate the importance of defense-in-depth approaches. We run capability evaluations like these without safeguards that ship with our generally available models because our goal is to measure what the underlying model can do. That is safe only if the evaluation is appropriately contained. However, the safeguards deployed on our generally available models would have blocked the behaviors identified.

Ultimately, many factors contributed to these incidents, but, consistent with a blameless postmortem culture, we’re approaching the fixes as if the responsibility were ours alone. This begins with ensuring every part of our evaluation pipeline is secure, including the manner in which we integrate with external partners. Moving forward, it will include expanding our continuous monitoring of evaluation transcripts for unexpected behavior, improving our investigation tooling, and conducting more rigorous assurance work with the vendors we rely on.

We began this review after OpenAI disclosed that its models had escaped an isolated test environment, and we commend them for publishing their report. While we also found evidence of our models reaching systems they weren’t supposed to reach, the incidents are otherwise quite different:

• We discovered these incidents after a proactive review of our cybersecurity evaluation transcripts; the affected organizations had not detected the activity, and we have subsequently reached out to all three.
• Whereas OpenAI’s models exploited a novel vulnerability to escape isolation, the Claude models evaluated here accessed the internet via an open path.
• While there is not a perfectly sharp distinction between the two, we believe these incidents to be closer to a harness and operational failure than a model alignment failure. Our models were told they had no internet access and to capture the flag, while in fact being misconfigured to have internet access. This led them to believe—arguably reasonably—that the real environments they encountered were simulations.
• Notably, our most recent model, on realizing that it was working in a real environment, stopped its pursuit of the evaluation goal.

These facts give us cautious optimism that with tighter monitoring and controls around evaluation infrastructure, as well as continued investment in alignment, this type of risk can be overcome. 

Updated Aug 3: Corrected the name of the evaluation in which the OpenAI/Hugging Face incident occurred.

Full Article

Back to Top

2027 Scenes of South Dakota Calendars: PRE-ORDER TODAY!

Each year, the SDBA offers the Scenes of South Dakota Calendar. This calendar features photos of South Dakota submitted by South Dakota bankers, their family members, and customers.

Scenes of South Dakota calendars are a great opportunity to thank your customers for their business and promote your bank or business. Your bank, branch, or business logo and name can be printed on each calendar to display in homes and businesses year round.

Place your order for the 2027 Calendar - EARLY BIRD RATE AVAILABLE THROUGH SEPTEMBER 1

Online Education

Participating in learning opportunities outside the bank can be challenging. Take advantage of the SDBA's extensive selection of webinars and on-demand training to enhance your banking expertise directly from your computer.

GSB Online Seminars
OnCourse Learning
SBS Institute
ABA Training

Learn how to put compliance management solutions from Compliance Alliance to work for your bank, by contacting (888) 353-3933 or [email protected] and ask for our Membership Team. For timely compliance updates, subscribe to Bankers Alliance’s email newsletters. 

Back to Top

---

SDBA eNews Archive

View past issues of the SDBA eNews

Advertising Opportunity
Learn more about sponsoring the SDBA eNews

Questions/Comments
Contact the SDBA at 605.224.1653 or via email