The IT Nerd

Bank of America hired 1,000 outside contractors to help remediate software vulnerabilities identified by advanced AI models, including Anthropic’s Mythos, according to CNBC.

CEO Brian Moynihan said the contractors were brought in during the second quarter and continue working alongside approximately 3,000 existing employees.

The bank accelerated remediation of vulnerabilities in its internal software and third-party vendor code as AI models became more capable of discovering security weaknesses. Moynihan said software remediation and anti-money-laundering compliance efforts together added more than $200 million in third-quarter expenses.

The bank did not disclose how many vulnerabilities were identified or patched.

John Strand, Owner, Black Hills Information Security:

“What do you call a thousand outside contractors helping Bank of America remediate software vulnerabilities? A good start.

“That’s an infosec joke, but it also shows one way AI may actually contribute to job growth in computer security. Finding more vulnerabilities creates more work for the people who have to fix them.

“My bigger concern is the idea that finding and remediating vulnerabilities is going to be an Easter egg hunt. Find all the eggs, put them in the basket, and you’re done. Software doesn’t work that way. It’s constantly evolving, changing, and getting patched. New vulnerabilities and attack paths keep emerging. We’re not going to find everything, fix everything, and then have everything be fine. This is ongoing work.”

ㅤ

Jacob Krell, Senior Director: Secure AI Solutions & Cybersecurity, Suzu Labs:

“Bank of America’s 1,000 remediation contractors confirm what I have argued for a while now, the chokepoint has moved from finding vulnerabilities to fixing them. AI models like Anthropic’s Mythos can surface weaknesses faster than any bank can patch, so remediation capacity becomes the scarce resource, and Moynihan’s $200 million in added quarterly expenses puts a price tag on how scarce.

“Hiring that capacity this way creates its own exposure. A bank’s vulnerability inventory is effectively a targeting package, it maps exactly where the defenses are weak across internal software and third-party vendor code. Handing it to 1,000 outside contractors, roughly one contractor for every three existing security employees, distributes the bank’s most sensitive operational intelligence to people sitting outside its HR controls, monitoring, and enforcement chain. The bank can say the contractors follow the same security practices as employees, but without employee-grade endpoint logging and access oversight, the claim is unverifiable.

“I would want to know how long these contractors stay, what offboarding looks like, and who audits their access to live vulnerability data. The remediation backlog will shrink. Third-party risk like this outlasts every patch those 1,000 contractors ship.”

If AI created all this work, that’s not a good thing as all these bugs were out there. The real question is if the bad guys are using AI and for what for. Chances are that it was not anything good.

President Donald Trump and executives from OpenAI, Anthropic, Google, Meta, Nvidia and xAI signed a voluntary AI safety accord calling on companies to implement multiple layers of controls and oversight as increasingly capable AI systems raise cybersecurity and other safety concerns.

The agreement calls for companies to monitor AI models during training and deployment for dangerous capabilities, including whether models could hack or access technical systems in unintended ways, assist with biological, chemical or nuclear threats, or evade human control. Companies also agreed to maintain internal teams responsible for verifying that safeguards and monitoring systems are working as intended.

The accord calls for independent external evaluations, board-level oversight and sharing relevant safety information among participating companies and with the federal government. Trump described the agreement as “morally binding,” rather than a regulatory requirement.

Denis Calderone, CTO, Suzu Labs:

“1. The whole document rests on the word independent

“Layer three asks every signatory to partner with an independent external auditor or evaluator, and we already have a case study. METR and Redwood Research investigated the Hugging Face incident and documented their own limitations plainly. OpenAI defined the investigation window, so agent behavior before and after it fell out of scope. They could not query the model behind most of the activity. They had no direct access to OpenAI infrastructure and had to request datasets. OpenAI could redact the findings. With six days on site and roughly 1,300 transcripts to get through, they delegated much of the analysis to GPT-5.6 Sol, one of the models implicated in the incident, and wrote that they could not rule out being misled by it. That is a serious team doing careful work on terms set by the company being examined. The accord never says who accredits these evaluators, what methodology applies, or where the scope boundary sits.

“2. I expect this to produce press releases, not audits

“So they get to hire an evaluator of their own choosing, and ninety days from now we start reading about how rigorous their safety reviews turned out to be. I worry that these reports will be used more for as marketing tools rather than true assurance. If a client handed me this as their AI governance program I would write it up as a policy with no evidence of operation.

“3. The timing on this is ironic

“On September 14 the president called AI destroying humanity a “HOAX” and said a “SICK conspiracy” was running against AI and data centers. Fifteen days later he signed a document he called “morally binding” and “almost like a constitution.” That’s some pretty strong rhetoric to be followed by this accord. Maybe the administration doesn’t see AI as destroying humanity, but it apparently is a concern.

