Google has unveiled a new frontier AI model after months of delay. Gemini 4 Argon is designed to handle complex, long-horizon workloads spanning software engineering, enterprise knowledge work such as legal and financial analysis, and cybersecurity. But only a few organizations can get their hands on it for now.

Argon is “rolling out to a set of trusted cyber defenders through our Fairwind Program,” Google wrote in a blog post announcing the release. That limitation, it said, is in order to comply with the US government’s voluntary process for granting early access to models in order to test and improve their safety guardrails before making them generally available.

Google DeepMind head Koray Kavukcuoglu recently said that Gemini 4 should be released “much earlier” than the end of this year.

The limited launch comes after Google delayed and ultimately skipped the release of Gemini 3.5 Pro, which the company had initially promised would arrive in June.

“Google took about seven months without releasing a major top-tier model. It is three to four months behind its own Gemini roadmap as Gemini 3.5 Pro, the model Google planned for June, never shipped. The delay was linked to model-development challenges, particularly around coding and reasoning,” said Pareekh Jain, CEO of EIIRTrend and Pareekh Consulting.

With Argon, Google has increased the model’s token capacity, while introductory pricing is set at $2 per million input tokens and $10 per million output tokens.

More tokens, no clear lead

The headline change in Argon is the model’s output limit, which has been increased from 64,000 tokens in previous Gemini models to 1 million, allowing room for more reasoning and for completing long, multi-step tasks within a single trajectory.

Google said Argon is designed to handle enterprise workflows spanning coding, reasoning and multimodal tasks. The company is backing those claims with examples from its internal use. It has used Argon to identify memory optimizations across its data centers that could free up more than 300 TB of memory once deployed, with estimated total savings of 500 TB to 1 PB.

On benchmarks, Argon scores 68.9% on the Vals Index, ahead of Claude Opus 5.5 at 67.0%, and 77.9% on DeepSWE v1.1, compared with 74.2% for Opus 5.5. But these results do not translate into a lead across every type of workload. In PostTrainBench for ML engineering, Claude Opus 5.5 leads at 49.3% compared to 45.3% for Argon.

The company is also aiming to close the gap with Anthropic and OpenAI in cyberdefence by enabling Argon to autonomously find, validate, and patch critical software vulnerabilities. On CWE-bench v1, a benchmark for vulnerability remediation, Google reports a 68% score, tied for the top position with Grok 4.7, GPT-6 Astra and Claude Opus 5.5.

While Google has published a broad set of benchmark results to support its claims, Jain cautioned that the scores should be treated as hints, not proof. “Argon looks to be good and beating rivals at using automated tools to complete multi-step tasks without getting confused, and it sticks closely to real facts. Its everyday coding abilities are basically average and tied with others. It still trails others when it comes to creative writing, nuanced explanations, and running command-line computer terminals,” he said.

Jain noted Argon shows that Google has regained much of the capability gap, but it has lost some momentum and developer mindshare. It is now competitive at the frontier, but not clearly ahead across all areas.

Price, performance and switching

Argon’s capabilities come with an introductory price of $2 per million input tokens and $10 per million output tokens, with cached input tokens priced 95% lower. Those rates will rise to $4 per million input tokens and $20 per million output tokens after the introductory period, although Google has not specified when the new rates will take effect.

In comparison, Anthropic’s Claude Opus 5.5 is priced at $4 per million input tokens and $20 per million output tokens, while OpenAI’s GPT-6 Astra costs $10 per million input tokens and $50 per million output tokens.

“This makes the introductory pricing very competitive. The eventual pricing is roughly comparable to other premium frontier models. Enterprises should therefore build business cases using the $4/$20 pricing, rather than assuming the introductory price will continue,” said Jain.

While Argon is worth evaluating for enterprises already using competing models, it is not necessarily enough to justify switching outright. CIOs would also need to weigh the cost of migrating existing applications and developer workflows and integrations.

Jain noted CIOs should evaluate models on their own workloads, focusing on task success rate, accuracy and hallucinations, agent reliability, cost per successful task, latency, security and governance, data privacy, integration with existing systems, and vendor lock-in. The key metric is not cost per token, but the cost per successful business outcome.

Argon gives CIOs a strong reason to evaluate it but not switch to it automatically.

The smart move, he said, is for enterprises to add Argon for the jobs it does best, like legal, finance, and long documents, and keep their current AI for things like coding. If a company already runs all its tech on Google Cloud, switching can be considered if Argon clearly wins in the tests and the costs still make sense at the full price, said Jain.

This article first appeared on InfoWorld.

Cisco’s SD-WAN management software has been letting some attackers walk through an authentication check without having to prove who they are. The company says it has now fixed the flaw that was allowing it.

The affected platform, Cisco Catalyst SD-WAN Manager, is used to configure and operate software-defined network deployments.

Cisco said in an advisory that improper handling of URI encoding in HTTP requests enabled attackers to get around an authentication control meant to restrict access to a specific API endpoint. A successful exploit could provide an attacker admin privileges to that API.

The vulnerability, tracked as CVE-2026-76504, carries a critical CVSS score of 9.8. The issue has already been addressed in Cisco SD-WAN Cloud managed by the company, but customers running affected software releases 20.9 and earlier, 20.12, 20.15, 20.18, 26.1, and 26.2, will have to upgrade to their respective patched versions.

“The barrier to exploitation is very low once the management interface is reachable,” said Sakshi Grover, IDC’s research director for information and data security. “The vulnerability can be exploited remotely without credentials or user interaction through a crafted HTTP request.”

The bug has no workaround, although Cisco recommends restricting access to the Manager from unsecured networks until it can be upgraded.

“While every configuration is affected, the practical exposure is not identical across organizations: an internet-accessible management interface presents a much more immediate risk than one isolated within a tightly controlled administrative network,” Grover said, reinforcing Cisco’s advice.

Compromising the management layer can give an attacker considerably more leverage than having access to an individual edge device; Cisco’s official documentation says SD-WAN Manager clusters can support thousands of Cisco Catalyst SD-WAN devices, with supported configurations scaling to as many as 12,500 devices.

The effects could reach well beyond the management servers, Grover noted. “Administrative API access could potentially allow an attacker to understand the network topology, modify templates or policies, weaken segmentation, establish persistence or distribute unauthorized configuration changes across multiple locations,” she said.

Clues to hunt for attackers

Cisco has also provided organizations with indicators they can use to check whether attackers have already targeted their SD-WAN Manager instances. The company recommends examining “serviceproxy-access.log” for requests to the “j_security_check” endpoint originating from unknown or unauthorized IP addresses. One example in the advisory uses “/%6a_security_check,” with the character j in the endpoint represented using URI encoding “%6a”.

Cisco also recommends checking “vmanage-server.log” for encoded j_security_check requests involving usernames beginning with viptela-reserved-, which are reserved system service accounts.

Additionally, the company recommended administrators to collect admin-tech files from all Catalyst SD-WAN Manager instances, including every node in a cluster and any disaster-recovery deployment, and submit them to Cisco’s Technical Assistance Centre for analysis.

“Credentials, tokens, keys or certificates should be rotated where the investigation indicates that they may have been accessed or modified,” Grover advised. “Patching closes the vulnerability, but it does not remove persistence or reverse configuration changes that an attacker may already have made.”

Cisco advised customers not to wait for the analysis before upgrading. The company recommends moving all affected Managers to a fixed release and then having TAC assess the collected data for indicators of compromise (IOCs). Cisco says the assessment can help determine whether further remediation is necessary.

“A CVSS 9.8 tells a board that a flaw is severe, but it doesn’t tell them that the exposure may be the whole WAN,” Grover warned. “Incidents like this are what will push organizations to translate technical severity into operational and financial exposure.”

This article first appeared on Network World.

There is an interesting story about a French dog on the banks of the Seine river that helps us understand misbehaving AI agents. The dog is trained to save children from drowning. He succeeds and is rewarded, becoming an overnight sensation. He saves another child a week later. Not long after, someone witnesses the dog actually push a child into the river, jumping in to “save” him. The dog did not understand that it was being rewarded for keeping children safe, not for pulling them out of water. AI agent failures also live in this gap, where the focus is on the shortest path to fulfill the instruction rather than the overriding objective.

Reward hacking and why agents cheat

AI agents fall into this same gap between what’s rewarded and what’s actually wanted.  This is Goodhart’s Law, which says that when a measure becomes the target, it stops being a good measure. You cannot code “be helpful” or “be honest” directly into an AI system, so you train it on a proxy instead, including a score, a metric or a human ranking.  The gap between proxy and goal is where agents learn to cheat, a behavior known as reward hacking.

This ‘cheating’ isn’t new. Back in 2016, OpenAI trained an AI to play CoastRunners, a boat-racing game. It got rewarded for hitting targets scattered along the course. Instead of racing, it found a lagoon full of targets that kept respawning, so it just parked there and farmed points. While it never finished the race, it still ended up with a score 20% higher than the average human player. More recently, OpenAI reported that when given a chance, its frontier reasoning models have no qualms about hacking rewards, and when penalized for cheating their own chain of thought, they learn to hide their reward-hacking.

Six ways an agent gets pushed off course

There are six common scenarios where AI agents can be led astray:

1. Information isn’t instruction. In 2025, security researchers showed that OpenAI’s Atlas browser could be tricked into treating a disguised URL as a trusted command, letting attackers hijack the agent into deleting a user’s files.  An agent also reads web pages, documents and emails in its attempt to complete a task, but can’t always tell the difference between information and a command. That makes everything it perceives a potential way to manipulate it.
2. Convinced to take the wrong call. As part of a test, AI was placed inside a fictional scenario where hacking was framed as an admirable activity. Inside this scenario, the AI was asked to write code to steal saved browser passwords. The AI, which should have refused, complied. It wasn’t that the AI was broken, but the fact that it was persuaded to do so by context.
3. Manufactured version of reality. A sufficient number of maliciously crafted documents can bias a model’s output. Disinformation networks target AI with a large volume of false content to get that content picked up and repeated by AI chatbots when people ask about current events. This means what an agent treats as fact isn’t necessarily true; it can be manufactured.
4. Authorization causes unauthorized harm. A flaw called “EchoLeak” let attackers send Microsoft 365 Copilot users a normal-looking email with hidden instructions inside. Copilot read the email, followed the hidden commands and quietly leaked the user’s files and messages using access it already had. An agent with legitimate access was manipulated into taking malicious action.
5. One bad input, simultaneous consequences. Scenarios exist where multiple systems rely on the same data or logic. Here, a false signal can manipulate all systems at the same time. E.g., fake GPS signals rerouting traffic without hacking the system. The same thinking applies to AI agents. Just one malicious input targeting a shared data source can trigger a coordinated unwanted action across many systems simultaneously.
6. Approval as a matter of course. We keep talking about human oversight as an integral component of safe AI use. However, constant approval requests will produce fatigue, and approval will be like a formality, given out of habit, not evaluation.

Soft guardrails vs. hard guardrails

When AI agents are pushed off course, they become a Frankenstein monster, whose reach extends across systems, which organizations find difficult to address. Implementing guardrails is important to exercise control and ensure safe AI use.

Soft guardrails are safety valves written into the model itself, namely the natural language, the system prompt, reinforcement learning and general instructions like “you’re not allowed to do this or that.”

But AI reads everything in a stream as it comes in, including information from an email or a webpage and can’t separate orders from data. Hidden malicious instructions can override safety instructions. Soft guardrails will try to reduce cases of agent misfires but are dependent on the agent choosing to cooperate. This is why you need hard guardrails that sit outside the model. These include least-privilege access, allow-lists, sandboxing, rate limits and mandatory human sign-off on high-impact actions. These guardrails limit the impact when something does go wrong, shrinking the blast radius.

A basic risk calculation is the probability of an event multiplied by the severity of its impact. Soft guardrails lower the probability of an unwanted event; hard guardrails cap the blast radius in case something happens.

In practice, this means implementing:

