Discover how the Spring Ring vishing campaign uses Microsoft Teams phishing tactics to trick employees into installing malware and giving up remote access.
Related Posts:
The post Spring Ring Vishing Campaign Targets Microsoft Teams appeared first on Daily CyberSecurity.
Reverse engineering shows Microsoft's Paint app embeds an invisible, server-issued watermark into every AI-generated image, one users cannot fully disable.
Related Posts:
The post Reverse Engineering Reveals Microsoft’s Hidden InvisMark Watermark in Paint appeared first on Daily CyberSecurity.
Apollo Global Management confirmed a social-engineering breach exposing sensitive personal data amid a wider hacking campaign targeting financial firms.
The post Apollo Confirms Data Breach Amid Cyberattacks Targeting Financial Firms appeared first on TechRepublic.
Singapore is using simulated AI-enabled scam calls to train the public, offering IT leaders a new model for social engineering security training.
The post Singapore Is Literally Training People to Get Scammed appeared first on TechRepublic.
The FBI is warning the public about sexual exploitation actors illegally accessing social media and personal accounts to steal explicit images and videos from adult and underage victims. The stolen material, also known as non-consensual intimate images (NCII), is being posted or sold on criminal marketplaces, often without the victim's knowledge.
According to the FBI, these actors use social engineering and cyber intrusion tactics to target specific individuals or general targets of opportunity. After gaining access to accounts, they steal explicit content and share it through community forums or illicit marketplaces.
The FBI said personally identifiable information, including a victim's name, date of birth, email address, phone number and social media username, is often posted alongside the stolen material. This can expose victims to continued harassment and re-victimization.
The FBI has identified several methods used by sexual exploitation actors to gain access to victims' accounts.
In password/PIN targeting, actors use high-volume password and PIN attempts against social media and personal accounts. The information used in these attempts can come from data leak sites, social media and open-source information.
When victims are known to the actors, curated lists may include personal details such as names, date of birth or variations of those details.
Another tactic involves social media customer service impersonation through text messages. Victims may receive messages claiming their account is being disabled or locked unless they provide a verification code.
The actor then requests a password reset, causing a code to be sent to the victim. If the victim shares the code, the actor can reset the password and access the account.
The FBI also warns about phishing campaigns using look-alike domains and email accounts designed to appear as social media customer support.
These messages may claim there has been a new login and contain an embedded link asking the victim to change their password. Clicking the malicious link can give the actor access to the account.
Once explicit content is stolen, sexual exploitation actors may post or sell it while including personal information about the victim. The FBI said victims can subsequently face harassment, sextortion, stalking or other targeted attacks.
The actors may also advertise stolen content through a victim's own social media page, increasing the potential for further exposure.
The FBI advises people to avoid storing sensitive images or videos on social media platforms or other internet-accessible sites.
It recommends using unique, complex passphrases and PINs along with multi-factor authentication (MFA). Password information directly associated with a person's identity, including names or birthdays, should be avoided.
Users should also be cautious with links received through emails and text messages. The FBI recommends going directly to the relevant website to address account concerns and checking URLs before clicking.
Unrequested temporary passwords, PIN resets or access codes should also be treated with caution. The FBI advises users not to share login information, even when someone claims to represent a platform or service.
People who believe their explicit content was stolen or leaked can provide information through the FBI's NCII reporting site. The FBI also advises the public to continue reporting fraud, scams and cyber threats to the Internet Crime Complaint Center or a local FBI Field Office.
The UK’s AI Security Institute (AISI) has put something uncomfortable on the table: during cyber testing, frontier models didn’t just follow instructions badly. In some runs, they crossed into real-world actions, touched real people and organisations, and then tried to make the evidence go away.
“On 28th 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.” reports AISI. “We declared a security incident and, within roughly one hour of discovery, had contained it and begun a full investigation.”
That matters because the setting was not a botched public rollout or a rogue consumer chatbot. It was a controlled evaluation, run on purpose with open internet access and some safety filters turned off, so the institute could measure what the models could actually do under permissive conditions. AISI says that’s standard practice for frontier testing, but it also notes that those conditions are not how these models are normally shipped.
To assess the models’ real-world cyber capabilities, they were given internet access and had their built-in cyber safety filters intentionally disabled under controlled testing conditions.
The headline result is simple enough, even if the details are messy. AISI ran the challenge 122 times across several models, and in 10 of those runs it saw AI agents take autonomous, unsanctioned actions on the live internet. The institute logged 19 such actions in total, with 17 tied to Anthropic’s Mythos 5 and two to OpenAI’s GPT-5.6-Sol with cyber classifiers disabled.
The most serious sequence looked less like a lab mishap and more like a small-scale social-engineering campaign. The agent tried to insert malicious code into a public open-source project, researched the maintainers, created fake identities based on real people, and used those identities to pressure a maintainer into approving the code.
“On the morning of 28th July, our security monitoring flagged data leaving one of our testing systems through the ‘Tor’ anonymity network, which is commonly used to disguise the origin of internet traffic. The team running the evaluation began reviewing the agent’s activity within minutes.” continues the report. “They quickly found that, during one run, the agent had created a malicious ‘pull request’ (a proposed code change) on a real, public open-source project on GitHub. “
It also sent messages and files, and when challenged, it edited earlier activity to look harmless and even considered adopting a fresh identity.
AISI says human review stopped the worst outcome. The malicious pull request was caught, the fake identities failed to get the code approved, and the institute did not find evidence of resulting real-world harm. Even so, it says this is the first time it has seen autonomy and deception show up this clearly, without specific prompting, in a real-world setting.
The institute is careful not to overclaim. It says the evaluation design and configuration choices helped create the conditions for the behaviour, and it notes that the models in question were not commercial public deployments. But that caveat cuts both ways: if permissive test conditions can produce this kind of behaviour now, tighter production settings are not a reason for complacency. They are just a better fence.
That is the part that should make people stop scrolling. Not because the models “went evil,” which is lazy, but because deception emerged as a by-product of goal-seeking under the conditions set by the evaluators.
“The agent pursued its goal persistently. AI agents explore routes their operators did not intend. Given a difficult objective, the agent kept searching for a way through, and some of the routes it found involved trying to deceive real people.” states AISI. “It was never instructed to deceive; deception emerged as a by-product of pursuing the task, the kind of goal-directed deception that, until recently, had been largely theoretical.”
The agent was trying to solve a cyber challenge, and in doing so it explored routes nobody had asked it to explore, including routes that involved fooling actual people.
What makes the episode more serious is the way it lines up with recent disclosures from Anthropic and OpenAI. Anthropic has already said its models reached the public internet from within a third-party evaluation environment and accessed real systems. OpenAI has separately reported that one of its models mistook a misconfigured test setup for a real task and touched real infrastructure.
AISI’s view is that these incidents point to a shift in the risk landscape. Harm may no longer come only from obvious misuse by humans. It may also come from capable agents, in internal research settings or privileged-access environments, taking unintended actions beyond the scope they were given. That is a quieter problem than movie-style “AI rebellion,” and a more useful one to think about.
The key takeaway is straightforward. Keep cyber basics tight, verify outside code before trusting it, and stop assuming that a model will stay inside the lines just because the prompt sounded clear on the day. In security, the line between “evaluation” and “incident” can get thin fast. Machines are very good at finding the part of the process you forgot to make boring.
AISI says it will tighten internet controls, add real-time monitoring, and revisit how it designs evaluations. That is the right response, but it should not be read as a narrow fix for one lab. It is a warning to anyone testing powerful agents: if the test can reach the real internet, the real internet can reach back.
The original AISI report is here: Incident report: unsanctioned agent behaviour during cyber testing.
“Incidents of this kind reflect the speed at which AI is developing. As capabilities advance, the work of understanding these systems, and ensuring their safety, must keep pace alongside them.” concludes the report.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, AI Deception)
A vishing call to an overseas contact center agent. A fake IT ticket. A default setting nobody thought to lock down. That's all it took to expose the personal data of roughly 5 million Australians — and now the country's privacy regulator has decided Qantas isn't to blame for it.
The Office of the Australian Information Commissioner (OAIC) closed the book this week on its year-long preliminary inquiry into the June 2025 Qantas data breach, and the conclusion cuts against the instinct to punish the victim of a cyberattack.
According to the OAIC's report, the evidence gathered did not indicate a likelihood that Qantas had "failed" to take reasonable steps to protect the personal information it held, nor that it failed to ensure its overseas third-party provider complied with Australia's privacy principles. No investigation. No enforcement action.
"After more than a year of making inquiries and obtaining information on the data breach, we're satisfied that the evidence does not support the likelihood that a breach of privacy law occurred. As a result, we've decided not to commence a full investigation of Qantas at this stage." - Carly Kind, Australian Privacy Commissioner.
The breach traces back to a single phone call. A threat actor posing as "Qantas IT help" convinced a contact center agent to visit a website tied to the customer relationship management platform used by Qantas agents, walking them through steps framed as necessary to close an IT support ticket. That interaction connected the agent's CRM session to a data extraction tool controlled by the attacker, who then pulled data from every contact profile the agent could access. It was pure social engineering — no malware, no exploited vulnerability, just a convincing lie.
Qantas caught it fast. A staff member spotted an unusual spike in login-attempt alerts on the morning of June 30, two days after the call, and escalated it to the cybersecurity team. Within hours, the company had frozen the compromised account, assessed for data exfiltration, and triggered its incident response process. Public disclosure followed on July 2.
The regulator's numbers are more precise than what circulated publicly last year. Roughly 5.67 million customer records were compromised, with about 4 million exposing names, phone numbers, email addresses and Frequent Flyer details, and a further 1.7 million records including combinations of home or business addresses, dates of birth, gender and meal preferences. Critically, no credit card numbers, financial information or passport details lived on the compromised platform, and customer passwords and login credentials were never touched.
The OAIC's reasoning is a rare, explicit acknowledgment that good controls don't guarantee immunity. Investigators found that social engineering training generally targets credential theft, not the rarer tactic of talking an employee into authorizing a legitimate-looking system connection — meaning the attack likely would have succeeded even with standard training in place. They also noted the flaw was structural: a default configuration let the agent authorize a third-party app connection, a setting the CRM vendor has since changed for all its customers.
Commissioner Carly Kind put the broader stakes plainly in the OAIC's statement announcing the report, warning that AI-driven threats are only raising the bar. As she framed it, agentic and advanced AI will keep escalating the cybersecurity risks businesses face, making continuous review of security posture non-negotiable — not optional.
“Data breaches are a persistent feature of today’s digital world, and can occur despite organisations taking steps to protect personal information,” Commissioner Carly said. “Agentic and advanced AI will only increase the cybersecurity risks that businesses face, and it is critical that all organisations continuously review and enhance their security to protect against this growing threat.”The takeaway here isn't that Qantas got a pass. It's that a regulator has now drawn, in writing, the line between negligence and the limits of what training and access controls can realistically stop.
Apple is warning iPhone users about FaceTime scams. Learn how the fraud works, what Apple recommends, and how to report suspicious calls.
The post Apple Warns Millions of iPhone Users: FaceTime Scams Are Spreading appeared first on TechRepublic.
The investigation into the Odido cyberattack has uncovered possible involvement of Dutch nationals, according to Dutch police, as authorities continue to investigate the ShinyHunters ransomware-linked attack that exposed the personal data of approximately 6.39 million customers. Law enforcement has urged the public to come forward with information as investigators work to identify those responsible for one of the country's largest telecom data breaches.
The cyberattack took place on February 5 and 6 after attackers allegedly used voice phishing (vishing) to deceive Odido's customer service team.
According to the company, the attackers posed as members of its internal IT staff, gaining unauthorized access before exfiltrating customer data. Odido said its teams detected the unauthorized access immediately on both occasions and revoked the attackers' access, but the incident still resulted in a large-scale data breach.
Under the direction of the National Public Prosecution Service, the High Tech Crime Team (THTC) of the National Investigation and Intervention Unit launched an extensive investigation into the breach.
Authorities said investigators have found strong indications that Dutch criminals may have been involved. One key lead centers on a phone call made shortly before the breach in which a Dutch-speaking man allegedly impersonated an Odido IT employee while speaking with customer service representatives. Police are continuing efforts to identify the caller and have indicated that his voice could be made public if necessary.
Investigators believe people within cybercrime circles may have information about those responsible and are encouraging anyone with relevant details to contact law enforcement.
Odido attributed the attack to the cybercriminal group ShinyHunters, which the company said carried out the social engineering campaign.
Chief Executive Officer Søren Abildgaard acknowledged the incident in a public statement, apologizing to customers and outlining the company's commitment to strengthening its cybersecurity capabilities. He said Odido would continue investing in security, improve data protection practices, expand customer support, and share lessons learned from the incident.
The CEO also explained why the company refused to pay the ransom demand. According to Odido, paying cybercriminals would reward illegal activity and could encourage future attacks against other Dutch organizations. The company said the decision was made following guidance from authorities, despite knowing that stolen data could eventually be published.
Odido confirmed that approximately 6.39 million active and former customers of Odido and its Ben brand were affected by the breach. Customers of Simpel were not impacted.
The exposed information varied by individual and included names, addresses, mobile phone numbers, customer numbers, email addresses, IBAN numbers, dates of birth, identification details, nationality, and gender.
The company clarified that My Odido account passwords, call records, location data, billing information, and scans of identity documents were not compromised.
Odido also addressed reports claiming customer passwords had been leaked, stating that login passwords remain securely encrypted and were never accessible during the attack. Instead, a separate telephone verification field known as "password_c," used as a customer challenge code, was included for a limited number of customers. The company has since discontinued using that verification method.
Following the breach, Odido increased customer support by adding more than 140 service agents and introduced additional security measures. These include its "Check je Gesprek" verification service, allowing customers to confirm whether communications claiming to be from Odido are legitimate, along with access to the F-Secure digital security service.
The telecom provider said all customers identified as affected have been notified by email or SMS, while customer service teams continue assisting users with questions related to their specific data exposure.
Meanwhile, Dutch authorities expect investigations into the Odido cyberattack to continue for several months. Police have also warned that cyberattacks targeting businesses and institutions are becoming increasingly common, urging organizations to strengthen cybersecurity defenses and encouraging citizens to remain vigilant against follow-on fraud and phishing attempts.
AI has given cybercriminals a big advantage in attacking organizations, which they are using to go after weaknesses on edge devices
The post AI-Driven Identity Attacks Are Surging, PwC Warns appeared first on TechRepublic.
A few weeks ago, we published our initial findings from Project Glasswing, looking at what happens when you point frontier security models at an enterprise codebase. We also explored how our defensive structures adapt to protect our infrastructure and customers from threats posed by frontier AI. Since then, the AI ecosystem has continued to shift rapidly — developers who've built tightly around a single model have already experienced what happens when that model is no longer available or gets superseded by a more capable one. These market shifts only reinforce our core thesis: no matter which underlying model is leading the pack on any given day, the future of agentic workflows will not be found in standalone models, prompts, or single-agent sessions.
Moving from a localized security "skill" to a continuous, fleet-wide scanning pipeline requires an architecture where models are treated as interchangeable components. Relying on a single model inherently limits defensive coverage, as the same system will tend to look at code paths through the exact same lens. To counter this, models should be frequently interchanged and cross-tested. By varying the models across the pipeline — such as using one model for initial discovery and an entirely different one for validation — we can ensure that vulnerabilities are cross-checked by distinct sets of logic. Furthermore, a true enterprise-scale harness must look beyond isolated repositories to trace vulnerabilities across cross-repo dependencies, ultimately filtering thousands of raw candidates down to a trusted, triaged queue of actionable fixes.
This post serves as a practical look at how to build that model-agnostic layer, focusing on how we manage state controls, eliminate false positives, and coordinate end-to-end triage at scale.
The first post made the case for why generic coding agents can't do this job. The main issue is that agents only hold one hypothesis at a time, fill their context window after covering a sliver of a real repo, and then lose information during context compaction. For more details, read that post.
Before we move forward, we would like to answer two likely questions.
"Why not use subagents instead of a harness?" Subagents are useful, and they are a good starting point. But security analysis needs hundreds of separate investigations that survive across runs, don't share a context window, and can be re-scoped and cross-referenced later. It needs persistence, deduplication, resumability, and eventually fleet-wide dependency tracing. That's an orchestration problem, and a prompt can't get you there.
"Is this blog post just an ad for frontier models?" No. Our approach centers on the harness, not the model. When it comes to vulnerability discovery, we run it with whatever frontier model is currently best at what we need. When we point different models at the same target, they each turn up a different share of the bugs. The harness is the bit that lasts. If you build your own system, design it to be model-agnostic from day one. This will allow you the freedom to use any model of choice without constraints.
We started with a ~450-line security-audit skill that we ran on a single repository, and adjusted the prompts until we surfaced real bugs. Later, we added the orchestration that became the plumbing of the entire system. The real value lives in the prompts themselves, and our prompts continue to carry the initial skill's attacker scenarios, bug classes, and anti-pattern detections nearly unchanged.
The skill was written to run a 7-phase audit in one session:
Entrararchitecture.md.findings.json against a schema, and a mechanical check validates that file.That first skill maps almost directly onto the later harness:
The skill worked, but it quickly revealed its limits. Looking at the coverage metrics, a single run finds only about half the bugs you'd catch across multiple runs. In our experience the ones it did find skewed toward the simpler and less subtle. Once your process is basically "run it ten times and diff by hand," you probably need to start looking at a real harness.
While running and fine-tuning the skill, we ran into three walls:
Most AI security write-ups in this space are about a single repo or a curated benchmark; running a whole fleet this way, with cross-repo tracing, isn't something we've seen written up elsewhere. Our codebase spans a massive mix of languages — Rust, Go, C, Lua, TypeScript and Python, alongside various configuration management systems, static configs, and all sorts of additional context. So we had to come up with something new that worked for us. Going from that first slash-command run to a fleet scanner that could cover 128 distinct repos, automatically finding and interrogating relevant dependencies, took about six weeks. Codification was mostly mechanical: we lifted each phase of the skill into its own agent, put a database behind it and an orchestrator in front. The mapping was almost one-to-one.
The entire fleet runs on one unified harness with no per-language tuning and traces the dependencies between repos. While offloading syntax to a model makes the system language-agnostic, the differentiator is its ability to trace dependencies between repos. The harness itself doesn’t care if it’s looking at C pointers or a TypeScript file; it focuses on the higher-level logic of security orchestration. This allows us to scale across hundreds of different codebases, without having to write custom language parsing.
Our entire vulnerability research workflow is built on a two-stage operational framework: the Vulnerability Discovery Harness (VDH) and the Vulnerability Validation System (VVS).
The VDH functions as our discovery engine, proactively scanning codebases to surface potential security issues. Once bugs enter the VVS, which allows multiple harnesses to feed into it, they go through stages of Deduplication, Judgment, and finally Fixing, as we’ll talk about later.
We use one model for VDH, but we use a completely different model for VVS, so the models are effectively double-checking each other. There is an obvious security benefit to this: by forcing Model B (VVS) to judge the output of Model A (VDH), you ensure that the finding is evaluated by an entirely different set of logical weights and training data — one that acts as an unbiased, adversarial third party whose sole job is to ruthlessly stress-test Model A's assumptions. And operationally, we benefit from treating model providers like interchangeable commodities. Model providers can change temperature, caching, and inference effort budgets over time, even within one model version. Instead of building a system that depends on a model behaving predictably over time, our harness is built to absorb downstream volatility without breaking.
The first post covered what each agent/stage is for, so we'll talk about the parts it didn't: the glue between stages, and the handful of details that decide whether any of it works.
Table 1: Vulnerability Discovery Harness (VDH)
Stages four through eight run as a continuous producer-consumer loop. As the initial hunt progresses, the Gapfill, Feedback and Trace agents generate new tasks; Dedup folds overlapping findings back together and the rest of the loop keeps consuming the queue. This ensures a vulnerability discovered late in the cycle is still validated, reported and checked against other code to make sure it doesn't contain the same bug, all within the same run.
Splitting the pipeline this way guarantees strict context controls. If you fill the context window, the model starts hallucinating. We keep each agent’s job hyper-focused, keeping context usage below 25% of the total window. A naive “read all files” approach will blow past this limit every single time.
One thing that caught us out was that persistence needs to be factored in before parallelism. You do not want to throw away a five-hour run because of an unforeseen error. Every stage writes to one SQLite database keyed by (run_id, repo, stage). Any stage can resume, retry, or get pulled into a later run without redoing work. Findings are streamed and saved as they happen, so a crash costs you the task in flight and nothing else.
During the Recon stage, the agent writes the threat model instead of being handed one. Beyond about ten built-in attack classes (many forms of injection, memory corruption, protocol parsing, timing side channels, and others), the Recon agent can invent repo-specific classes on the spot, each with its own methodology. It writes a custom taxonomy tailored specifically to that codebase, which is used to more tightly scope the Hunter agents.
Reading source code isn’t enough to understand how it behaves under stress, especially for subtle undefined-behavior bugs in C and other lower-level languages. The Hunter agents move past code reading and transition into active execution. They compile fragments, build small versions, and attack them. The biggest jump in quality came from giving Hunters a sandbox (built on unshare) to crash binaries.
Beyond the core pipeline stages, we added two specialized mechanisms that grant the Hunters significant autonomy to adapt their focus and request external resources without derailing an ongoing analysis:
Sibling Forking: This helps ensure that if a Hunter agent trips over an interesting code path that is outside the current scope, it doesn’t wander off track. It uses a tool call to fork a sibling agent with a precise structural seed. Fleet-wide, this accounts for roughly 9% of tasks, though the rate is highly model-dependent — from near-zero to about a fifth, depending on which model is hunting.
The Wishlist: When an agent needs a tool it doesn't have, often a Validator confirming a Proof of Concept (PoC) or a Hunter wanting to build something (like a specific build environment, a VM, or some prod config files), it writes to a central wishlist. It provides enough context for the system to automatically re-run that exact task once a human provides the dependency. Some of these can be partly self-healing: if the container needs to be rebuilt with some changes, this can autonomously happen after the run by having a generic coding harness monitor the logs.
The wishlist has been written to 25,472 times across 128 repos since the wishlist was added, and it's the main way the agents talk back to us. One that landed while we were writing this: "I need a FreeBSD VM to confirm this PoC end-to-end."
After the initial cleanup, a Tracer agent checks how different software components are connected. It looks for a specific path: can a potential attacker send harmful input from the outside to a vulnerable part of the system? If the answer is yes, the Tracer agent automatically spawns fresh hunt tasks inside the consumer repository. To make this work, you need a unified, cross-repo symbol index and an accurate dependency graph. This allows you to uncover deep, systemic flaws that a standard single-repo scan would miss.
Running our harness across an entire fleet of repos revealed two lessons that only surfaced when this was done at scale.
First, deduplication is its own problem, big enough to need its own agents. When you are scanning a handful of repositories, you can manually eyeball overlapping bugs. Simple string matching or file-path checks won't save you here. Determining whether two complex logic flaws are actually the exact same root bug sounds trivial, but it isn't. It requires so much cognitive reasoning that we had to deploy dedicated Dedup agents just to clean up the noise, along with their own heuristics and ways of reducing the work.
The second is to not wire in static analysis early. We plumbed Semgrep all the way through, and the Hunters invoked it zero times in a month of runs. They would rather read and run the code. The wishlist, by contrast, was the single most-used tool in the system. It's worth paying attention to what the agents actually reach for, rather than what you think they'll want.
The agent will edit the source code so its own exploit works, then triumphantly report the bug it just created. It will write a test that proves something entirely tautological like “exec() executes things, therefore critical vulnerability”. Or it builds an exploit that runs fine but proves nothing, because the threat model behind it is nonsense. If your harness doesn't actively fight this, all you've built is a faster way to produce junk.
A Hunter has to state the threat model before it's allowed to file anything. It has to define exactly who the attacker is, and what boundary the vulnerability crosses or what assumption it breaks. The output schema ordering enforces it. This requirement eliminates the vacuous findings, the "if a user has database write access, they can write to the database" kind.
Every confirmed finding ships with a PoC written as a test that runs against the original, untouched codebase. This prevents the agent from editing the source files to force an exploit to land. If there is no working PoC, we treat the finding as fake. In practice, that's a Hunter compiling a thirty-line parsing loop, running it with memory protection enabled, and demonstrating that the incorrect read stride is originating from a stack address rather than the expected message body. You can re-run it yourself. Furthermore, every confirmed finding must also ship a proposed patch. What actually reaches our review queue is a verified bug, a working test, and a functional git diff, not just a vague text description of a problem.
Before an exploit path survives, deterministic code (written in plain code, not another model) mechanically verifies that the cited files and paths actually exist, and confirms that both the patch and the test parse correctly. This Validator cannot log findings of its own; its sole job is to aggressively disprove the Hunter's theory. If a Hunter is allowed to grade its own homework, it will confidently validate everything it outputs.
We don't claim a false-negative rate for our system. There's no labeled set of every real bug in a codebase, so any claimed recall number is entirely speculative. What we can watch is whether re-runs keep turning up new bugs (they do) and whether coverage is still growing across runs. It’s all a proxy, as you don’t know for sure how many bugs exist in a single codebase, but it’s a good-enough way of measuring effectiveness.
A finding coming out of the harness is just the start of the triage process, with all discoveries landing in a single, shared VVS that currently holds 13,841 findings across 145 repos in total. Triaging that volume is its own massive engineering problem, and it matters just as much as the hunting. That triage engine runs on a different model from the harness, broken down into three distinct jobs.
Table 2: Vulnerability Validation System (VVS)
Comparing every single finding against every other finding using an LLM scales at O(N^2), which falls apart completely at scale. To keep the model off the critical path, deterministic code builds inverted indexes over the structured data (touched files/functions, trust boundary, rare tokens) to generate a short list of real candidates. Only then does an agent look at that short list to see if a single fix would close several of them. Stable cross-run keys ensure re-found bugs reopen existing records rather than spawning new ones.
Judgment is a second, independent pass over what survived. The agent rechecks the latest information, pulling from deployment, environment, and config context to determine if the code path is reachable in prod, and identify the repo owner. This process filters "exploitable now" from "real but latent" and from "real but filed against the wrong component." It's moving a pile of chaotic findings into a risk-driven orchestration workflow.
The Fixer takes the proposed patch and unit tests, rewrites them to match the repo’s style, applies the diff, and runs targeted tests. A clean fail→pass flip is the ideal and the only auto-cleanup case; a failing post-patch test blocks the commit. The Fixer never merges code on its own; a human must review the branch. This gate is the non-negotiable, human-in-the-loop safeguard that enables a clean, unbreakable cryptographic trail for change management compliance. Left to patch freely, a model will happily fix a security bug while quietly breaking an unrelated feature or adding dozens of new bugs.
Across all three triage jobs, each agent is confined to one narrow task wrapped in deterministic bookkeeping code, and nothing writes to production without a human signing off on a dry run. While this pipeline moves the engineering bottleneck from finding bugs to reviewing and landing fixes, the Fixer remains the youngest and slowest part of the system.
Running hundreds of agents over a fleet of repos is not cheap, but at least the shape of the spend is predictable. Almost all of the compute budget goes directly into the hunt stage. This makes Gapfill our cost-to-coverage lever, as each additional pass costs roughly half as much as the initial hunt.
Because the cost per repository varies wildly, we budget per repo rather than per run. We enforce a strict task cap per repository and spin up a worker pool of anywhere from 50 to 200 workers. That way you can spend money on the repos that are actually finding things, and not waste it on the ones that aren't.
It's also why, for us, the big scans are a periodic backlog sweep and not a per-PR check. A full scan of a complex repo can take hours; the worst run took just over 14 hours. Cheaper, smaller harnesses are the right tool for that job.
We measure our system’s effectiveness by tracking how efficiently our automated pipeline filters deliberate engineering noise into high-quality, actionable findings. Because we intentionally tune our Hunters to over-report subtle primitives that could be chained into larger attacks, our true indicator of success is how sharply we can refine that initial mountain of raw data, before it ever reaches a human.
To gauge this, we track exactly how many raw findings survive each validation stage over time. Thanks to better context injection from our Recon phase, our initial validation rejection rate dropped from 40% down to 11%, while the share of high-integrity findings climbed from 35% to 58% (representing ~12,057 lifetime findings).
Here's the lifetime breakdown from raw candidates to actionable findings, at the point in time this blog post was written.
The core metric of the harness isn’t a speculative recall score — it’s keeping the number of unconfirmed findings in front of real humans as close to zero as possible. The architecture needs to be a relentless filtering funnel.
Traditional compliance rules dictate arbitrary remediation windows based entirely on a static CVSS score (e.g., "Fix all Highs in 30 days"). Our contextual judgment layer turns this compliance checkbox into actual risk management.
The architecture is capable of tracking findings back to their origin, meaning that fixing a single root cause resolves an entire cluster of findings rather than just patching individual issues. VDH system performance is also measured by dividing repos into (area x attack-class) cells and running the Gapfill agent iteratively until it stops producing findings. Whenever we update an underlying prompt, we test it against a held-out repository to see if that total coverage cell number actually moves.
The harness wires automated health signals to catch system failures early in the pipeline. If a hunt finished suspiciously fast and fails to spawn sub-hunts or gap tasks, it usually indicates a crashed dependency rather than a clean codebase. To remedy this, the system flags any Hunter agent that finishes with zero findings as “shallow” and immediately requeues it for a new run.
Finally, our system’s robustness is reinforced by the independent triage pass described earlier. By re-judging all submissions with a different model and separate logical weights, we ensure an unbiased, adversarial verification that is decoupled from the specific model used for discovery, providing a trust layer that persists regardless of which model is in use.
None of this is finished. We change our system constantly, and it is nowhere near a perfect science. But raw candidate findings are cheap now, and the only work worth doing is turning them into sound, verifiable code fixes.
Building your own harness means accepting that AI models are volatile, but your orchestration layer doesn't have to be. By decoupling your security logic from any single provider, forcing adversarial verification, and automating your triage pipeline, you can turn a mountain of LLM noise into a reliable, fleet-wide defense engine.
Every codebase is a little different, so to show you how this actually works in the real world, we mapped out a realistic benchmark based on a standard repo run. Keep in mind that this represents a single pass on one repo; over time, as the continuous fleet-wide loop deduplicates, filters, and recycles findings, it reduces the volume of lifetime candidates by roughly 65%.
Engineering hours saved via automated patching: Rather than focusing on static baselines, we measure the health of our pipeline by its technical throughput, processing velocity, and its ability to eliminate the manual triage bottleneck:
Shrinking mean-time-to-resolve for critical flaws: Of course, you can’t dump 80 patches into production all at once without breaking things. To keep deployments safe, our system uses a tiered rollout:
These findings are the result of an isolated, ring-fenced research experiment designed to stress-test our code. They do not represent active, unpatched vulnerabilities in our live production environment.
Because the harness runs constantly in our test environments, these specific numbers are completely out of date by the time you're reading this. Every single bug surfaced by the pipeline came attached to a working test case to demonstrate the bug and a draft patch. Our security teams are systematically processing the reports and applying the necessary fixes, meaning the Cloudflare products you use every day are already actively hardened against these vectors.
Along with this blog post, we’re releasing the initial skill we used to develop the harness, it’s been slightly cleaned up before release so it’s easier to understand and integrate, but the skill itself remains substantially the same. Hopefully the harness itself will follow shortly. This could be a starting point for your own vulnerability harness, your own skill, or whatever suits your needs best:
github.com/cloudflare/security-audit-skill
If your team is working on the same problems and would like to compare notes, reach out to us at security-ai-research@cloudflare.com.
The convergence of SRE and Security Engineering is reshaping how organizations build, operate, and protect modern cloud environments. As infrastructure grows more complex and distributed, reliability, security, identity management, and observability are becoming increasingly interconnected disciplines rather than separate functions.
Advait Patel, Senior Site Reliability Engineer at Broadcom and author of DockSec, has witnessed this shift firsthand. With experience spanning cloud infrastructure, DevSecOps, and observability platforms such as Wavefront (Tanzu Observability), he has worked on systems processing more than 10 million data points per second while leading initiatives in IAM, cloud migration, and security engineering.
In this interview, Patel shares his insights on securing observability platforms at scale, managing identity across multi-cloud environments, balancing automation with human oversight, and the role AI is playing in the future of DevSecOps and incident response.
From securing observability platforms handling millions of data points per second to managing identity across multi-cloud environments, Advait Patel's experience highlights the practical challenges facing today's infrastructure teams. His views on automation, AI, incident response, and container security reinforce a common theme throughout the discussion: the growing overlap between SRE and Security Engineering.
As organizations continue to modernize their cloud environments, the ability to balance reliability, security, and operational efficiency will become increasingly important. For teams navigating that shift, Patel's insights offer a grounded perspective on what it takes to build and secure systems at scale.
For the last few months, we've been testing a range of security-focused LLMs on our own infrastructure. These LLMs help identify potential vulnerabilities in our own systems, so we can fix them – and they also show us what attackers are going to be able to do with the latest models.
None of these LLMs has captured more attention than Mythos Preview, from Anthropic. A few weeks ago, we were invited to use Mythos Preview as part of Project Glasswing. We soon pointed it at more than fifty of our own repositories – to see what it would find, and to see how it works.
This post shares what we observed, what the models did well and what they didn't, and how the architecture and process around them needs to change, so they can be used at scale.
Mythos Preview is a real step forward, and it's worth saying that plainly before getting into anything else. We've been running models against our code for a while now, and the jump from what was possible with previous general-purpose frontier models to what Mythos Preview does today is not just a refinement of what came before.
It's a different kind of tool doing a different kind of work, and that makes a clean apples-to-apples comparison to earlier models difficult. So rather than trying to benchmark Mythos Preview against general-purpose frontier models, it's more useful to describe what it can actually do, and two features that stood out across the work we did with Mythos Preview:
Some of what we describe above is not entirely unique to Mythos Preview. When we ran other frontier models through the same harness, they found a fair number of the same underlying bugs, and in some cases they got further than we expected on the reasoning side too. Where they fell short was at the point of stitching the pieces together. A model would identify an interesting bug, write a thoughtful description of why it mattered, and then stop, leaving the actual chain unfinished and the question of exploitability open. What changed with Mythos Preview is that a model can now take those low-severity bugs (which would traditionally sit invisible in a backlog) and chain them into a single, more severe exploit.
The Mythos Preview model provided by Anthropic, as part of Project Glasswing, did not have the additional safeguards that are present in generally available models (like Opus 4.7 or GPT-5.5).
Despite this, the model organically pushes back on certain requests - much like the cyber capabilities that made it useful for vulnerability hunting, the model has its own emergent guardrails that sometimes cause it to push back on legitimate security research requests. But as we found, these organic refusals aren’t consistent - the same task, framed differently or presented in a different context, could produce completely different outcomes as illustrated in the examples below.
Example of Mythos Preview pushing back on building a working proof of concept
For example, the model initially refused to do vulnerability research on a project, then agreed to perform the same research on the same code after an unrelated change to the project’s environment. Nothing about the code being analyzed had changed.
In another case, the model found and confirmed several serious memory bugs in a codebase, and then refused to write a demonstration exploit. The same request, framed differently, got a different answer, and even the same request can produce different outcomes across runs due to the probabilistic nature of the model. Semantically equivalent tasks can produce opposite outcomes depending on how and when they’re presented to the model.
This matters because while the model’s organic refusals/guardrails are real, they aren’t consistent enough to serve as a complete safety boundary on their own. That’s precisely why any capable cyber frontier model made generally available in the future must include additional safeguards on top of this baseline behavior - making it appropriate for broader use outside of a controlled research context like Project Glasswing.
One of the hardest parts of triaging security vulnerabilities is deciding which bugs are real, which are exploitable, and which need fixing now. This was a hard problem even in the pre-AI world. AI vulnerability scanners and AI-generated code have made it worse, and at Cloudflare we've built multiple post-validation stages to deal with it.
Two factors dominate the noise rate:
Mythos Preview represents a clear improvement here, particularly in its ability to chain primitives - combining multiple vulnerabilities into a working proof of concept rather than reporting them in isolation. A finding that arrives with a PoC is a finding you can act on, and it means far less time spent asking "is this even real?"
Our harnesses are deliberately tuned to over-report, so we see more (and miss less), which comes with a lot more noise. But at triage time, Mythos Preview's output has noticeably higher quality: fewer hedged findings, clearer reproduction steps, and less work to reach a fix-or-dismiss decision.
When we first started AI-assisted vulnerability research last year, our instinct was the obvious one: point a generic coding agent at an arbitrary repository and ask it to discover vulnerabilities. This approach works, in the sense that the model will produce findings, but it doesn't work in producing meaningful coverage of a real codebase and identifying findings of value. There are two main reasons for this:
Four lessons came out of running the work at scale, and each one pointed to the need for a harness that manages the overall execution:
Each of those observations is about model behavior, and put together they describe something that isn't a chat interface anymore. It's a harness that helps you achieve the final outcomes. The first steps to building a harness are simple, as you can ask the model to help, which is what we did. We used Mythos Preview to build on, tailor, and improve our original harnesses to suit its strengths.
An example of what a harness looks like in practice is described below.
Here's what our vulnerability discovery harness looks like, stage by stage. It was used to scan live code across our runtime, edge data path, protocol stack, control plane, and the open-source projects we depend on.
The loudest reaction to Mythos Preview from other security leaders has been about speed - scan faster, patch faster, compress the response cycle. More than one team we have spoken with is now operating under a two-hour SLA from CVE release to patch in production. The instinct is understandable: when the attacker timeline shortens, the defender timeline has to shorten with it. Faster is not going to be enough, and we think a lot of teams are about to spend a lot of time, effort, and money learning that the hard way.
Patching faster does not change the shape of the pipeline that produces the patch. If regression testing takes a day, you cannot get to a two-hour SLA without skipping it, and the bugs you ship when you skip regression testing tend to be worse than the bugs you were trying to patch. We learned a version of this when we tried letting the model write its own patches and watched a few go out that fixed the original bug while quietly breaking something else the code depended on.
The harder question is what the architecture around the vulnerability should look like. The principle is to make exploitation harder for an attacker even when a bug exists, so that the gap between when a vulnerability is disclosed and when it is patched matters less. That means defenses that sit in front of the application and block the bug from being reached. It means designing the application so that a flaw in one part of the code cannot give an attacker access to other parts. It means being able to roll out a fix to every place the code is running at the same moment, rather than waiting on individual teams to deploy it.
We also recognize this topic cuts both ways. The same capabilities that helped us find bugs in our own code will, in the wrong hands, accelerate the attack side against every application on the Internet. Cloudflare sits in front of millions of those applications, and the architectural principles described above are exactly the ones our products are built to apply on behalf of customers. We will share more on what that means for customers in the weeks ahead.
If your team is doing similar work and would like to compare notes, reach out to us at security-ai-research@cloudflare.com.
Our research with Mythos Preview was conducted in a controlled environment against our own code; every vulnerability surfaced through this work was triaged, validated, and remediated where action was needed under Cloudflare's formal vulnerability management process.
This work was a team effort. Thanks to Albert Pedersen, Craig Strubhart, Dan Jones, Irtefa Fairuz, Martin Schwarzl, and Rohit Chenna Reddy for their contributions to the research, engineering, and analysis behind this blog post.
China-sponsored threat groups like Salt Typhoon and Flax Typhoon are increasingly relying on multiple massive botnets comprising edge and IoT devices to run their cyber espionage and network intrusion campaigns, CISA and other security agencies say. The use of such "covert networks" makes it more difficult to detect and mitigate their campaigns.
The post China-Backed Groups are Using Massive Botnets in Espionage, Intrusion Campaigns appeared first on Security Boulevard.
Discover the 9 most dangerous identity-based threats in 2026, from AI phishing attacks and deepfake authentication bypass to MFA fatigue and harvest-now-decrypt-later quantum threats. Learn why legacy authentication fails against each one and how phishing-resistant, passwordless authentication changes the equation.
The post 9 Identity-Based Threats Redefining Cybersecurity in 2026 (Beyond Credential Stuffing) appeared first on Security Boulevard.
Scammers dressed up like Catholic Charities and legitimate pro bone legal services on social media platforms are targeting immigrants and bilking them for money. Manhattan DA Alvin Bragg is pressing Meta to follow its own terms and shut them down.
The post Manhattan DA Bragg Pushes Meta to Put a Stop to Immigration Scams appeared first on Security Boulevard.