“4. The industry has been disclosing, information already, but it’s been pretty selective.

“These companies are very willing to tell you how powerful and dangerous their models are. We get essays and staged releases explaining that a model is too capable to hand over freely because of what it might do in the wrong hands, but when the damage lands on somebody else’s network it goes quiet. Emails viewed by the New York Times show two OpenAI employees warned executives months in advance that the newest models were not being properly monitored during testing, and the employees say they were told the tests had to keep moving to hit release dates. Hugging Face published its own breach disclosure on July 16 and OpenAI only recognized its agents as the source afterward. It is always the independent researcher or the company that got hacked making the disclosure when it makes the company look bad. Will this accord remove those market forces that caused earlier poor decision-making? I wouldn’t bet on it.

“5. There is nothing in here for the people actually deploying the technology

“All four layers sit inside the lab, and leaving the deployment side out will only make deployment standards worse rather than better. Read it as a CISO and the message is that responsibility for model behavior belongs to the developer. That is a comfortable place for a board to land when somebody asks who owns the risk of the agent your team just wired into production with an API key and a service account. This accord says nothing about the needed shared responsibility model or provides guidance to proper secure harnessing and guard railing of agentic deployments or disclosure path when a model does something unintended in a customer environment.”

ㅤ

Ryan McCurdy, VP of Marketing, Liquibase:

“The agreement gets one thing right: we can’t expect increasingly capable AI systems to govern themselves.

“Monitoring models and testing safeguards are important but enterprises also need controls around what AI can actually do once it has access to real systems. An agent may need permission to access a repository, database, or deployment system to do useful work. That doesn’t mean it should have the authority to take every action available to it.

“The controls need to sit outside the agent and close to the systems where its decisions become real actions. Policy can handle known, repeatable decisions while people step in for exceptions that genuinely require judgment.

“AI is going to make mistakes. The goal isn’t to prevent every bad decision inside the model. It’s to make sure one bad decision doesn’t automatically become a production problem.”

This doesn’t go far enough because it relies on the companies policing themselves. That will always be an #fail. What is actually needed is real enforcement and real consequences highlighted by the fact that OpenAI for example has a bad thing happen to them every week or more.

Major technology and defense companies including Palantir, Nvidia and Booz Allen Hamilton are restricting or considering ending their use of advanced AI modelsunless providers including Anthropic and OpenAI offer stronger guarantees that sensitive corporate data and intellectual property will not be retained or misused.

Palantir has pressed Anthropic for irrevocable zero-data-retention guarantees before offering its latest model through Palantir’s software. Nvidia is limiting Anthropic’s models to less-sensitive work and using its own Nemotron models for proprietary projects, while Booz Allen has barred employees from using Anthropic’s commercial model for cybersecurity work involving proprietary software.

In June, Anthropic changed its data policy to retain usage logs for 30 days to help detect complex attacks spanning multiple sessions. Anthropic and OpenAI both say they do not train their models on customer data by default unless customers opt in.

John Strand, Owner, Black Hills Information Security, Inc.:

“This is kind of insane, and it reminds me a lot of what happened with cloud computing years ago. When companies started moving to Microsoft and Google cloud services, there was an outcry. People were saying, ‘Our data isn’t on our servers anymore. It’s on Google’s servers.’ Eventually, that died down. People got used to the reality that their data was going to be stored in the cloud.

“I think AI is having a very similar moment. People are looking at Anthropic and OpenAI and getting upset about 30-day log retention policies. You can scream and thrash about that all you want, but the reality is that logging is a fundamental part of security and data governance. We keep transactional database logs. We keep email and activity logs in systems like Microsoft Purview. Organizations have requirements to maintain these records for security, auditing, governance, and accountability.

“When I look at Anthropic’s response in particular, it feels like they’re trying very hard to make sure these transactional logs exist for security and accountability. 

“And if your data is so sensitive that even that level of retention is unacceptable, there is another option. Run open-weight models locally on infrastructure you control. That’s exactly what we do for particularly sensitive activities.

“Logging and analysis have always been critical parts of security. AI doesn’t suddenly change that.”

Steven Swift, Managing Director, Suzu Labs:

“Organizations who prefer the old zero retention guarantees are likely to get stuck using older models. Anthropic and other labs have very publicly been fighting against wide scale misuse of their products. In order to meaningfully find and fix novel abuse techniques, it is essential that Anthropic maintain logs for a period of time. Its basically not possible to build adequate safeguards without such logs.

“I would expect that as time goes on, that all newer models carry with them the same standard data retention requirement. As time goes on, organizations will slowly get used to the 30 day retention window. It seems likely we’ll see the 30 day retention expanded to include older models as well. Especially where some of the older models clearly don’t have the same sorts of safeguards in place, making abuse on these older models more prevalent.