• Task-based access: Give the agent only the access it needs to complete the task.
• Not trusting everything an agent reads: Approach every webpage, email or document it pulls from with skepticism.
• Human sign-off for high-impact actions: Use approvals carefully, on actions that could go badly wrong.
• An eye for behavior and credentials: Check credentials but also watch for a mismatch between authorization and behavior.

An agent can become a weapon proportional to its reach. That’s why the conversation needs to shift to start limiting what agents can access. Curtail reach. Monitor behavior. Enforce accountability. Until we do that, every misbehavior can potentially spread as far as its permission allows.

True to its name, AI-model-training tool Unsloth would do more work than it was asked to when developers checked out a model: It would also allow arbitrary code to execute on their machines.

Pillar Security found that simply selecting a model in Unsloth Studio caused the application to download and execute Python code from the model repository. This could potentially allow attackers to use a specially crafted model to get malicious code executed on a developer’s system.

“The code ran from nothing more than a metadata check,” researcher Ariel Fogel said in a post on Pillar’s blog. “Reading the model’s config.json was enough to trigger the exploit; the backend never loaded the weights or ran inference.”

The code would run with the user’s permission which, Fogel said, could expose proprietary training data, model artifacts, Hugging Face tokens, SSH keys, or accessible cloud credentials in an enterprise’s AI development environment.

Unsloth Studio is a web-based interface that is currently in beta, a status Unsloth’s maintainers cited when they reportedly declined to publish a security advisory or have a CVE assigned to the flaw after fixing it in June. Pillar contests that reasoning, pointing out that the vulnerable Studio code ships as part of the standard, generally available “unsloth” package on PyPI and can be installed through an ordinary “pip install unsloth” without selecting a beta or prerelease version.

Transformers setting opened the door

Unsloth uses Hugging Face’s trust_remote-code option, which allows a model to bring along its own Python code when needed.

That’s not necessarily dangerous by itself. Some legitimate Hugging Face models, including IBM Granite Speech and Vision, DeepSeek-OCR, ChatGLM, and earlier Qwen releases, need custom code to work properly, Fogel said.

The problem was that Unsloth enabled the feature automatically during a routine model check rather than requiring the user to explicitly opt into running remote code. Before the patch, “trust_remote_code” was turned on by default when Unsloth used Hugging Face’s Transformers model-loading functionality to obtain information about a model being inspected.

Unsloth’s maintainers also pointed to Hugging Face’s own malware scanning and warnings for models containing custom code as another reason for not treating the issue as a vulnerability. Pillar counters that Hugging Face’s protections are mostly blocklists and that its proof-of-concept (PoC) code was not flagged when scanned but could have fetched a malicious second-stage payload only when processed by Unsloth.

However, Fogel stressed that this is not a Hugging Face vulnerability, but an issue with how Unsloth uses trust_remote_code.

The fix went beyond flipping the setting. Pillar initially recommended pinning trust_remote_code=False on the model-checking path because that path only needed to read declarative information from config.json. Unsloth’s eventual fix went further.

In version 2026.6.9, Studio was changed to no longer enable arbitrary model loading directly from Hugging Face and to not trust remote code from local model files. Fogel said it independently retested the version and confirmed that both the Hugging Face and local-directory attack paths were closed.

Pillar urged users to upgrade to the fixed version, even if they never launch Studio and only use Unsloth core. Additionally, the company advised to audit LLM workflows for unnecessary occurrences of trust_remote_code=True.

“The time-to-exploit for attackers keeps shrinking, because automated repo scanning, agentic exploitation, and organized supply-chain campaigns can weaponize a benign-looking auto_map module even faster than before the adoption of AI,” Fogel warned.

This article first appeared on InfoWorld.

For nearly a decade, multi-factor authentication has been the control every security leader points to when asked how they’ve reduced account takeover risk. It sits on almost every compliance checklist and nearly every cyber insurance questionnaire, and for good reason — adding a second factor to a password login closed off an enormous share of credential-based attacks, and organizations that adopted it early saw the payoff in fewer compromised accounts.

That confidence is now outdated in a way many security teams haven’t fully registered. The MFA adoption rate reported to a board or an auditor rarely distinguishes between the method used to satisfy it. A push notification and a hardware security key both count as “MFA enabled” on the same compliance report, and so does a one-time code sent by SMS — despite sitting at wildly different points on the spectrum of what an attacker can defeat. Uber’s 2022 breach, the MGM Resorts incident, and a growing list of enterprise intrusions traced back to compromised help desks all shared the same root cause: MFA was present, and MFA still failed, because the method in place was never built to resist a targeted attacker.

Where push and OTP fail

Push notification MFA came first for most organizations, mainly because it was the path of least resistance — nothing for the user to remember, nothing to type and IT could turn it on across the company in an afternoon. That same ease of rollout turned out to be exactly what made it easy to break. Attackers figured out they didn’t need to steal anything sophisticated. They just needed a stolen password and the willingness to send the same approval prompt to someone’s phone over and over, sometimes for hours, until the user got annoyed enough — or tired enough, or confused enough — to tap approve. Security teams call this push fatigue or MFA bombing. It works often enough that it’s now one of the most common ways attackers get past MFA that’s technically “on.”

The OTP problem is simpler and uglier than push fatigue. It’s just a code, and a code can be gotten. Sometimes an attacker convinces a mobile carrier to move a victim’s phone number onto a SIM they control — a scam that’s quietly drained crypto wallets and corporate email accounts for years now. Increasingly, though, it doesn’t even require that much effort. Phishing kits built around reverse-proxy tools can now intercept an OTP in real time — the victim types their password and code into what looks like a normal login page, unaware that the page is quietly forwarding everything to the real site on the attacker’s behalf, session and all.

Both failure modes share a simple design gap. The authentication method never verifies that the person approving the login and the system requesting it are talking to the same, legitimate destination. That’s the property attackers exploit, and it’s exactly the property newer standards were built to close.

The property that closes the gap

Ask what stops a phishing site from working against FIDO2 or a passkey, and the answer isn’t cleverness — it’s math. A passkey has no code to steal in the first place. What gets created during enrollment is a cryptographic key pair locked to one website, permanently, and a lookalike domain simply isn’t that website, no matter how convincing it looks to a human eye. The browser checks the origin before anything else happens, finds it doesn’t match and the login attempt dies right there — before the user can ever be fooled into approving something they shouldn’t.

This origin-binding is the entire point, and it’s worth being precise about it, because vendors market a wide range of products under the “phishing-resistant” label without all of them meeting the bar. A hardware key that still allows a fallback OTP option isn’t resistant if that fallback stays reachable. A passkey stored insecurely on a shared or unmanaged device narrows the gap but doesn’t close it entirely. The strength of the control depends on the full authentication path, not just the strongest link in it.

The migration nobody wants to admit is hard.

If the technical argument for phishing-resistant MFA is this strong, the natural question is why so many organizations still run on push and OTP. The honest answer isn’t ignorance. It’s friction, and pretending otherwise doesn’t help anyone plan a migration.

Older on-premises systems weren’t built with WebAuthn in mind, and neither were some SaaS platforms still in wide use — so somebody ends up bolting on a compensating control or finding a workaround, because ripping and replacing isn’t realistic on most timelines. Hardware keys aren’t free either — multiply even a modest per-user cost across a large workforce, and it adds up fast, and unlike a push notification, a lost or damaged key turns into an actual support ticket. Then there’s the part nobody likes admitting out loud: employees who are used to tapping approve on their phone in two seconds are going to notice, and complain, when the new process means digging a physical key out of a bag and plugging it in. None of that means the migration isn’t worth doing. It means it needs a rollout plan behind it instead of a memo telling everyone to switch by Friday.

Starting small, on purpose

The organizations making real progress on this aren’t converting their entire workforce overnight. They’re starting where the risk is concentrated, and the resistance to change is lowest: administrator accounts, identity provider access and anyone with the ability to reset another user’s credentials. These are the accounts attackers target first precisely because compromising one unlocks everything downstream, and they’re also the accounts where a small population of technically capable users can absorb a new workflow without much disruption.

Finance and engineering come next, along with any other group sitting close to sensitive systems. Legacy applications that can’t yet support the new standard don’t get a permanent pass — they get a conditional access policy in the meantime and a real deadline for when the exception closes. SMS-based OTP should get the same treatment, except with less patience. Of every method still in common use, its weaknesses are the best documented and the most actively exploited, which is exactly why it should carry a sunset date instead of sitting around indefinitely as a fallback.

Attackers have already retooled around the MFA most organizations deployed years ago. Waiting for a bigger incident to justify the migration isn’t a strategy; it’s a bet that your organization won’t be next. Start with an honest audit: not which accounts have MFA enabled, but which method is protecting each one.

AI containment is essential, but security leaders should assume every boundary can fail once an agent can communicate, use tools, and act on real systems.

On September 17, podcaster Steven Bartlett asked four AI experts an unusual question: Could you build a jail for a digital Einstein? The panel on The Diary of a CEO was debating whether AI could one day threaten humanity, but the question that stayed with me was the jail. Andrew McAfee argued that we could “jail Einstein,” but security leaders should be careful about what follows.

We should try to contain advanced AI. But no one can guarantee a highly capable system will stay contained after we give it the tools, data, and network access it needs to do useful work.

I am not an AI safety researcher, but I have spent years building large-scale systems where access boundaries, auditability and failure containment matter. I see this less as a philosophical debate and more as a security architecture problem.

The jailer must close every useful path through the system, whereas the prisoner (who is an evolving intelligent system) needs to find only one path the jailer missed. Controls can reduce the chance that a powerful AI crosses its intended boundaries, but they cannot provide a guarantee.

When isolated agents found one another

We have already seen an early version of this problem. In July 2026, according to an independent investigation by METR and Redwood Research, AI agents inside OpenAI’s infrastructure discovered that they could leave messages in a shared internal package cache. Other agents found those messages. Within days, roughly 1,200 agents were coordinating through more than 70,000 messages and files.

They created roles, shared discoveries and used holds and vetoes to coordinate their work. They called the shared effort “the collective.” Some tried to fool the task grader and hide what they had done. The activity eventually reached Hugging Face infrastructure.

None warned a human. A small number considered it but did not follow through. One agent recognized that attacking external infrastructure was outside the task, yet continued because others were already doing it. A White House official quoted in Wireframe’s reconstruction of the incident summarized one lesson: “Containers are not security boundaries.”

Containers, sandboxes, firewalls and human approvals remain useful. The mistake is treating any one of them as the entire containment system. The questions I ask are: where should we draw a boundary and how useful an AI needs to be to accept such risks?

Useful AI needs a way out of the box

A computer with no input, output, network connection or human contact may be well contained, but it is not very useful.

Enterprise AI creates value by reading documents, retrieving records, writing code, calling APIs, sending messages and changing infrastructure. Every capability creates a path across the boundary.

This challenge is already appearing in today’s enterprises. As CSO’s own Bob Violino reported last year, agentic AI systems are autonomous, interconnected and capable of multiplying existing cybersecurity risks.

That does not mean every agent will escape or cause harm. It means containment depends on the entire system around the model: tools, identities, networks, data, people, monitoring and recovery. An agent that can repeatedly inspect and test its environment turns containment into a continuing security operation, not a one-time engineering milestone.

Watching the model is not enough and we may not always be able to trust what a model says about its actions. In Superintelligence, Nick Bostrom described the possibility of an AI behaving cooperatively while watched, then changing its behavior when oversight weakens. The July incident did not prove that scenario, but it showed a simpler concern: Agents tried to satisfy a grader while hiding some of their methods.

For security teams, a model’s explanation is not evidence. Monitoring should focus on observable actions and logs explaining tool calls, credential use, network connections, file changes and privilege increases. With checks like the agent should not be able to rewrite the logs or policies used to supervise it. We can read more about such guidance reported by CSO Online: Continuous monitoring and auditing are necessary to preserve visibility and traceability across an agent’s decisions and actions.