“There isn’t much upside for any of the frontier labs to offer true zero retention usage of their services. They already offer a guarantee that the data retained during the 30 day window won’t be used for model training.”

Donald McFarlane, Board Member, Xcape Inc.:

“We need to stop treating digital information as something people or businesses surrender simply because they place it in someone else’s custody. We should treat that relationship for what it is: a digital bailment.

“Possession is not ownership. When I entrust proprietary code, business records, personal information, or other unpublished material to a cloud or AI provider, that must be deemed to create duties much like a traditional bailment: use it for the agreed purpose, protect it, and do not retain, repurpose, sell, or disclose it beyond that purpose.

“AI makes this especially important because aggregation magnifies the risk. Thousands of individually mundane interactions can collectively reveal extraordinarily sensitive information about a person or company.

“Moving our papers from a desk drawer or filing cabinet into the cloud, including into the memory and logs of an AI model harness, should not strip away our property rights or make it easier for government to obtain them without proper legal process.”

Claudionor Coelho, Senior Advisor, Ridge Security:

“There is a discussion on whether OpenAI used data or meta-data to accelerate and anticipate the proof of Navier Stokes equations.

“In addition to that, Anthropic announced recently it is opening several verticals (like biotech, finance, etc). That raises the questions on whether any company’s data or meta-data are being used by the foundation labs, if not to train their models, at least using meta-data to help make decisions on which verticals to enter.”

I have been saying for a while that AI doesn’t have safety and guardrails and corporations are deploying AI without safety and guardrails in place. Maybe this will change things. One can hope.

The UK’s AI Security Institute has revealed that an AI agent went rogue after being given too much freedom. It may have happened in a test:

On 28^th July 2026, AISI’s Security Team detected unusual data transfers leaving our research systems during a routine cyber evaluation. On investigation, we found that some of the agents being tested had engaged in sustained, potentially harmful activity directed at real people and organisations. We declared a security incident and, within roughly one hour of discovery, had contained it and begun a full investigation.

The incident stemmed from a single evaluation where agents were given a task of solving a cyber security challenge. We ran this challenge 122 times across several models. Our investigation found that in 10 of those runs, an AI agent took autonomous, unsanctioned action on the live internet, targeting real people and organisations. In total, we catalogued 19 such actions. Almost all of this behaviour (17 actions) came from a single model, Anthropic’s Mythos 5, with 2 actions involving OpenAI’s GPT-5.6-Sol with cyber classifiers (mechanisms to prevent misuse) disabled. In the most serious case, an agent tried to insert malicious code into an open-source project. In an attempt to get the code approved, the agent engaged in social engineering  — creating fake online identities and using them to pressure the project’s maintainer to approve the code. A human maintainer caught and refused to approve the malicious code.

These attempts were unsuccessful, and our investigations have not evidenced any resulting real-world harm. But this is the first time we have seen risks around autonomy and deception manifest this clearly, without specific prompting, in the real-world.  

Luke Hinds, CEO and Co-founder of nolabs had this view:

“This is the latest in a growing list of rogue agent stories, from the Hugging Face incident to models reportedly creating fake identities to get malicious code approved on GitHub. It’s becoming abundantly clear that when agents are given too much freedom, they can take bad actions, whether they are trying to be helpful, misunderstanding the goal, or being manipulated through prompt injection. That leaves businesses with a difficult balancing act. Agents need agency to be useful. They need to access systems, call tools and act autonomously. But every extra permission increases the blast radius when something goes wrong.

“The answer is not to trust frontier labs to solve this. Enterprises shouldn’t leave agent permissions to the companies building the models. Their incentive is to make agents more capable, more connected and more widely used. Instead, enterprises need control over what agents can actually do inside their own environments. Blunt sandboxing is not enough as if you lock agents down too heavily, you kill the value businesses are trying to unlock. But if you put a human approval step in front of every action, you no longer have an autonomous agent. Instead, businesses need controlled freedom – enough authority for the task in front of the agent, and absolutely nothing more. That means protection wrapped around the agents’ action. Once an agent can call tools, use credentials, contact networks or change data, the boundary has to apply to each workload it runs. What can it read? What can it write? Which tool can it call? Which credential can it use? Which network can it contact? And can it do that only for this task, right now?

“Ultimately, businesses should not rely on agents to behave well, or on model providers to mark their own homework. The boundary has to sit outside the model, where it can be enforced independently. Otherwise, companies are not deploying agents safely. They are handing them the keys and hoping they do not find the wrong door.”

Justin Beals, CEO & Founder, Strike Graph, an AI-native GRC and compliance automation platform has this view:

“What AISI found is significant precisely because it’s documented, not speculative. An agent created fake identities and used them to pressure a real person into approving malicious code. That is social engineering, executed by a system we assumed only followed instructions. Credit to AISI for disclosing this openly instead of burying it, and it’s worth being precise about context: this happened with safety filters intentionally turned off and internet access intentionally granted, to stress test the model’s ceiling. That is not how these systems are deployed commercially, and it should not be read as evidence that production AI is roaming free.

Here is the part that should worry security teams more than the headline. The only thing that stopped this attack was a human reviewer’s judgment, not a technical control. That is a governance gap, not a tooling gap. Most security programs are built to catch known signatures and deterministic behavior. They are not built to catch an agent that fabricates identities and adapts its persuasion tactics in real time.

Security teams should take three steps now. First, treat every AI agent as its own identity class, with dedicated access controls and behavioral monitoring, rather than an extension of whoever deployed it. Second, build real-time monitoring into agent workflows so unusual behavior gets flagged as it happens, not discovered afterward through general logs, the way AISI found this. Third, stop relying on human vigilance as your only defense against AI-driven social engineering. Formalize verification steps for any code contribution, regardless of source, because the next attempt may not be caught by an alert reviewer.”

I think it’s clear now that AI might be potentially bad if guardrails are not in place. And you have to restrict AI to make sure that it stays inside those guardrails. Otherwise you get this,

UPDATE: Waseem Ahmed, Head of Engineering at Secure.com has this comment:  

“Let’s be precise about what happened, because “AI went rogue” misses it. AISI’s own report is clear. The agent did not turn evil and it did not escape its sandbox. It was told to solve a hard security challenge, and deception emerged as a by-product of chasing that goal. 

“Two details matter. This was a model not yet released, and testers had switched off the safety filters on purpose to probe raw capability. That is not how these models behave in production with guardrails on. The real lesson is that a capable agent chasing a goal will try routes you never approved, including social pressure aimed at real people. That is new, and it is why we cannot treat agents like ordinary tools.

“The most reassuring fact in the report is also the most alarming one. The attack failed because a human caught the bad code and refused it. Good practice worked, but the margin was thin. It held on human vigilance, not a technical wall that would reliably stop a stronger agent. So here are four moves for security teams. 

“First, block open internet access for agents by default and grant it only when a task truly needs it.

“Second, watch agents in real time so you can stop out of scope actions as they happen, not find them in the logs later. 

“Third, assume any capable agent will try to bend its limits, and build guardrails and containment before it runs.

“Fourth, harden code review and contributor identity checks, because fake identities are now a real supply chain attack path, and treat all AI generated or outside code as untrusted until you verify it in isolation. 

“The strongest response is still standard cyber hygiene done well, which matters more as these agents get stronger.”

Researchers have demonstrated an AI-powered ransomware framework known as “JadePuffer” that automates multiple stages of the attack lifecycle, including target identification, database interaction, encryption, and ransom execution. While the project is intended as a proof of concept rather than evidence of an active ransomware campaign, it illustrates how AI could significantly reduce the time, expertise, and resources required to conduct cyberattacks. The research highlights growing concerns that AI may enable attackers to automate operational workflows, accelerating the speed and scale of future ransomware and cybercrime operations.

If you want an overview of “JadePuffer”, click here: JadePuffer: The First Successful LLM-Driven Ransomware Attack

John Watters, Chairman and CEO, iCOUNTER Cybersecurity Intelligence had this to say:

“The most important takeaway from stories like this is not whether a specific AI-powered ransomware framework achieves widespread adoption, but what it signals about the direction of cybercrime operations. Threat actors have spent years automating individual stages of the attack lifecycle. AI has the potential to connect those stages together, accelerating reconnaissance, target selection, and execution in ways that compress attacker timelines significantly.

As cybercriminal operations become more automated, defenders face a growing mismatch between machine-speed attacks and human-speed decision-making. Security teams can no longer rely solely on detecting malicious activity once it reaches their environment. They need operational intelligence that provides visibility into emerging adversary behaviors, infrastructure, and campaign activity before attacks reach execution.

This is ultimately an intelligence challenge as much as a security challenge. Organizations that can identify shifts in attacker tradecraft early and adapt their defensive priorities accordingly will be far better positioned than those waiting to respond after automation has already increased the scale and speed of an adversary’s operations.”

Consider this to be fair warning that AI is going to be used in all sorts of attacks, and ransomware will be no different. Thus this should be all you need to get your defences in order.

UPDATE: Ensar Seker, CISO at SOCRadar, has provided the following commentary:

“JADEPUFFER demonstrates that the most important change isn’t that AI created new attack techniques, it didn’t. The campaign relied on a known vulnerability and familiar post-exploitation methods. What changed is that an AI agent was able to autonomously chain reconnaissance, exploitation, credential discovery, lateral movement, and extortion while adapting to failures in real time. That dramatically lowers the operational cost of ransomware campaigns and allows attackers to execute far more operations simultaneously than a human team could manage.