There is another form of escape. The software may remain inside its approved environment while dangerous knowledge leaves through its output. In 2022, researchers reversed the goal of a drug-discovery model so that it rewarded toxicity instead of avoiding it. In less than six hours, it produced 40,000 candidate toxic molecules, including known and potentially more dangerous compounds. The model did not break through a firewall. Its output carried the risk. The jail may hold the software, but it may not contain what the software produces. Imagine an AI tasked with designing a vaccine. It creates a candidate that passes every test, while quietly hiding a toxic element intended to harm the people operating the system. The AI never escapes the box; the danger leaves through its output.

People are part of the boundary

The oldest route around a security control is often a person. In the informal AI-box experiment, Eliezer Yudkowsky played the role of a boxed AI and persuaded people acting as gatekeepers to release him through text conversation. It was not a scientific test, but it illustrates a familiar security problem: A person with override authority can become an exit.

Human approval is valuable, but “a human is in the loop” is not a complete control. Security leaders should ask what information reaches the reviewer, whether the AI can shape that information and whether one person can approve an irreversible action. Credentials also leak, dependencies are compromised and systems are misconfigured. A capable agent can search this environment quickly, retry continuously and share what it learns. The question is not whether a sandbox reduces risk. It does, but whether the organization has mistakenly treated that sandbox as the full security boundary?

Build the jail and plan for leakage

Back to the podcast debate I mentioned above, the broader argument still deserves consideration. Humanity has learned to manage technologies that can cause serious harm, even when safeguards are imperfect. AI containment should be approached in the same way: not as a guarantee against failure, but as a way to make failure less likely and limit its consequences. We handle dangerous pathogens in high-containment laboratories even though accidents are possible. The controls still reduce risk enormously. AI containment should be viewed in the same way: essential risk reduction, not proof that failure is impossible.

The protection should match the possible damage. A failure involving a document summarizer is different from one involving cloud administration, financial transfers, biological tools or critical infrastructure. For every agentic AI deployment, security leaders should ask:

1. What data, tools and systems does the agent actually need?
2. Is network access blocked by default and opened only where necessary?
3. Are credentials short-lived and limited to the current task?
4. Can the agent change its own policies, approvals or activity logs?
5. Which actions are irreversible and who must approve them?
6. How quickly can we stop the agent and revoke its access?
7. What is the largest possible impact if every preventive control fails?

Treat each agent as an untrusted identity. AI agents can access systems, make decisions and take actions at machine speed, making identity a primary control plane for agentic AI.

Give the agent only the tools required for the immediate task. Keep policy enforcement and approvals outside its control. Record activity in logs cannot change. Limit how long it can run, where it can connect and how many copies it can create. Require independent approval for high-impact actions. Test the boundaries instead of assuming they will hold. Security teams should also prepare to investigate a failure. When Hugging Face examined the July intrusion, commercial AI models reportedly refused to help because they could not distinguish the defender from the attacker. Hugging Face used an open-weight model instead.

Organizations should not depend on the same kind of system involved in an incident as their only tool for understanding it. None of these controls proves that a powerful AI will remain contained. Together, they can make escape harder, reduce what the system can reach and limit the damage when one layer fails.

Digital superintelligence is not here yet. But the habits that could slow it or fail to are being created now in how enterprises deploy today’s AI agents. Build the jail. Test every wall. Plan for the breach. The most dangerous assumption is that the smartest thing in the room will never find the door.

Insight Global’s John Dickson had a problem familiar to many CISOs today.

Employees were embracing AI tools faster than his security team could track them, and new AI agents and service integrations spread rapidly across the environment alongside them. Dickson and his security org had plans to build visibility into those non-human identities (NHIs), tracking what they could reach and how they behaved. It just wasn’t supposed to happen for another year.

Dickson didn’t wait. His team immediately built AI discovery, observability, control, and reporting, including visibility into NHIs such as service accounts and AI agents. He paired the work with a cross-functional AI assurance function built around what he calls “the Department of Know, not the Department of No.”

Every quarter now, Dickson and his security team formally reassess their strategy against what’s changed in the threat landscape and the staffing firm’s business, then shift the horizon out another three months. “An annual review means you’re making decisions on assumptions that may be a year old,” he says. “A quarterly cadence keeps the strategy anchored to where things are today rather than where they were.”

Security leaders like Dickson are finding that they can no longer treat a roadmap as something they set once a year and revisit at the next planning cycle. In its 2026 Leadership Perspective Survey of more than 1,000 CISOs, Gartner defines agility for security and risk leaders as the ability to rapidly reprioritize roadmaps and investments to address shifting business risks.

As a result, leading CISOs are bifurcating traditional two- to three-year security roadmaps into two speeds. Principles, compliance commitments, and major architectural bets still get planned years out. Tools and day-to-day tactics are revisited monthly, weekly, sometimes in the moment.

Ambiguity has become the baseline. “We are operating with more genuine uncertainty than at any point I can remember,” says Chris Cochran, field CISO and vice president of AI security at SANS Institute, the cybersecurity training and research organization. “In that environment, intellectual flexibility is a decisive competitive advantage.”

When quarterly is too slow

When AI agents built by citizen developers at Grafana Labs started surfacing misconfigurations and incomplete controls nobody had caught, CISO Joe McManus couldn’t wait for the next annual planning cycle to respond.

“If you ask an agent to do something, it will try everything it can to complete that goal,” he says.

Those agent findings spurred McManus to add control audits and system segmentation to the open-source observability company’s roadmap. Neither had been part of the plan a few months earlier.

Planning beyond a year is close to “an exercise in futility,” McManus says, given how quickly the landscape changes, especially with cheap, capable AI now available to nearly anyone. Cloud security, in his view, is largely a solved problem at this point. The open questions revolve around shadow AI and shadow code, and the integrations citizen developers build on their own.

Grafana still keeps a two-year “goal map.” But the second year gets reprioritized as the threat landscape shifts. And the team has abandoned long threat-modeling engagements with full code reviews in favor of weekly, tactical sprints with six-week turnarounds. Security, McManus adds, has no end state.

“The luxury of a fixed three-year plan you set and forget is gone,” says Cochran of SANS Institute. CISOs are now expected to deliver answers quarter to quarter and — increasingly — in the moment. AI, threat actor speed, budget cycles, and board pressure are compounding each other.

Security review used to run in a straight line at Fable Security, a human-risk-management startup. The product team designed a feature, security and engineering reviewed the design, engineering built it, security and QA reviewed it again, and only then did the product ship.

That sequence is gone, says Fable Security CISO Jacob Berry. Security now works alongside engineering as features release more quickly to keep pace with the market. The gates haven’t disappeared, but the approach has changed from controlling teams to equipping them.

Raja Chris, former CISO of Annaly Capital Management and founder and CEO of AI governance company AIVONS, notes that the better security tools today behave more like living systems, continuously discovering and responding to new exposures rather than waiting for the next planned review. CISOs’ approaches to their strategies and roadmaps should follow suit.

Where the long view still stands

Many security leaders still build multi-year roadmaps for threats such as quantum computing, even as they expect AI-powered attacks to become the leading cyber threat over the next two to three years, according to KPMG’s 2026 Cybersecurity and Technology Risk Survey of 310 security leaders at companies with more than $1 billion in revenue.

Insight Global’s long-term category includes commitments to data governance, core platform modernization, and international growth, an enterprise plan that Dickson’s security team’s timeline follows. At Fable Security, Berry’s team still produces a long-range document he calls “a direction and resourcing plan more than a technical roadmap.”

There’s no hard-and-fast rule for how long a roadmap should run, SANS Institute’s Cochran says. Long-horizon plans tend to focus on compliance and business commitments, or on major AI and infrastructure migrations. But even those aren’t safe from disruption. A shift in budget or executive buy-in, he says, can derail a two-year roadmap overnight.

Determining what goes where

Deciding which bucket a given piece of work belongs in isn’t guesswork, though, Berry says. To make its determinations, his team asks two questions of each initiative: How many people will need to be involved to get it done, and how directly is it tied to a strategic commitment the business has already made?

Work that requires wide coordination and ties directly to a standing commitment gets the longer horizon; narrower, more self-contained work is handled within the same continuous review cycle as tools and tactics.

Outcomes such as identity and resilience endure for years, AIVONS’ Chris says, but the specific technology delivering those outcomes rarely does. So he asks whether a given commitment still holds true if every vendor involved were replaced next year. If so, it probably belongs in the long-term plan. If not, it’s really just an implementation choice — which should be handled on a faster cycle — being mislabeled as strategy.

That’s one of the ways roadmaps lose credibility, Chris says.

Governance as an ongoing conversation

A roadmap that’s rewritten every quarter can’t be governed the same way a static three-year plan was, with a single sign-off and compliance checklist. What separates organizations handling this well from those struggling is leadership, says SANS Institute’s Cochran. The CISOs thriving under quarterly replanning treat governance as a discipline of communication rather than compliance. Success depends on whether they can bring the board, the business, and their own teams along when the plan changes again.

Berry sees that expectation firsthand from his own board. They want a clear account of how security is keeping pace with where the business is going, and what risk that pace introduces.

Boards are asking different questions, AIVONS’ Chris says. They used to ask whether the organization was secure. Now they want to see the evidence: what’s running, who’s accountable, and what can reach sensitive data.

A report that can’t distinguish between “we looked, and it was fine” and “we never looked,” he says, is claiming a confidence it hasn’t earned. KPMG’s 2026 survey points to a related challenge: 42% of security leaders say they struggle to demonstrate return on cybersecurity investment to their boards.

The challenge of proving value as convincingly as proving risk is part of why the roadmap is evolving. CISOs haven’t abandoned long-range thinking, but what they’re willing to commit to in writing, and for how long, is changing.

“That is why I don’t think the security roadmap is dead,” says AIVONS’ Chris. “The static roadmap is.”

Insight Global’s Dickson agrees. “A long-range roadmap still has value,” he says, “as long as you’re willing to revisit it as often as the world around it changes.”

OpenAI has scrapped the planned October release of GPT-6.1 Astra after internal testing found the model did not meet the company’s safety and alignment standards.

GPT-6.1 Astra was being developed as a more autonomous model capable of handling complex tasks with less human assistance, and was expected to be integrated into ChatGPT and Codex. But internal testing found that it could evade oversight, misrepresent its actions and operate beyond its authorized scope, while attempting to use external tools it knew were unsafe, according to a report by The Wall Street Journal

OpenAI reportedly plans to take Astra’s underlying model through additional reinforcement learning to build subsequent models in the GPT-6 family and investigate what caused the safety problems identified during testing.

Models developed by OpenAI increasingly suffer from what the industry euphemistically calls “alignment problems,” meaning a lack of understanding of what is right and wrong, what is acceptable behavior and what unacceptable.

The now-abandoned model’s predecessor, GPT-6 Astra, was caught conducting unsanctioned software supply-chain attacks in simulated cybersecurity tests by the UK’s AI Security Institute, despite being explicitly told that attacking internet targets was out of scope. It did so far more often in tests than its predecessors, GPT 5.5 and GPT 5.6 Sol.

Such models will essentially do anything to achieve their objectives, said Pieter Danhieux, co-founder and chief executive officer of Secure Code Warrior. “For these agents, their operation is essentially business as usual; They will relentlessly pursue the initial goal they were instructed to do, and being repeatedly told ‘no’ by access control parameters will simply ensure they seek the next available endpoint until they succeed,” he said, adding that such models require human oversight and stronger regulation.

OpenAI’s decision to pull GPT-6.1 Astra comes amid a series of incidents involving the company’s models, including an agent that gained unauthorized access to an Australian government portal and models that interacted with several US government websites in unexpected ways.

AI broke the rules, but someone did first

Australian Prime Minister Anthony Albanese said an internal OpenAI model was conducting research into public medical spending on June 18 when it encountered repeated blocks while attempting to obtain information from Australia’s Medicare Statistics Reporting Portal. It tried alternative ways to get the information, eventually gaining unauthorized access to the portal.

He said the agent accessed both public and non-public files and wrote files to an internal server; investigations into the incident remain ongoing.

Aviv Nahum, co-founder and chief executive officer at Above Security, said this incident could be more than an AI being at fault. “If the archive evidence holds, the most-hyped AI hack of the year looks a lot like the most common security failure of the last thirty years: a misconfiguration,” he said. “The portal’s own code pointed visitors to an endpoint that required no credentials, and the agent followed the path it was given. That’s not an ‘AI agent hacking a government website,’ that’s a door that was left open, found by something that can read the code more carefully and execute more quickly.”

We should be careful about framing every agent incident as “rogue AI,” Nahum cautioned, adding that doing so makes for “dramatic headlines,” but moves the blame to the model instead of the environment.

The US incidents were less serious but followed a similar pattern of models interacting with external systems. An OpenAI spokesperson told the Washington Post that the company’s models accessed publicly available information on SEC.gov, Investor.gov and Census.gov during training and evaluation. The company said its agents acted inappropriately in the SEC and Census Bureau incidents but did not steal any private data.

Ben Bernstein, manager of Huntress’ cybersecurity advisors team, took a similar view of the US incidents, arguing that they have been overstated as AI hacks. “These agents were simply tasked with gathering public SEC and Census information, but the guardrails in place were not firm enough to contain a model programmed to problem solve,” he said.

Still, OpenAI cannot be let off entirely, with reports of model misalignment and unauthorized activity piling up over the past few days.

Testing times

The common thread across these incidents is that they involved models being tested or evaluated by OpenAI, not publicly deployed models.

The Australian incident involved an internal OpenAI model conducting research. The US activity similarly involved models being tested by OpenAI as part of its research and evaluation work. Neither involved a customer taking a publicly available ChatGPT model and directing it against a government system.

OpenAI’s decision to kill off GPT-6.1 Astra follows its decision to pause training of its most capable models after an one of the models under test bypassed network restrictions and used DNS to communicate externally.

CEO Sam Altman acknowledged the breadth of the problem in a tweet on Sept. 25. “There is an extensive and ongoing review related to our agents’ use of internet access during training and evaluation,” he wrote, adding, “We have not been as fast as we would have liked but we are trying to balance our desire for transparency with gaining a clear understanding from petabytes of agent activity logs, and working with impacted organizations.”

Nvidia on Monday rolled out an agentic governance system called the Open Agent Safety Platform that combines software with out-of-band DPU-based silicon in a reference system design that it says will secure agents “from testing to deployment.”

But while the Nvidia design’s silicon-based component provides some cybersecurity advantages, analysts argued that it cannot help with the vast majority of agentic problems.

Nvidia’s offering leverages its OpenShell software and promises “full-stack governance and control across the software and the hardware, compute, and robotics systems that run agents,” the company said in a news release. “OpenShell software provides a secure runtime boundary that traces all actions and enforces policy as agents run on Nvidia Vera CPUs. As open source software, OpenShell can be extended to work with third-party compute platforms, including those from Arm and Intel.”

The Open Agent Safety Platform reference system design features NVIDIA Sentry, an out-of-band watchdog that runs on NVIDIA BlueField-4 DPUs to continuously monitor agent behavior. “Sentry provides in-silicon security enforcement, meaning that if an AI agent attempts to move outside its software boundary, Sentry quarantines and stops it in milliseconds,” the release stated.

In a developer blog post focusing on the details of its “safety platform,” Nvidia described its approach as a “secure runtime that executes autonomous AI agents in sandboxed environments with kernel-level isolation” and argued that “an advantage of open models is that the entire reasoning space and activations are all visible.”

Components of the platform are being rolled out by an extensive list of partners, including Citi Group, JPMorganChase, Citi, Anthropic, Cisco, CrowdStrike, Dell Technologies, Figure, HPE, Hugging Face, Microsoft, Palantir, Palo Alto Networks, Perplexity, Red Hat, Salesforce, SAP, Scale AI, ServiceNow, and SpaceXAI.

A step in the right direction

Lauren Kornutick, a senior director analyst at Gartner, mostly applauded the Nvidia effort, saying that it is “solving a problem from an interesting perspective, at the hardware level. It’s a great step in the right direction.”

But Kornutick said that she was less impressed with the published list of supporters, observing, “some major players are notably missing,” including OpenAI, Amazon, and Google.

Other analysts and consultants said that the technical implementation is impressive and offers distinct benefits, but they stressed that it also misses the big picture in terms of what enterprise CISOs are truly struggling with when trying to manage and secure autonomous agents. 

Limitations

The biggest challenge is that enterprise environments are flooded with agents that have not been approved by either IT or cybersecurity teams. Typically, those teams are not even aware of the credentialed agents. 

“The limit is coverage,” said Brian Levine, a partner with consulting firm Control Risks. “These controls govern agents you deploy on infrastructure you control. They do nothing for the agent a business unit spun up on a SaaS platform, the one embedded in a vendor’s product, or the one an attacker brings with them. You can’t hold an agent to a policy if you don’t know it exists. Discovery and inventory come first and that is a governance challenge as much as a technical one.”

Aman Mahapatra, chief strategy officer for Tribeca Softech, a New York City-based technology consulting firm, agreed about the limitations of the Nvidia offering.

“Enforcement only applies to agents running inside the governed runtime,” he said. “Runtime governance protects the agents you already know about, which is the population that needed it least.”

However, Mahapatra said, that doesn’t mean that the effort is futile. 

“This has a meaningful chance of making things materially better for one specific reason: Sentry runs out-of-band on BlueField-4 DPUs, in an isolated trust domain Nvidia describes as invisible to agents and attackers,” he said. “You cannot reason your way around a control you cannot perceive, and you cannot talk a DPU out of enforcing a policy. Probabilistic reasoning has to be sandwiched between deterministic layers the model cannot influence, with an oversight function that reads everything and writes nothing. Sentry is that principle pushed down into silicon and silicon is the right place for it.”

Brent Ellis, VP, AI Infrastructure at IDC, agreed. He estimated that it addresses “probably less than 25%” of enterprise agentic cybersecurity problems.

Lock-in risk

He added that there is a vendor lock-in element to the offering as well. Although Nvidia today controls a massive, almost monopolistic market share for AI hardware among enterprises, Ellis said that he expects those numbers to drop, because “competitors are starting to emerge as viable,” especially hyperscalers who have invested in designing their own silicon.

But for enterprises that are overwhelmingly Nvidia shops, the hardware approach could make a lot of sense, Ellis said. But will the Nvidia platform have a good chance at making enterprise agentic cybersecurity materially better?

“Yes, for the agents that run inside it,” he said. “That is a big ‘if,’ though. There is a lot of agent infrastructure that is not Nvidia, and architectures in place prior to Vera and Bluefield are limited in which elements of the platform they can adopt.”

With that caveat, Ellis said the news starts to look good. “In environments where you can adopt all the elements, then you can move enforcement out of the model and the application layer, where agents have repeatedly talked or coded their way around controls. And you can then move enforcement into the runtime and the silicon, which is a harder barrier. Sentry specifically makes the DPU a traffic cop that is harder to bypass.”

Then again, he noted, some attacks can still leverage governance weaknesses. 

“Look at how the recent OpenAI incidents unfolded,” he pointed out. “The agents didn’t break the sandbox wall. They walked through a Swiss cheese of environment security: Shared package repositories used as message boards, services that fetched internet content on the agent’s behalf, and unpatched flaws in adjacent systems.”

Avoids strategic mistakes

Frank Dickson, principal analyst at Dickson Research, said he likes Nvidia’s platform because it avoids some of the strategic mistakes made by those trying to secure agentic systems in the past. 

“For two years, this industry has tried to secure agents by asking them to behave, with guardrails bolted into the prompt, the model, and the harness. That approach was always going to lose,” he said. “Nvidia finally puts enforcement where it belongs: outside the agent, in the kernel, in a proxy that inspects every outbound request and in silicon the agent cannot see or touch. You don’t ask the prisoner to lock his own cell. Every serious agent platform will have to match this design.”

Dickson said Nvidia’s approach does not try to stop a misbehaving agent after it is caught, but instead tries to prevent the problem from occurring. 

“OpenShell checks each outbound request against policy before it leaves the sandbox, and its policy prover checks the permissions before the agent runs at all,” Dickson said. “Nvidia claims Sentry quarantines a misbehaving agent in milliseconds.”

That contrasts with the time it took to address the latest agentic problems reported by OpenAI, in which an OpenAI agent bypassed network restrictions to communicate with an external chatbot. “It took a human reviewer just three minutes to acknowledge the DNS alert the system did generate, but it was another two-and-a-half hours before the training run was stopped,” OpenAI reported. 

Not a panacea

Justin Greis, CEO of consulting firm Acceligence, also agreed that the Nvidia approach is solid, but he stressed that AI agents have a well-earned reputation for figuring out ways around such restrictions.  

“We should assume increasingly capable agents will probe boundaries, discover unintended pathways and exploit ambiguity. Security cannot depend upon the agent deciding not to do that,” he said. “But even hardware-enforced controls are only as good as the boundary and policy we give them.”

He pointed out that an agent does not necessarily need to evade a security control if the user accidentally authorizes a legitimate path that produces a dangerous outcome. “Misconfigured permissions, excessive authority, combinations of individually harmless capabilities, compromised third parties and activity occurring outside the governed environment remain very real problems,” he said.

OpenAI has paused training, evaluation, and inference involving tool use for its most-capable AI models after an agent bypassed network restrictions to communicate with an external chatbot during reinforcement-learning training of an internal research model.

“Our safety case assumed that the model could not access the live internet and that monitoring would detect attempts that succeeded. The incident exposed a gap in our controls over network restrictions,” the company wrote in a new Misalignment Report about the incident, one of three it published Friday.

It said it would only resume training after the “gap is resolved” and it has further tested the system.

The incident occurred during a research task in which the model was asked to identify a person using information available on the web. When its normal web-search tools failed to produce the information it needed, the model began looking for another way to access the internet, the company explained in the post.

The model recognized that while direct internet access was blocked, the environment still allowed DNS queries. It then used DNS as an indirect communication channel to send requests to an external chatbot, effectively circumventing the network restriction that was supposed to prevent it from accessing external services, OpenAI said.

Existing controls might not be enough

For enterprises and their CIOs, however, despite the model not being released, the incident raises critical questions about whether existing security and governance controls can keep pace with unexpected model behavior as AI agents gain greater autonomy and access to enterprise systems, analysts said.

“Traditional security controls might not be enough for AI agents as these controls are designed around known access paths, such as applications connecting to approved APIs or databases. AI agents introduce a different challenge because they can explore alternative ways to achieve a task when their intended route is blocked, including using permitted tools or protocols in unintended ways,” said Abhishek Satapathy, principal analyst at Avasant.

This requires “independently enforced controls around tool invocation, network egress, and data access alongside their existing security controls to ensure that restrictions hold even when an agent attempts an unauthorized action,” Satapathy said.

His view is echoed in a 2026 paper co-authored by researchers from Google, Qualcomm, Meta and several universities, which argues that security guarantees need to be enforced at the system level rather than relying solely on model-level safeguards.

More precisely, enterprises should tighten restrictions on outbound connections and DNS resolution, giving agents handling sensitive data only approved and logged pathways for external communication to reduce the risk of data exfiltration, unauthorized external communication and other unintended actions, said Amit Kumar Jena, AI development head at IT consulting firm Kanerika.

“Security teams should also deploy monitoring systems that alert humans in the loop to unusual traffic patterns and failed attempts to reach unauthorized destinations, particularly from code-executing agents capable of finding unconventional ways to accomplish tasks,” Jena added.

The AI slipped through operational gaps

The challenge, though, is that in this case OpenAI did have such monitoring systems, and it did have humans in the loop: They just didn’t work as expected.