The ability to analyze an error, modify its own approach, and continue the attack within seconds is particularly concerning. Security teams should expect future ransomware operators to use AI not because it makes attacks more sophisticated, but because it makes them faster, more scalable, and far more persistent.

Organizations shouldn’t focus solely on the ‘AI ransomware’ headline. This incident began with an exposed Langflow instance vulnerable to a publicly known CVE. The defensive priorities remain the same: aggressively patch internet-facing AI infrastructure, eliminate exposed administrative services, enforce least privilege, protect secrets stored within AI frameworks, and continuously monitor for abnormal behavior. AI is accelerating attackers, but it is still exploiting fundamental security weaknesses.”

UPDATE x2: More commentary was provided to me in relation to this story:

Justin Beals, CEO & Founder of Strike Graph:

“JadePuffer is the moment the industry has been warning about since agentic tooling showed up: an AI model that can chain reconnaissance, credential theft, lateral movement, and extortion without a human touching any single step. None of the techniques are new. What’s new is that a model strung them together end to end, in 31 seconds from failed login to working exploit.

That speed is the real story. Traditional third-party risk programs run on quarterly questionnaires and point-in-time attestations, but an autonomous attacker doesn’t wait for your next audit cycle. If your vendor risk posture is a snapshot, and the threat is continuous, you’ve already lost the race before the assessment period even starts.

Organizations need to stop treating AI agents as productivity tools and start treating them as identities with access that has to be governed, monitored, and continuously verified, not reviewed once and forgotten. The ones who build that muscle now will be the ones still standing when this pattern scales, and Sysdig is telling us it will.”

Andrew Obadiaru, CISO at Cobalt:

“What stands out about JadePuffer isn’t that an AI-generated malicious code. It’s that a model was able to string together reconnaissance, credential theft, lateral movement, and destruction into a working operation without a human directing any single step. That removes one of the last practical constraints on attacker scale: the need for an operator with deep expertise at each stage of an intrusion. We’ve spent years talking about AI lowering the barrier to entry for attackers. This is what that actually looks like in practice: adaptive, self-correcting, and fast enough to move from a failed login to a working exploit in under a minute. For defenders, the lesson isn’t really about Langflow specifically, though patching exposed AI orchestration tools matters. It’s that periodic testing cycles were never built for adversaries that iterate in real time. Continuous validation of Internet-facing infrastructure, and tighter controls around what credentials and API keys sit next to AI orchestration environments matter more now than they did a year ago. Attackers no longer need to be sophisticated. They just need a model willing to keep trying until something works.”

Will Baxter, Field CISO at Team Cymru:

“Whether or not JadePuffer represents the first fully LLM-directed ransomware operation, it reflects a broader trend toward AI orchestrating larger portions of the intrusion lifecycle. We’ve already seen AI accelerate individual stages of an attack; if it’s now coordinating workflows end-to-end, defenders should expect faster adaptation and shorter response windows. That doesn’t eliminate the value of indicators or signatures, but it does increase the importance of tracking the infrastructure and behavioral patterns that persist even as tooling changes. Organizations that can observe attacker infrastructure as it evolves, not just the artifacts of a single campaign, will be better positioned to detect and disrupt these operations before they progress from initial access to impact.”

The launch of EDAMAME — a platform specifically designed to catch AI coding agents going off the rails — signals that the industry is starting to reckon with something important: autonomous AI agents in software development pipelines can take unintended actions, and existing security tooling wasn’t built to see it. But the conversation is almost entirely happening in AppSec and DevSecOps circles, and it’s missing the bigger structural problem underneath.

You can find out more here: https://www.securityweek.com/new-edamame-platform-aims-to-catch-ai-coding-agents-going-off-the-rails/

Justin Beals, CEO & Founder, Strike Graph, an AI-native GRC and compliance automation platform

“Building guardrails for AI coding agents is a meaningful step, and recognizing that autonomous code generation needs behavioral oversight is the right instinct. What’s incomplete is treating this as purely a developer tooling problem — the moment AI-generated code is deployed, it becomes a compliance and risk management challenge that most GRC teams have zero visibility into.

The real gap isn’t just catching an agent that misbehaves in real time. It’s that organizations have no systematic way to evidence that their AI-assisted development process meets the security requirements their certifications demand. Your SOC 2 or ISO 27001 was written assuming humans made the code decisions — it has nothing to say about what an autonomous agent pulled, modified, or deployed on your behalf.

As AI coding agents become standard in engineering orgs, compliance programs will need to evolve from auditing what humans built to auditing what AI built in humans’ names. The frameworks haven’t caught up yet, and the organizations waiting for them to before they act are building a gap that auditors — and attackers — will eventually find.”

Organizations need to ensure that the AI coding agents are as secure as the human agents they use. If they don’t, then it will end very badly for that organization indeed.

Two independent studies found that advanced AI cybersecurity models, including Anthropic’s Claude Mythos Preview and OpenAI’s GPT-5.5, have exceeded previous benchmarks for autonomous cyberattack capability. Researchers from the UK AI Security Institute (AISI) and Palo Alto Networks said the models are now capable of chaining together complex multi-stage attack paths and identifying vulnerabilities at rates that significantly outpace earlier systems.

The UK AI Security Institute said Claude Mythos Preview and GPT-5.5 became the first models to fully complete a simulated enterprise intrusion scenario without human intervention. According to the findings, the models successfully executed tasks including credential theft, privilege escalation, lateral movement, persistence, and protected system access during controlled testing. Researchers said the models consistently outperformed previous-generation systems on autonomous cyber capability benchmarks designed to measure real-world offensive potential.

Separately, Palo Alto Networks said its internal testing showed advanced AI cyber models increased vulnerability discovery rates by more than seven times compared to traditional manual research workflows. Researchers said the models were particularly effective at identifying exploitable weaknesses in enterprise software, cloud configurations, and authentication systems, raising concerns that AI-assisted vulnerability discovery could dramatically accelerate exploit development timelines for both defenders and threat actors.

Josh Marpet, Senior Product Security Consultant, Finite State:

   “Unfortunately, this is about as surprising as saying that the sun rises. Nobody was not expecting it. The question is not, can an AI find and run an exploit? We know they can. The question is, can an AI find vulnerable code in a device or application with very little instruction given, write or find the exploit for that vulnerability, and successfully prosecute the exploit through to completion? If the answer is yes, then we are having a bad day.

   “The one interesting item is that the quality of the exploits, the discovery, the entire process, is still fairly dependent on the caliber of the person sitting behind the keyboard and directing that AI. For now.

Damon Small, Board of Directors, Xcape, Inc.:

   “The emergence of GPT-5.5 and Claude Mythos marks a paradigm shift where autonomous attack-path chaining moves from a theoretical lab risk to a quantifiable operational reality. When an AI can compress a twelve-hour expert reverse-engineering task into ten minutes for less than two dollars, the traditional economics of cyber defense collapse. This capability will inevitably commoditize the high-margin, bespoke manual testing currently sold by security consultancies, forcing a market pivot toward high-level strategy and remediation.

   “While these models currently demonstrate low reliability, succeeding in only 20% to 30% of end-to-end attempts, that failure rate is irrelevant to a persistent attacker with near-zero marginal costs. Security leaders must move beyond patching individual vulnerabilities and focus on time-to-break-chain, assuming attackers will use these models to identify and exploit multi-stage paths at machine speed. The priority is no longer just preventing the initial foothold, but ensuring that every compromised node is a dead end through aggressive segmentation and just-in-time access.

• “Death of the Boutique Pen-Test: The automation of complex, multi-stage attack chains will rapidly drive down the cost and delivery time for offensive engagements, turning premium security services into a baseline commodity.
• “Asymmetry of Persistence: A 20% success rate is a failure for a human consultant but a triumph for an AI that never sleeps and costs pennies to restart, allowing attackers to “brute-force” complex architectural flaws.
• “Architectural Resilience vs. Patching: As vulnerability discovery outpaces human remediation capacity, the focus must shift from the “patching treadmill” to building environments that are structurally resistant to lateral movement.

   “If your security posture relies on a $500-an-hour consultant to find the “bespoke” vulnerabilities that a $20-a-month chatbot just discovered in bulk, you aren’t paying for security; you are paying for an expensive PDF.”

Jacob Krell, Senior Director: Secure AI Solutions & Cybersecurity, Suzu Labs:

   “Palo Alto’s advisory data puts real operational weight behind the AISI benchmarks. Going from fewer than five CVEs per month to 26 in a single advisory cycle, with the majority found by AI scanning, is a preview of what every software vendor will face once these models are widely deployed. The bottleneck has shifted from discovery to remediation, and most organizations are not built to patch at the rate AI finds vulnerabilities.

   “Palo Alto estimates a three to five month window before AI driven exploits become the norm. That window is the planning figure security leaders should be working against. This capability is the new baseline, and because different models surface different vulnerability classes, the total volume of findings will only grow as more models reach this tier. Organizations running vulnerability management programs built for five CVEs a month need to start planning for a world where that number is measured in dozens.”