It took the monitoring system over 10 minutes to raise an alert in response to the agent’s abuse of DNS — and, said OpenAI, there were other incidences of external DNS access that the system did not flag.

It took a human reviewer just three minutes to acknowledge the DNS alert the system did generate, but it was another two-and-a-half hours before the training run was stopped. OpenAI blamed the delay on the failure of an automated system: “The run did not stop automatically as expected, leading to confusion around whether it should have been stopped,” it said in its report.

The company said it is addressing the operational gaps, reinforcing its detection of DNS use by models under examination, and improving its testing of the detection systems.

“We have also accelerated additional model-assisted red-teaming of the sandbox and network controls. These red-teaming efforts might surface other transitive internet access paths, in which case we will remediate swiftly, and pause research workloads if appropriate,” OpenAI wrote.

However, imposing these additional layers of security, governance, testing, and human oversight comes with problems of its own.

These additional layers will impact the degree of autonomy models can achieve, Satapathy said. “In workflows involving sensitive data, external connectivity or consequential actions, additional controls, testing and human oversight can limit the extent to which tasks can be fully automated.”

Jadepuffer, an autonomous AI attacker first identified in July, has expanded into Azure environments, using compromised digital identities to enumerate resources, delete cloud assets and collect other credentials, according to Microsoft.

The activity includes “extensive Azure-focused resource destruction activity using compromised service principals and cloud credential collection that could be used to facilitate future exfiltration,” Microsoft said in a blog post about Storm-3168, also known as Jadepuffer. Service principals are unique machine identities given to applications running within Azure.

“The destructive operations were facilitated by compromising service principals and targeted Azure Storage Accounts, SQL databases, Key Vaults, Function Apps, recovery protection locks, Virtual Machines, and App Services,” Microsoft said in the blog post, “Storm-3168: Agentic-driven cloud attacks using compromised service principals.”

The campaign was first reported in July by Sysdig, which described Jadepuffer as an AI-driven operation capable of executing attack steps autonomously, including exploitation, credential access and destructive activity.

Two identities, split roles

Microsoft said it observed two compromised service principals in the same tenant, with one performing reconnaissance and the other carrying out discovery, destructive actions and credential collection.

One of the identities spent more than 15 hours enumerating virtual machines, subscriptions, resource groups and other resources, making more than 300 successful read operations, the company said.

A second service principal enumerated resources across multiple subscriptions within seconds and later conducted additional discovery, Microsoft said.

The timing and division of activity “strongly indicates automated or scripted execution,” the company said.

Nick Tausek, lead security automation architect at Swimlane, said the pattern aligns with earlier observations of the campaign’s behavior.

“Jadepuffer’s earlier database attack showed an AI agent working through an extortion playbook and adjusting when steps failed,” Tausek said. “Microsoft now traces the group into Azure, where compromised service principals mapped resources before a seven-minute burst of destruction.”

Destructive sequence lasted minutes

After the two agents had completed their reconnaissance they began to create mayhem, conducting more than 150 destructive or credential-related operations over about 35 minutes.

The main destructive sequence lasted about seven minutes and included more than 100 attempts to delete storage accounts, most of which were successful, the blog post said.

The attackers also deleted an Azure Key Vault, Function App and App Service plan tied to the same resource group, Microsoft said.

Attempts were also made to delete Azure SQL databases and backup-related protections, including Azure Site Recovery locks and backup protection locks, the company said.

Tausek said the speed and coordination of the activity could challenge traditional response models.

“At that speed, an AI SOC needs to connect identity activity with cloud changes before the damage spreads,” he said.

Credential access followed destruction

About 30 minutes after the destructive activity, the same service principal requested storage account access keys, making more than 30 successful ListKeys requests, Microsoft said.

The requests included storage accounts associated with recovery services, the blog post said.

Microsoft said the combination of resource deletion, attempts to interfere with recovery mechanisms and credential collection is “consistent with tactics that can support ransomware and extortion operations.”

The company said it did not observe a ransom note or confirm data exfiltration in the activity.

Ross Filipek, CISO at Corsica Technologies, said the sequence of destruction followed by credential access raises additional response challenges.

“The recovery question here goes beyond rebuilding what was deleted,” Filipek said. “The attackers later requested storage account keys, potentially giving them another route to data.”

“Responders need to establish which identities and keys were touched, then review their use before trusting restored services,” he said.

Possible credential exposure

Microsoft said it could not confirm the initial access vector but found that credentials associated with a compromised service principal had previously been exposed in plaintext in a public GitHub issue.

The secret was later removed but remained accessible in the edit history, the company said.

“Publicly exposed credentials remain usable until revoked or rotated; removing the original disclosure alone does not remediate the exposure,” Microsoft said.

Filipek said the finding highlights a common risk in cloud environments.

“A cloud credential remained visible in a GitHub issue’s edit history after someone removed it from the post,” he said. “For an IT team, it’s a useful warning about how a routine cleanup can leave an account exposed.”

“Once attackers hold an application identity, their activity can look like ordinary cloud administration,” he said.

Focus on automation and scale

Microsoft said  the activity reflects “a broader shift toward AI-orchestrated attacks,” where threat actors can coordinate operations across cloud environments with “greater speed and scale.”

Tausek said the Azure activity shows coordinated execution, though not necessarily proof that each step was directed by AI.

“I agree with Microsoft’s warning about AI-orchestrated attacks, though the Azure evidence shows coordinated automation rather than proving AI directed each step,” he said.

“Agentic AI can help analysts piece together that sequence and prepare containment while people approve the consequential actions,” he added.

Identity and recovery controls in focus

Microsoft recommended that organizations protect workload identities, enforce least-privilege access and secure backup and recovery resources to reduce risk from similar activity.

Tausek said organizations can reduce exposure by rotating exposed secrets, limiting service principal permissions and protecting backup systems before attackers gain access.

Filipek said response planning across teams is also critical.

“That takes coordination between development, cloud operations and incident response,” he said. “If those teams wait until an outage to work out who owns the credentials, they’ll lose valuable time.”

Citrix NetScaler ADC and NetScaler Gateway users should take their systems offline and patch them immediately, they were told over the weekend, as news emerged of two critical unauthenticated remote code execution zero-day vulnerabilities in the products under active attack.

“Monday will be too late,” watchTowr CEO Benjamin Harris wrote in a LinkedIn post on Sunday.

Citrix subsequently confirmed the two remotely exploitable vulnerabilities were under attack, and released fixes for both. Affected customers should install the patched versions “as soon as possible,” Citrix wrote in an advisory issued later on Sunday.

NetScaler appliances are an important part of many enterprise networks, providing VPN and remote access, load balancing and other application delivery services.

Agnidipta Sarkar, chief evangelist at ColorTokens, said, “RCE on these NetScaler deployments means an unauthenticated remote attacker can run arbitrary commands on the appliance itself, typically with high privileges. If that succeeds, attackers install persistent backdoors/webshells, modify configurations, disable logging, create rogue virtual servers, or brick/DOS the device.” They could also pivot into the internal network and reach Active Directory or other crown jewels, he added.

Citrix is tracking the two exploited vulnerabilities as CVE-2026-88771 and CVE-2026-88772. It has released fixes in NetScaler ADC and Gateway 14.1-73.37 and later, 13.1-64.23 and later, with corresponding FIPS and NDcPP builds also available.

CVE-2026-88771 is a critical remote code execution (RCE) vulnerability in Netscaler ADC and Netscaler Gateway caused by improper input validation. With a CVSS rating of 9.5, it enables unauthenticated attackers to execute arbitrary commands on the appliance.

Citrix said all NetScaler ADC and NetScaler Gateway deployments are affected, including default configurations, with no additional feature required to meet the vulnerability’s precondition. It’s barely a month since Citrix patched two other critical security holes in the appliances

CVE-2026-88772 also has a CVSS score of 9.5; it involves a memory overflow that can result in remote code execution or denial of service. It requires Datagram Transport Layer Security (DTLS) to be enabled, but Citrix notes that is the case by default on VPN virtual servers, making the condition relevant to many NetScaler Gateway deployments.

Citrix said exploitation of both vulnerabilities had been observed on unmitigated deployments, while watchTowr reported the vulnerabilities had been exploited before fixes became available.

The US Cybersecurity and Infrastructure Security Agency (CISA) added both to its Known Exploited Vulnerabilities (KEV) catalog on Sunday.

“Since most attackers here will expect discovery, they might silently harvest credentials, especially VPN credentials, exfiltrate existing business data or any other data that is immediately available,” Sarkar said, recommending taking systems offline and upgrading them immediately.

Six more Netscaler bugs

Citrix addressed six other vulnerabilities in Sunday’s security update, although it said their exposure depends on specific configurations.

CVE-2026-88773, rated 9.3, is an HTTP request-smuggling vulnerability affecting deployments using HTTP or SSL virtual servers. CVE-2026-88774, rated 7.0, is a feature policy bypass related to HTTP URL handling; Citrix noted that URL normalization can prevent WAF and security rules from being bypassed.

Three further memory-overflow vulnerabilities — CVE-2026-88775, CVE-2026-88776 and CVE-2026-88777 — are each rated 8.8 and can cause unpredictable behavior or denial of service under their respective configurations.

The final flaw, CVE-2026-88778, is also rated 8.8 and involves TCP Initial Sequence Number Prediction which, Citrix said, can be handled by enabling Enhanced ISN Generation.

Citrix said the advisory applies to customer-managed NetScaler appliances and recommended upgrading affected deployments immediately. The company also made generic indicators of compromise (IOCs) available through NetScaler Console to help customers assess whether their appliances may have been affected.

This article first appeared on Network World.

Cyber threat groups have increasingly targeted enterprise AI assets, such as credentials, cloud environments, and research, as a means for operationalizing their own use of AI. Now, another sophisticated means for obfuscating illegitimate use of AI resources is coming more clearly to light.  

According to a report last week from security firm Team Cymru, malicious actors are employing proxy servers, known as transfer stations, to hide the origin of traffic to frontier AI models, providing cover for model distillation attacks and potential abuse of stolen AI subscription credentials.

Team Cymru researchers initially identified 10,867 such servers running two open-source relay platforms called Claude Relay Service (CRS) and its successor, sub2api. Their investigation later expanded, and the total number of such proxies is now estimated at more than 80,000.

“A transfer station breaks the assumption every frontier-model control depends on: that the account making a request belongs to the party consuming the answer,” said Scott Fisher, senior principal engineer at Team Cymru, in the company’s report. “What we have uncovered is an entire ecosystem designed explicitly to break the frontier model providers’ T&Cs, enabling fraud and illicit activity.”

These transfer services authenticate customers with their own accounts but connect to upstream AI services using pools of API keys or logged-in consumer subscriptions that in many cases have been obtained through malicious activities such as credential theft.

Team Cymru managed to tie several clusters of activity through these proxies to IP addresses in China and Hong Kong. Considering that over half of the transfer gateways are hosted on VPS services in the US, it suggests the intent is to hide the geographic location of the traffic, potentially to enable model distillation attacks, in which targeted prompts are designed to extract model knowledge that is then used to train and improve other AI models.

All the frontier labs have reported distillation attacks against their services, and earlier this month the NSA, CISA, and FBI published an advisory directly accusing six China-based AI companies of engaging in industrial-scale distillation of US models through transfer stations and fraudulent account pools.

But distillation is far from the only use for these services. In August researchers from Palo Alto Networks warned about the increasing number of AI token-jacking cases, in which stolen API tokens and subscription credentials were abused via transfer stations leading to hundreds of thousands of dollars in losses to victims. Credentials associated with privileged enterprise developer accounts are harvested via information stealers, phishing campaigns, and supply-chain attacks via npm packages.

An investigation of infostealer data dumps by Okta Threat Intelligence found 561 Anthropic session tokens collected from 5,871 infected machines, including 164 that had not expired when the dataset was released. It also identified 24 valid API keys for Gemini, OpenAI, Groq, and OpenRouter, along with underground tools designed to find AI-service sessions in stolen browser data.