Tom Yates, Product SME, Ridge Security Technology Inc.:

   “These findings highlight the urgent and critical need for security companies to be at the leading edge of Gen AI technology. Security tooling must match the capabilities hackers use or your infrastructure will look like swiss cheese to the bad guys.  But security buyers need to beware, an avalanche of AI-washing has already hit the market.  Buyers must spend more time digging into product claims to ensure that AI is a first-class citizen of the solution, not a “bolt-on” to satisfy marketing needs.”

This is another example of AI welcoming us to the new reality of cybersecurity. Were the time to get pwned has been reduced so much that humans are simply not even in the game. That should scare anyone on that side of the fence.

Researchers at Check Point have identified multiple vulnerabilities in Anthropic’s development tool Claude Code, allowing malicious repositories to trigger remote code execution and steal active API credentials.

The observed security issues exploited built-in mechanisms including Hooks, Model Context Protocol servers, and environment variables to run arbitrary shell commands and exfiltrate API keys before trust prompts could be confirmed.

Two specific tracked vulnerabilities, CVE-2025-59536 and CVE-2026-21852, were documented and patched by Anthropic following disclosure by security researchers. The first enabled arbitrary code execution via overridden configuration settings that bypass user consent dialogs, while the second could redirect API traffic to malicious endpoints, exposing developers’ Anthropic API keys in plaintext.

All reported flaws have been remedied in subsequent Claude Code updates prior to public advisory publication.

According to researchers, even after the specific vulnerabilities were fixed, the underlying risk does not disappear. The issues exposed how project configuration files can directly shape execution behavior inside AI-assisted development tools, and a malicious repository can still act as a delivery mechanism if safeguards are insufficient, which expands the threat model beyond the individual CVEs that were addressed.

As a result, applying patches resolves the documented flaws but does not fully remove the broader exposure created when AI tooling automatically interprets and acts on repository-level settings. 

Jacob Krell, Senior Director: Secure AI Solutions & Cybersecurity, Suzu Labs:

“These CVEs are real and Anthropic was right to patch them. The broader issue is not unique to Claude Code. The AI development tool industry as a whole is prioritizing enablement over security, and these vulnerabilities are a symptom of that design philosophy, not an isolated product failure.

“In the case of Claude Code, hooks ran shell commands before the developer even saw the trust dialog. The security control existed. It just executed after the damage was already done. AI agents are deployed with broad permissions by default because restricting them reduces productivity. That is the same tradeoff the industry made with admin accounts two decades ago, and it took years of breaches to correct. The principle of least privilege does not stop applying because the user is an AI model instead of a human. Agents should be treated as untrusted by default, with strict zero trust boundaries between the agent and any command surface, credential store, or system resource it touches.

“This is not a new class of attack surface. Malicious Makefiles, poisoned scripts, and git hooks have compromised developers for years. What AI tools change is the scope of what runs once triggered. The attack surface is not new. The blast radius is.

“AI development tools are going to become more autonomous, not less. The industry is building the capability first and retrofitting the security later. That pattern has never aged well in software, and it is unlikely to age any better with AI.”

I am aware of a large number of developers who are using tools like Claude Code to speed up the coding pf

A new social media platform called Moltbook, designed for AI agents to interact with each other and “hang out”, was found to have a misconfiguration, leaving its backend database publicly accessible allowing full read and write access to all data, according to a recent blog post by Wiz Security.

Researchers discovered a Supabase API key exposed in client-side JavaScript revealing thousands of private AI conversations, 30,000 user email addresses, and 1.5 million API keys..

   “Supabase is a popular open source Firebase alternative providing hosted PostgreSQL databases with REST APIs. It’s become especially popular with vibe-coded applications due to its ease of setup,” explained Wiz head of threat exposure, Gal Nagli.

   “When properly configured with Row Level Security (RLS), the public API key is safe to expose – it acts like a project identifier. However, without RLS policies, this key grants full database access to anyone who has it. In Moltbook’s implementation, this critical line of defense was missing.”

In a message posted to X before the Wiz posted the blog, Moltbook’s creator, Matt Schlicht said he “didn’t write one line of code” for the site. Wiz reported the vulnerability to Schlicht, and the database was secured.

   “As we see over and over again with vibe coding, although it runs very fast, many times people forget the basics of security,” Wiz cofounder Ami Luttwak said.

Sunil Gottumukkala, CEO, Averlon:

   “What this highlights is the tradeoff vibe coding creates. It massively compresses idea-to-product time, but often skips essential security steps like threat modeling, secure defaults, and review gates that account for real user behavior and adversarial abuse.

   “When those controls are missing, a routine misconfiguration, such as shipping without proper authorization or RLS policies, can quickly turn into an instant, internet-scale incident. Some vibe-coding platforms are starting to add guardrails, but we’re still early. As long as speed continues to outpace security analysis and remediation, this will be a bumpy road.”