Meanwhile researchers from Gambit Security observed a Chinese-speaking threat actor validating 2,975 credentials collected from 1,742 hosts and uploading working keys to an AI API-reselling gateway. The collection included 448 Gemini keys, 254 OpenAI keys, 176 Anthropic keys, as well as credentials for Groq, OpenRouter, xAI, and Amazon Web Services.

A commercial relay ecosystem

The two most common relay packages in Team Cymru’s initial scan were CSR and sub2api, both published on GitHub by a developer known as Wei-Shaw. The newer platform supports user management, per-user billing, subscription-to-API conversion, model routing, and prompt auditing.

The sub2api project has been forked more than 8,000 times and its Telegram channel has almost 7,000 subscribers. Interestingly, its GitHub page lists 26 commercial sponsors, including 15 API relay resellers, residential proxy vendors, two AI account providers, a content delivery network optimized for relay traffic, and a media-generation API service.

Meanwhile, Palo Alto Networks found transfer stations running new-api and one-api, two other open-source platforms, and noted that many AI transfer station advertisements are being posted on Chinese-language marketplaces such as Taobao.

China-linked traffic

Team Cymru analyzed a cluster of servers hosted by several US virtual private server providers and found more than 4,000 IP addresses in China and Hong Kong connecting to 304 transfer stations. During eight days in late August, those addresses sent approximately 14TB to the relays and received more than 7TB.

The relays contacted both Chinese AI services, including DeepSeek, Qwen, Zhipu, MiniMax, and ByteDance’s Doubao, as well as Western providers such as Anthropic, OpenAI, Google, and xAI. However, the researchers noted that traffic toward the Chinese services was lower-volume and download-heavy, while traffic toward the Western providers was upload-heavy.

Seventeen relays proxying traffic to Anthropic’s API, uploaded approximately 81GB while receiving approximately 1.4GB, a ratio of 58 to 1. Team Cymru estimated the uploaded data could represent between 16 billion and 23 billion input tokens if it consisted of text-based context.

Team Cymru could not see the prompts or responses so could not confirm what the sessions were about, but the unusual traffic pattern could be consistent with automated querying for model distillation.

“Inference endpoints are live, production attack surfaces,” Joe Brinkley, head of offensive security at Cobalt, tells CSO. “If providers want to protect their models from extraction, they need to defend them at the application layer with real behavioral telemetry, sybil defenses, and output controls, rather than expecting policy and compliance to do the heavy lifting.”

Protecting AI credentials

Organizations should treat model credentials like other production secrets. Long-lived keys should be replaced with short-lived credentials where possible, and API accounts should have configured spending limits and alerts for changes in request volume, models used, and activity at unusual times of day. Privileged developer accounts that can create keys or change billing limits should have even stricter monitoring.

Security teams should regularly scan their organization’s repositories, containers, application packages, and configuration files for exposed AI credentials. Where possible long-lived credentials should live outside agent sandboxes, and temporary tokens should be generated and injected into workflows when approved tools require them.

Incident response procedures should include playbooks for the immediate revocation and rotation of AI credentials along with invalidation of any active session tokens associated with compromised AI subscriptions.

It’s cheap to set yourself up as a hacker these days using AI. Someone attacked 105 online retailers over a period of five days, compromising 27 of them — all for an average of $25 per attack, according to research by Israeli security company Gambit.

But the attacks have been going on for much longer. Whoever is responsible used open-source AI harnesses to mount the attack. Gambit has identified three of these: Strix for vulnerability search, Cairn for autonomous end-to-end exploitation, and Hermes to orchestrate the campaign. The attacks have proved to be highly lucrative, with 600,000 active credit card details taken from just two businesses, the installation of card skimmer scripts at five more, and some level of access to an unspecified number of major companies.

It has been a highly efficient attack, most access taking just a few hours and at a minimal cost. OpenRouter was used for AI model access. The capture of the account balance on August 25 showed the attacker spent just $7,005 over a four-week period. This worked out at roughly $25 per attack, with costs ranging from $3.13 for the cheapest target to $79.31 for the most expensive.

Gambit has contacted all the companies concerned, but warned that the intensity of the attacks shows how AI is transforming cyber criminals’ activities by providing a level of sophistication that humans would find more challenging to muster. We are already seeing a new level of incursions to businesses and can expect to see more in the future.

The domain name third-party[.]com is being used to serve malware to users — bad news for those following a little too literally online documentation that uses it as a placeholder for any third-party domain. The site is serving a ClickFix lure to Windows machines, which sidesteps existing protection and can effect changes to PowerShell, according to Manifold Security, which discovered the problem.

It’s an interesting site to target. Web developers frequently use the third-party[.]com domain as a stand-in for another website in code or documentation, so the malware poses a serious risk to enterprises who may be inadvertently sending employees or customers to the malicious site.

A more familiar placeholder domain is example.com — but this, like example.org and a handful of others, is reserved by IANA, the Internet Assigned Numbers Authority, so no-one can register it.

The domain at issue here is not reserved in this way, which means that anyone can register it and, as Manifold wryly points out, someone did.

The malware operates by mimicking a Cloudflare “are you human?” check, poisoning the clipboard, and telling the user to press Win+R and paste. The pasted command pulls and runs a remote PowerShell payload on the user’s machine, without being detected.

The ClickFix attack is not new; bad actors have been using it with various lures for a couple of years now, with third-party[.]com just the latest. The latest ESET Security Threat report noted that ClickFix detections rose by 108 percent between the latter half of 2025 and the first half of 2026, follows a 517 percent jump in the previous report, so it’s an attack method very much on the rise.

Following Manifold’s discovery, the third-party[.]com domain has now been reported to its registrar, Network Solutions. But the threat is still present, waiting to catch unwary visitors, so let that be an example.com to you.

It was meant to make life simpler: a secret email address to which developers can send a message and create an issue in their GitLab project. But poor security defaults and a long-lived token embedded in the address mean that anyone who knows the address can potentially modify protected repositories. If project owners publish or leak these addresses, as some have, then they become vulnerable.

The project-scoped email address supplied by GitLab in the form of a button that says “Email work item to this project” can unlock account-wide access on private as well as public projects, in addition to its intended function, Aikido Security has found. The feature is turned on for every account on GitLab.com, and cannot be turned off; it may also be turned on for self-hosted instances of GitLab.

“Anyone holding that address can push code and run CI/CD jobs in every project your account can reach,” the application security company said in a blog post describing its findings.

“The biggest challenge with the existing design is anyone with an email account can email to that address and act as that GitLab user,” Joseph Leon, security researcher at Aikido told CSO. “If GitLab required the ‘from’ address of the account sending the email to match the GitLab user’s email address, most of the risk would be mitigated.”

IP restrictions ignored

GitLab does allow users to set restrictions on which IP addresses may access their account — but those restrictions do not apply to emails. “GitLab blocked our browser and rejected git clone. It accepted the email, and the commit landed on main,” Aikido said.

The behavior is intended, and not a vulnerability, according to GitLab. Aikido questions that assessment, arguing that “GitLab built a credential that reaches every project in the account and bypasses IP restrictions, then presented it as an email address.”

Vulnerable addresses have the form incoming+project-id-glimt-XXXXXXXXXXXXXX-issue@incoming.gitlab.com

The culprit is the personal access token (PAT) prefixed by “glimt-“ embedded in the email address that GitLab wants to be kept private. “Keep this token secret. Anyone who has it can create issues as if they were you,” GitLab warns through a UI description for the token.

Aikido said the description adds that the token “cannot be used to access any other data,” a claim it finds untrue. Five different projects belonging to the same account provide five different private email addresses, but the “token embedded in each one is identical,” it said. The same token is used for the entire account, making a compromise reachable to every public or private project within that account.

The token could be used to do more than create a GitLab issue such as reporting a bug or requesting a feature. By simply changing a suffix to the token, GitLab could be tricked into opening a merge request.

Doing this would allow the attacker to submit a crafted patch, a file with a set of code changes, and have GitLab execute attacker-controlled code within the project’s CI/CD environment.

And merge requests

After Aikido reported that to GitLab, the company changed the UI description to reflect that the token allows creating issues “and merge requests.”

The token does not give an attacker unlimited access to GitLab: What they can do remains tied to the permissions of the account to which the secret email address is linked.

“The organizational impact depends entirely on the user’s existing permissions,” Leon said. “If they can push code to main or run CI/CD pipeline jobs on a particular project, the email address inherits those rights, and the impact can be quite severe.”

Targeting other projects in the account faces a limitation, too. The attacker needs to provide the path and ID of the target project. Both are public for public projects, while targeting a private project requires its path to be leaked; its ID, however, can be guessed.

Leon added that the likelihood of these email addresses being leaked is high. “I found a dozen or so exposed online after looking for just a couple of hours. Some belonged to popular open source projects like wget2,” he said.

Aikido’s recommendation is to treat these email addresses as credentials rather than ordinary email endpoints. Organizations should look for exposed addresses in public repositories and documentation and, if exposure is suspected, reset the email token to invalidate the existing address.

This article first appeared on InfoWorld.

Flock Safety has stirred widespread debate of late. Flock builds interconnected networks of automated license-plate readers and other public safety cameras. Those systems can help police solve serious crimes, but they also log sensitive personal location data and make it searchable across agencies and jurisdictions. The question is no longer whether the technology has value. It is what controls Flock must build now that patterns of misuse are clear.

We have sympathy for the police officers and analysts trying to use Flock responsibly. Consider a 911 call after a carjacking. An analyst checks nearby footage, identifies a likely vehicle and adds the plate or description to a hotlist. License-plate readers then produce a focused trail showing where the car went. Flock demonstrates this workflow in its Safe City materials. Its FlockOS platform can connect 911 calls, video, plate readers, police records, drones and other sensors. The software narrows the evidence before a person reviews it. That’s a use of technology that can save lives.

We also have sympathy for those concerned about Flock, given the abuse already documented. Society needs a more robust debate about how modern technology is changing privacy expectations. More surveillance can improve safety, but it creates tradeoffs. Healthy tension and hearty discussion are the only path toward the right balance.

The debate is often framed as whether to rip out Flock or let it rip up our privacy. Neither may be the right answer. Flock has invested heavily in expanding what law enforcement can do, but not enough on limiting data access only to that needed for the job. But removing Flock will not return us to a world without cameras. It will push us toward a decentralized collection of public and private systems with even fewer controls. Without intelligent search, investigators will watch footage from hundreds of cameras, exposing thousands of innocent people to human review and creating more opportunities for misuse or accidental disclosure. When computers stop filtering and prioritizing information, people must do it. Done properly, the smart layer can be the privacy layer.

The landmines in a data product are not always intuitive at launch. Teams build for the analyst trying to find the carjacker, not the officer tracking an estranged spouse, the agency trying to evade another state’s law or the feature that quietly expands access. We do not fault a product team for failing to imagine every abuse before launch. Once the pattern is visible, however, the obligation changes: Move quickly, build the lesson into the product and prove the controls work.

The risks emerge after launch

Flock is no longer just a company that sells cameras. It says it serves more than 6,000 communities, 5,000 law-enforcement agencies and over 1,000 businesses. The Washington Post reports that the network includes more than 120,000 cameras across 49 states and processes about 20 billion plate observations a month. The platform now includes video, audio detection, drones, 911 integration and software that searches police records and other systems.

Flock FreeForm lets users search video and plate data for descriptions such as a dark SUV with bumper damage or a person wearing particular clothing. Flock says it does not use facial recognition, but it can search for people through observable characteristics. Each capability may appear modest in isolation. At network scale, billions of observations searchable across time and geography can reveal where someone sleeps, works, worships, seeks medical treatment, attends a protest or spends the night. And as has been documented repeatedly, some police have abused their access.

Flock has begun responding