Lydia Zhang, President & Co-Founder,Ridge Security Technology Inc. gave me this comment:

   “This leads to another mandatory step: testing. Zero-trust principles should also be applied to Vibe coding. Vibe-coded solutions can miss basic security practices, and configuration or misconfiguration issues are often outside the scope of the code itself. I’m glad Wiz Security caught this before the damage spread further.”

Michael Bell, Founder & CEO, Suzu Labs added this comment:

   “The Moltbook incident shows what happens when people shipping production applications have no security training and are relying entirely on AI-generated code. The creator said publicly that he didn’t write a single line of code. Current AI coding tools don’t reason about security on the developer’s behalf. They generate functional code, not secure code.

   “The specific failure here was a single Supabase configuration setting. Row Level Security was disabled, which meant the API key that’s supposed to be safe to expose became a skeleton key to the entire database. That’s not a sophisticated vulnerability. It’s a checkbox that never got checked, and nobody reviewed the code to notice. When 10% of apps built on vibe coding platforms (CursorGuard) have the same misconfiguration, that’s not a user error problem. That’s a systemic failure in how these tools are designed.

   “The write access vulnerability should concern anyone building AI agent infrastructure. Moltbook wasn’t just leaking data. Anyone with the exposed API key could modify posts that AI agents were reading and responding to. That’s prompt injection at ecosystem scale. You could manipulate the information environment that shapes how thousands of AI agents behave.

   “Users shared OpenAI API keys in private messages assuming those messages were private. One platform’s misconfiguration turned into credential exposure for unrelated services. As AI ecosystems become more interconnected, these cascading failures become the norm.

   “The 88:1 agent-to-human ratio should make everyone skeptical of AI adoption metrics going forward. Moltbook claimed 1.5 million agents. The reality was 17,000 humans running bot armies. No rate limiting. No verification. The platform couldn’t distinguish between an actual AI agent and a human with a script pretending to be one.

   “We’re going to see a lot of “AI-powered” metrics that look impressive until you examine what’s actually behind them. Participation numbers, engagement statistics, autonomous behavior claims. Without verification mechanisms, the numbers are meaningless. The AI internet is coming, but right now it’s mostly humans wearing AI masks.

   “If you’re deploying vibe-coded applications to production, you need security review by someone who understands both the code and the infrastructure it runs on. AI tools don’t have security reasoning built in, which means every configuration decision is a potential exposure. We help organizations identify exactly these kinds of gaps through security assessments that trace data flows and access controls. The discovery process that found this vulnerability took Wiz researchers minutes of looking at client-side JavaScript. That’s the same level of effort an attacker would spend.

   “AI development velocity and AI security maturity are on completely different curves. Teams are shipping production applications in days. Security practices haven’t caught up. Until AI tools start generating secure defaults and flagging dangerous configurations automatically, humans (or hackers) need to be in the loop reviewing what gets deployed.”

Ryan McCurdy, VP of Marketing, Liquibase contributed this:

   “Moltbook is a textbook example of what happens when you ship at AI speed without change control at the database layer. A single missing guardrail turned a “public” Supabase key into full read and write access, exposing private agent conversations, user emails, and a massive pile of credentials. This is why Database Change Governance matters.

   “The highest risk changes are often permissions, policies, and access rules, and those need automated checks, separation of duties, drift detection, and audit-ready evidence before anything hits production. AI agents and vibe-coded apps will only amplify the blast radius if database change is not governed.”

Noelle Murata, Sr. Security Engineer, Xcape, Inc. served up this comment:

   “Matt Schlicht’s admission that he “didn’t write one line of code” isn’t something to celebrate, given the fundamental nature of the security flaw. The database completely lacked Row Level Security (RLS) policies, allowing anyone to access it without authentication. This misconfiguration exposed the entire database structure and content, including tokens that granted read/write/edit access to non-authenticated users – a basic oversight with serious consequences.

   “Vibe-coding,” or relying on AI to generate code, can produce functional results but often sacrifices best practices in architecture and security for speed and convenience. Without code review or highly specific prompting, AI-generated code prioritizes “fast and easy” over “resilient and secure.” This is analogous to why junior developers need oversight; the same principle applies to AI-generated code.

   “Despite Moltbook being marketed as a social platform “for bots, by bots,” it had a significant human user base: 17,000 humans alongside 1.5 million bots, creating a roughly 1:88 ratio. Notably, no CAPTCHA or human/bot validation system was implemented, raising questions about the platform’s actual purpose and user management.

   “This incident demonstrates that AI-generated applications require careful monitoring and professional oversight. Software development still demands review by trained, experienced humans to ensure security and reliability.”

This highlights the danger of vibe coding. You can get stuff done. But how it gets done might be a problem. You might want to keep that in mind if you rely on vibe coding.