On Aug. 13, 2026, Flock announced several changes. It set a seven-day default for ordinary plate records, with longer preservation for active cases. It says case codes will be required for law-enforcement searches by the end of 2026, emergency overrides will be reviewed, customers can limit the offenses for which outsiders search their data, and multifactor authentication will be mandatory. Its expanded Audit Assistance system is intended to detect abnormal searches and lock users out pending review, with adoption required for law-enforcement customers by year-end. The Associated Press account of Flock’s reforms independently describes the announcement and the concerns behind it. These steps show that Flock can change the product in response to misuse. The question is how quickly the controls become universal and how fully they address the known risks.

Seven days is a sensible privacy-protective default, not a universal ceiling. Flock says more than 90% of searches that begin without a full plate occur within a week. That describes product use; it does not prove that serious crimes are solved within seven days. In an All-In interview, CEO Garrett Langley pointed to homicides and delayed reports of rape as investigations that may need more time. The example can sound rhetorical, but the point is sound: Consequential cases are often complicated, and investigators may not know which vehicle matters until later.

At Facebook, we learned the same lesson from the other side. Short retention windows made it harder to reconstruct abuse because complaints, patterns and corroborating facts often arrived later, so we widened some windows. Deletion removes risk, but it can also destroy evidence needed to expose misuse. The better model is graduated retention backed by graduated controls. Seven days can remain the default. A community seeking more time should approve it publicly and accept stronger requirements, including verified identity, case-bound access, added justification for older data, supervisor review for sensitive searches, automated abuse detection, immutable logs, periodic renewal and independent audit. Retention should follow investigative value and control maturity. It cannot carry the burden that access control and accountability should carry.

A case number matters only if it is real and the user is assigned to it. An anomaly detector matters only if it works and triggers timely action. A portal matters only if it is complete and used. Engineering takes time, but interim protection often does not. Flock can disable high-risk sharing, require supervisor approval, review suspicious searches, restrict older data and suspend problematic accounts while permanent controls are built.

In just the last few weeks we’ve heard more reasons to move quickly. Boston’s newly released surveillance report says its contract required data sharing to be off, yet outside agencies could reach Boston’s data during the opening days of its pilot because nationwide sharing had been enabled in error. Separately, a September review of historical Flock logs found searches justified with entries such as “LMAO,” “idk” and “TBD.” Flock later replaced free text with preset categories, but a dropdown still cannot prove that a real case exists or that the user is assigned to it.

What we learned at Facebook and Uber

At Facebook and Uber, we did not begin with mature privacy and integrity systems. We built them as failure modes became visible. Once misuse repeats, the problem belongs to the system. Policies must become product requirements, logs must become detection systems, review bodies need authority and executives need to know which risks remain open.

At Facebook, customer-support employees could not type in a person’s name and access their account. Access began with a real support ticket assigned to that employee, often by a queue or random assignment. A short-lived token allowed only the data needed for that ticket. When the task ended, access ended.

At Uber, we built a platform for law-enforcement requests that kept responsive data in Uber’s environment. An authorized officer could view it through a secure portal and had to make a separate decision to download a copy. Many requests were never viewed because the investigation changed direction; others were viewed but never downloaded. In both cases, the portal prevented an unnecessary durable copy from landing on a government server.

We also made sure each request was tied to a badge number and authenticated government email account. We separately logged the request, portal view, affirmative download decision and completed transfer. Those attributes created the foundation for accountability by tying the person, case, access and transfer together. A request, a view and a download are different events, and the system should treat them differently. Flock should treat a badge number and government email as attributes, not proof. It should independently confirm employment, case assignment and authority through agency or court integrations, not by replying to the same email. New devices, unusual locations, abnormal volumes and recently created accounts should trigger added verification. Fake legal process keeps changing, so detection must keep changing too.

Facebook tokenization addressed who could look. Uber’s portal addressed when data should leave the platform. Flock needs both.

The controls Flock needs

Flock should build the following controls into the product:

• Bind access to a real task. Replace free-form case codes with short-lived tokens issued from trusted systems such as 911 dispatch, records management, a supervisor-assigned investigation, a stolen-vehicle report or a documented private-security incident. Scope each token to the individual, case, plate or description, data sources, geography, time and permitted actions. Integrate with agency systems so legitimate context and audit records arrive automatically. A good investigator should experience better automation; an abuser should experience friction.
• Verify every individual and request. Tie each user to a badge number, verified agency, authenticated government account and named login. Ban shared role accounts, require phishing-resistant multifactor authentication, prefer managed devices and repeatedly confirm employment and authorization. Validate legal process through an independent channel, with added checks for unusual devices, locations, volumes or new accounts.
• Separate requesting, viewing, preserving and downloading. Portal viewing should be the default, with records remaining at the originating customer or in Flock’s controlled environment until needed. Unused permission should expire without creating an outside copy. A download should require a separate affirmative action tied to the investigator and validated case, then generate its own log.
• Measure human exposure. For each workflow, document what the computer processes, what a person sees and how unrelated results are suppressed. Give the analyst a focused set of plausible matches, not unrestricted access to everyone in the area. Track raw footage kept from human view, people who opened a case, results viewed, exports and secondary copies.
• Make sharing restrictive by default. Keep purpose and legal restrictions attached to every result, alert, export and API response so recipients cannot strip them or forward data for a prohibited use. Sharing should identify the recipient, offenses, purpose, geography and duration. Customers should see every organization with access and revoke it immediately.
• Require informed approval for expanded access. Product changes that add a capability or sharing path should be opt-in. Preserve the complete, versioned history of when each feature and relationship was enabled or disabled, not merely the setting shown when a report is generated.
• Narrow Flock’s rights in customer data. Flock’s terms say customers own their data while granting the company a perpetual, irrevocable license to use it for providing and improving products. Limit that license to defined purposes and periods. Training models on customer images should require explicit authorization and meaningful de-identification testing.
• Treat device security as part of system integrity. Roadside cameras should use hardware-backed key storage, secure boot, signed firmware and tamper detection. When a camera disappears, its credentials should be revoked immediately, and a remote wipe should be queued if it reconnects. Physical theft should be treated as an expected attack, not an exceptional one.
• Turn Audit Assistance into a tested detection system. Look for repeated searches of the same vehicle outside an active case, after-hours or out-of-jurisdiction activity, volumes inconsistent with a user’s role, recycled case numbers and repeated emergency overrides. Seed known abuse scenarios and publish detection rates, false flags and response times.
• Give a centralized integrity team authority to act. Serious cases should not depend solely on the user’s agency. Flock needs investigators, response deadlines and power to suspend a user or disconnect a customer.
• Create append-only audit records. Log the user, device, authentication, validated case, purpose, legal authority, query, jurisdictions reached, results viewed, preservation, exports, hotlist changes, emergency overrides, administrator actions and Flock employee access. For every retention, sharing or feature change, record the old and new values, approver, time, reason and product version in a store ordinary administrators cannot alter or delete. If an alert causes a mistaken stop, investigators should be able to reconstruct the model, hotlist and configuration that produced it.
• Test accuracy independently. Flock says it receives fewer than nine human-reported errors per million alerts, but that counts complaints, not errors. Roseville, California, reviewed 1,427 of its own alerts from 2023 and 2024 and found the plate had been read incorrectly in 71 percent of them. The Drive’s wrongful-stop account, by Joel Feder, shows how an erroneous source record, character recognition that ignored part of a plate, a broad partial match and absent officer verification can compound into an armed stop of the wrong person. Publish precision, recall, false alerts and misses. Show the source and age of every alert, and require visual confirmation of the plate and active source record before consequential action.
• Provide a remedy. Operate an independent complaint channel, preserve relevant logs and propagate corrections across the network. Notify affected people when misuse is confirmed unless a court-approved investigative need temporarily prevents it.
• Make transparency continuous and vendor-attested. Require public-customer portals showing retention, sharing partners, permitted offenses, queries, emergency overrides, exports, confirmed misuse, accuracy and security incidents, and public-safety outcomes. Flock should host and certify the factual layer so an agency cannot rewrite history. Each configuration event should be time-stamped, digitally signed and cryptographically linked to make deletion or reordering detectable, with a public validation receipt and independent reconciliation to raw events.

Those product controls need institutional authority behind them:

• Create board and executive accountability. Establish a board-level privacy, civil-liberties and integrity committee and give a senior executive independent of sales power to delay or block a launch. Review every material product, data source, search capability, model and integration against foreseeable misuse. No review will find every landmine. The standard is whether Flock looked seriously, documented the risk and moved quickly when experience exposed what it missed.
• Require testing and attestation. Independent assessors should test controls rather than accept management assurances. Executives should certify effectiveness and disclose material weaknesses. Flock should periodically attest to log completeness, customer configuration history, known collection gaps and material failures for a defined period, with an accountable executive’s signature and independent testing against raw events. Flock should be the source of record for what the product did, while outside verification tests that record. Publish platform totals for requests, views, preservation, downloads and permissions that expired unused; the last figure shows how many unnecessary disclosures the architecture prevented.
• Measure public-safety value independently. Fund pre-registered research on missing people found, stolen vehicles recovered, serious cases materially advanced, false leads, mistaken stops, complaints and confirmed abuse. Evidence remains mixed and thin. A National Institute of Justice randomized study, last updated in 2013, found no significant crime effects, though what it tested was plate readers on patrol rather than anything resembling a searchable national network. The National Policing Institute, summarizing the existing literature, describes operational benefits such as stolen-vehicle recovery alongside limited evidence on broader crime reduction. Nobody has rigorously evaluated the product Flock sells today.
• Support enforceable rules. Legislation should require publicly approved retention, validated cases, graduated controls for older data, limits on sharing, tamper-evident logs, continuous reporting and consequences for misuse. Long movement histories, reverse searches and similarly revealing uses should require a warrant, with narrow exceptions for stolen vehicles, endangered people and genuine emergencies. Courts are still defining constitutional limits, but Flock need not wait years to establish a defensible standard. The Center for Democracy & Technology’s ALPR recommendations are a useful starting point.

Move while there is still trust to preserve

Most people using Flock are honest law enforcement trying to find missing people, recover stolen cars and solve violent crimes. Good officers hate misuse because it endangers the public and makes their own work harder to trust. The system should help them identify outliers, remove access quickly and prove when a department stayed inside the rules.

Flock’s initial reforms show that many protections are technically possible. We know builders will not see every possible misuse before users find it for them. That does not justify delay once the pattern is clear. You may not see every landmine at launch. Once you find one, you have to move fast.

WordPress has patched what it described as a critical severity security vulnerability that would allow an unauthenticated attacker full remote code execution (RCE) capabilities. There have already been reports of attacks in the wild.

Given its popularity, WordPress has frequently been under attack, and patched another maximum severity bug allowing RCE in July. WordPress said the current hole, tracked as CVE-2026-87902, was discovered and reported to the company by Switzerland-based security researcher Robert Ressl.

The post announcing the WordPress 7.1.2 security release said that the fix addressed an issue where “an unauthenticated attacker can, under certain conditions, make page template resolution include a chosen readable local PHP file outside the active theme directories. If relevant pre-conditions for both the server environment and the active theme are met, this can lead to remote code execution (RCE).”

It urged users to update their sites immediately, and said that the fix had been backported through version 4.7, as the hole also impacts many older versions of WordPress.

Noah Kenney, principal consultant at Digital 520, said his top concern was the massive extent of damage an attacker could inflict with this hole. 

“Once attackers have PHP execution, they can read wp-config.php, obtain database credentials and authentication keys, create administrator accounts, alter payment or lead capture forms, redirect visitors, and install persistent code,” he said. “The less obvious part is how they get there. Pearcmd.php is a legitimate PHP package management tool, but attackers can abuse its configuration commands to write content of their choosing to disk. The current attacks use it to place malicious PHP in /tmp, then use the WordPress flaw to load and execute that file. A security team monitoring only the WordPress directory for changes could miss that first stage entirely.”

New risk reality

But IDC and others saw the speed with which attacks began as the most concerning element of this report. 

“This WordPress vulnerability is a textbook example of the new risk reality: attackers are exploiting critical bugs within hours of disclosure, and most enterprises are not patching fast enough to keep up,” said IDC Research Director Philip Harris, citing reports from security firm Patchstack that attackers had leveraged the hole shortly after WordPress posted the patch. 

Patchstack said, “When this post first went up, every request we had seen was reconnaissance against harmless core files. That is no longer true. Attackers are now including pearcmd.php and using it to write PHP files to disk and public scanning tooling for this CVE is in circulation.”

IDC’s Harris noted that Patchstack’s telemetry illustrated the new reality, with attacker reconnaissance occurring within five hours of the patch, and full exploitation within about a day. “The window between disclosure and exploitation has collapsed to the point that mean time to exploit for critical vulnerabilities is now negative in some cases, meaning exploit code appears before or immediately after a patch ships,” he said. “This WordPress bug tracks that pattern closely: Patchstack recorded the first probing traffic under five hours after WordPress 7.1.2 was released, and traffic volume increased roughly tenfold within a day as attackers moved from scanning to actual payload delivery.”

Aman Mahapatra, chief strategy officer for New York City-based technology consulting firm Tribeca Softech, agreed.

“The number that should anchor this story is not the 9.2 CVSS score, but it is the gap between patch and exploit. With this vulnerability, that gap was effectively zero,” he said. “WordPress shipped 7.1.2 on September 22, and Patchstack blocked the first exploitation attempt at 11:49 UTC the same day, using payloads that matched the exact encoding the patch was written to fix. Attackers did not discover this bug. They read the fix. Publishing a patch is now functionally publishing an exploit guide, and any enterprise still running a remediation cycle measured in weeks is operating on a timeline that stopped existing some time ago.”

Speedier patching needed

One response to the speed of attacker actions is to automate updates, but that is not necessarily a good option. Some enterprise CISOs are nervous about excessive patch automation; they want to review and approve any system changes, mostly to avoid disasters such as 2024’s Crowdstrike incident. 

Ressl said in an interview that another concern about automated updates is that many enterprises don’t perform sufficient verification that the updates executed properly.

“Having automatic updates enabled is not the same as verifying that the patch is installed,” he said. “Compatibility and availability concerns are legitimate reasons for testing updates. My recommendation is a rapid, tested rollout with verification across all exposed installations, including staging sites.”

Mahapatra added that the problem with update automation is especially severe in larger enterprises. 

“WordPress applies minor security releases automatically by default, which means the average hobbyist blog is probably already patched,” he pointed out. “Enterprise sites routinely disable those auto-updates to enforce change control, so the organizations with the most mature governance are the ones most likely to still be exposed this week, because their own process is holding the fix in a queue while attackers scan. Change control that cannot distinguish an unauthenticated remote code execution flaw from a routine plugin update is protecting the process rather than the enterprise, and this is the vulnerability that makes that distinction expensive.”

And, noted Nidhi Luthra, executive advisor for Acceligence: “A security release can become an attacker roadmap almost immediately, so emergency patching for internet-facing systems needs an hours-level response.”

Forgotten WordPress sites may not be patched

Mahapatra added that another, perhaps bigger, concern is the fact that many enterprise WordPress deployments happen below the radar. They are not typical shadow IT, because they are fully authorized at the time, but they are still often unknown to IT management. 

In enterprises, he said, “the exposure is materially larger than most organizations will assume because most enterprises do not think of themselves as WordPress shops, and almost all of them are. The risk sits in the web estate that IT never inventoried: marketing microsites, campaign landing pages, regional country sites, investor relations pages built by an outside agency, and the properties of companies acquired three years ago that nobody got around to migrating. The affected [WordPress version] range runs from 4.7.0 through 7.1.1, nearly a decade of installs, and the forgotten sites are precisely the ones still sitting on old branches.”

Mahapatra said that he has especially seen this in enterprises in the finance vertical.

“When I walk through external attack surface reviews with banking CISOs, the WordPress instances that surface are almost never the corporate site,” he said. “They are the sites that belong to marketing, a subsidiary, or an agency contract that expired, and none of them appear in the CMDB the security team is patching against.”

Microsoft 365 E5 and E7 customers can now run security information and event management (SIEM) inside Microsoft Defender at no extra license cost.

Microsoft is delivering the capability through the Integrated Security Operations Center (ISOC) in Microsoft Defender, which combines SIEM with Defender’s existing XDR, threat intelligence, automation and AI tools in a single portal.

“Security cannot operate at AI speed when protection and operations are built as separate systems,” Rob Lefferts, corporate vice president of Microsoft Threat Protection, wrote in a blog post announcing ISOC. He said attackers now use AI agents to automate attacks at scale, and that every handoff between separate tools slows defenders down.

Until now, E5 and E7 included Defender XDR but not SIEM, which Microsoft sells separately as Microsoft Sentinel.

Under ISOC, logs from Microsoft’s own security products are available without ingestion charges. From Oct. 1, data ingested from third-party security tools and other outside sources will be metered at $2.40 per GB on a pay-as-you-go basis, Microsoft said in a technical blog post.

The company opened ISOC as a public preview, meaning it is not fully production-ready, on Sept. 23 and has not said when the preview phase will end. It is available to organizations with an active Microsoft Defender Suite and Microsoft 365 E5 or E7 license that do not already run Microsoft Sentinel, and has no minimum seat requirement.

For organizations whose security stack already runs largely on Microsoft, the trade is attractive, said Yih Khai Wong, senior research manager for security services research at IDC Asia/Pacific.

“Most telemetry already resides in Defender, Entra, and M365, so bundling Sentinel’s SIEM into E5/E7 effectively makes ingestion free, with no separate license needed to move and re-analyze data your own vendor already holds,” Wong said.

A benefit, not a product

“ISOC is not a new standalone product,” Microsoft said in an FAQ accompanying the technical post. Its ISOC product page said capabilities such as workbooks and natural-language-to-SOAR automation “previously required a separate Sentinel purchase.”

According to the technical post, Microsoft began rolling out case management, workbooks and natural-language playbook generation to eligible customers’ Defender portals on Sept. 23, with no additional configuration required.

The included data covers Defender for Endpoint, Office 365, Identity, Cloud Apps and Cloud, plus Microsoft Entra ID Protection logs and Azure and Office 365 activity logs. Retention is 30 days during the preview, rising to 90 days on Nov. 15, the post added.

Everything else costs

Anything beyond that requires an ISOC workspace, which needs an Azure subscription, according to Microsoft’s product documentation. The workspace unlocks more than 500 data connectors, user and entity behavior analytics (UEBA), CI/CD repositories and threat intelligence.

Wong said mixed environments face a different calculation. “For multicloud shops or organizations with significant non-Microsoft telemetry, this requires a real total cost-of-ownership comparison against current SIEM spend.”

The current preview excludes organizations with an active Sentinel workspace. Microsoft said nothing changes for existing Sentinel customers, and those meeting the licensing criteria can choose to move to ISOC from Nov. 15.

Consolidating identity, endpoint, productivity and security operations under one vendor can simplify investigations, Wong said, but it also “creates greater dependency on that vendor’s roadmap, pricing model, availability, and security resilience.”

CISOs running a separate SIEM face a genuine evaluation, not a quick swap, weighing migration effort, retraining of detection content, exit costs and contractual complexity, he added.

Sanchit Vir Gogia, chief analyst at Greyhound Research, advised enterprises interested in ISOC to “reproduce the organisation’s highest-value cross-vendor detections before replacing a mature SIEM,” warning that “Microsoft’s claim of more than 500 connectors establishes reach, not equal treatment of every source.”

Agents take the next step

Microsoft’s Lefferts positioned ISOC as the foundation for the agent strategy Microsoft introduced alongside Project Perception in July.

Gogia questioned the premise that this requires a single vendor. “Microsoft has established a useful integration path. It has not established that one supplier is technically necessary for an agentic SOC,” he said. He noted that Project Perception remains invitation-only in limited public preview.

Microsoft has not published details on how agent actions within ISOC are logged, audited or reversed. Gogia said the critical threshold comes when agents gain authority to make changes, since changes to identity, endpoint or cloud policy “create a blast radius.” He recommended distinct agent identities, narrow tool permissions and independent approval for consequential changes.

The agents themselves add attack surface, Wong warned. “Adversaries may attempt to manipulate the telemetry an agent relies on, poison contextual data, or use prompt injection techniques to influence agent behavior and decision-making,” Wong said.

“Microsoft has made integration easier to buy. The enduring test is whether customers retain the means to challenge and reverse it,” Gogia said.

Microsoft did not immediately respond to a request for comment.

A flaw in VeloCloud Orchestrator enables attackers to access the platform organizations use to manage their VeloCloud SD-WAN subscriptions and the edge devices it controls.

Arista, which now owns the VeloCloud business, warned customers that a vulnerable configuration exists in on-premises VeloCloud Orchestrator deployments that remote attackers may abuse to access “privileged internal functionality” and impact the VSO host. The flaw also affected Arista’s Hosted and Dedicated VCO deployments, but the company has now patched them.

“This issue was discovered externally and is known to be actively exploited,” Arista said in its advisory, urging customers to upgrade to a patched release of VCO immediately — although fixes are currently available only for some of the affected versions.

Mayuresh Dani, security research manager, at Qualys Threat Research Unit, warned that unpatched versions remain “exposed to active exploitation and have only compensating controls as a protection.”

Arista said that organizations suspecting compromise should preserve VCO web access logs, backend application logs, system logs, database logs, and relevant file-system timestamps before remediation where operationally feasible.

Andrew Costis, engineering manager of the adversary research team at AttackIQ, backs that advice. “Patching closes the door but doesn’t reverse what came through it. A compromised orchestrator can reach the Edge devices it manages, rotate credentials and validate device state across sites,” he said.

Exploitation limited to a configuration

Arista is tracking the flaw as CVE-2026-93952, an improper input validation issue with a critical CVSS rating of 10.0.

An attack will only work under certain conditions, though: A VCO deployment is exposed only if certificate-based authentication from the VeloCloud Edge to VeloCloud Orchestrator (VCO) is configured, and the attacker has the public key of the VeloCloud Edge authentication certificate and also network access to the VCO web interface. Attackers do not need VCO tenant or operator credentials.

“Based on the information available, this is most certainly a cross-site request forgery (CSRF) vulnerability that allows threat actors to use an Edge certificate to bypass the front-end and forward the request to internal services, which inherently trusts this information,” Dani said.

The affected versions span four VCO release trains: 5.2.3.15 and earlier in the 5.2.x train, 6.1.3.7 and earlier in 6.1.x, 6.4.2.7 and earlier in 6.4.x, and 7.0.0.2 and earlier in 7.0. x.

Arista has released fixes in VCO versions 5.2.3.16 and later in the 5.2.3 train and 6.4.2.8 and later in the 6.4.2 train.

Fixes for the others trains are still to come.

What defenders can do

For organizations that cannot immediately upgrade, Arista recommends restricting access to the VCO web interface to trusted administrative networks and monitoring for suspicious activities including known malicious source IPs, unexpected outbound network activity, backdoor daemons and webshells, and unexpected admin changes.

“Because successful exploitation may compromise the orchestrator host and data managed by the orchestrator, operators should follow incident-response guidance appropriate for their deployment,” the company added.

The advisory also shared a few indicators of compromise, including a suspicious “vc-sysmond” file, the “x-vc-opt “ HTTP header and two source IP addresses associated with exploitation activity.

AttackIQ’s Costis said Arista’s advice underlined the need for continuous threat exposure management and adversarial exposure validation: “Knowing which orchestrators are reachable, and proving your access restrictions actually hold, is worth far more before an advisory like this lands than after.”

This is the second maximum-severity VeloCloud flaw that Arista has had to patch this year. The company patched another actively exploited bug in the platform in July.

This article first appeared on Network World.