Nearly half (49.8%) of organisations have confirmed or suspected that an AI agent took an unintended, unexpected or unauthorised action in the past year, according to new research from Salt Security.

The findings, published in the company’s State of Agentic AI and API Security 2H 2026 report, highlight growing concerns around the security of autonomous AI systems as enterprises increasingly integrate agents into everyday operations.

Based on a survey of more than 380 security and technology professionals, alongside Salt Labs production telemetry from hundreds of customer environments, the research suggests that AI adoption is outpacing organisations’ ability to monitor, govern and contain agent activity.

Among respondents who reported confirmed or suspected unintended agent actions, more than half experienced an unauthorised external API call or transaction, while over 40% reported an agent modifying or deleting data.

The research also found that AI agents are now firmly embedded in enterprise environments, with 86.4% of respondents reporting at least one operating within their organisation and 59.5% running more than ten. Furthermore, 76.8% reported agents capable of chaining actions across other agents, tools and APIs, creating complex sequences that may not have been anticipated by individual teams.

Despite this widespread adoption, visibility remains limited. Just 12.5% of organisations can consistently trace an agent’s complete journey, from its initial instruction through the tools and APIs it accesses to the final outcome. More than 60% would require hours or days of manual investigation to reconstruct an agent’s activity from the previous day.

The ability to respond to unexpected behaviour is similarly concerning. Only 17.5% of respondents said their organisation could automatically stop an AI agent behaving unexpectedly in production. For the majority, intervention remains a manual process, potentially requiring an application to be taken offline.

“The data shows a gap that is already producing real operational consequences,” said Roey Eliyahu, CEO of Salt Security. “Organisations are deploying agents and granting them access to enterprise data, APIs, and services before they can trace what those agents are doing or stop them automatically when something goes wrong.”

Shadow AI Infrastructure and AI-Generated Code Raise Further Concerns

The report also identified emerging risks associated with Model Context Protocol (MCP) infrastructure, which enables AI systems to interact with external tools and data sources.

Nearly a third (32.9%) of respondents reported discovering an unauthorised, shadow or misconfigured MCP server in the past year, while 54.3% had either confirmed or suspected encountering one.

Salt Labs’ own telemetry revealed that MCP-related infrastructure was detected in 21.6% of customer environments in August 2026, compared with 16.7% in January, representing a relative increase of approximately 30%.

Meanwhile, AI-generated code is introducing additional application security challenges. Some 83.5% of respondents estimated that AI-generated or AI-assisted code contributed to at least some of their application security findings.

However, just 6.8% reported resolving these issues directly within coding assistants at the point of generation, leaving vulnerabilities to be identified during subsequent code reviews, testing or after deployment.

Recent Manus Vulnerability Highlights Agentic AI Risks

The findings follow recent research from Salt Labs, which demonstrated how a single malicious email could be used to hijack the Manus agentic AI platform and potentially access a user’s connected email, cloud storage and code repository accounts.

The attack did not require a stolen password or the victim to click a malicious link. Although the platform’s guardrails detected the malicious activity, they were unable to prevent the code from executing.

The vulnerability was responsibly disclosed and has since been remediated.

According to Salt Security, the incident demonstrates how traditional detection mechanisms may struggle to keep pace with autonomous systems capable of executing multiple actions before human intervention is possible.

“The Manus research and this survey data are two views of the same problem,” said Yaniv Balmas, Head of Research at Salt Security.

“In the field, we showed how an agent can be weaponised through a single malicious email, how the guardrail detected the attack at exactly the right moment, and still could not stop the code from running. The survey quantifies how widespread that architecture is.”

The findings underline the need for organisations to strengthen visibility into agent activity, establish appropriate governance controls and develop automated containment capabilities as AI agents gain greater autonomy and access to critical enterprise systems.

The full State of Agentic AI and API Security 2H 2026 report includes sector-specific findings, recommendations for CISOs and further analysis of Salt Labs production telemetry.

The post Nearly Half of Organisations Report Unauthorised AI Agent Actions, Research Finds appeared first on IT Security Guru.

Huntress researchers have uncovered an SEO-poisoning campaign that harvests SSL VPN credentials through a lookalike WatchGuard download page, then hands victims the real, validly signed installer from WatchGuard’s own CDN, leaving endpoint tools with nothing to detect.

The activity, detailed by the Huntress SOC on 13 October, centres on watchguard-vpn[.]net, a lookalike domain posing as a download page for WatchGuard’s Mobile VPN with SSL client. Unlike earlier waves of the campaign, which relied on trojanised installers, this iteration strips the malware out entirely.

A typo and a search result

The incident Huntress investigated began on 7 October, when an administrator at a managed service provider searched Bing for “watchguard vpn sll download”. Eight seconds later they had clicked through to the fake site via a standard Bing result redirect, which Huntress says points to SEO poisoning rather than malvertising.

Two bites at the password

Clicking any download option on the site opens a pop-up asking for the VPN server address, username and password, the same three values the legitimate client requests. The logic sits in roughly 150 lines of unobfuscated JavaScript (popup.js), which posts the entries as JSON to a separate collection domain, watchguard-ssl[.]online.

The first submission is always rejected with an “incorrect data” message, prompting victims to retype carefully or try a different password. That gives the operators a second, likely more accurate, set of credentials, along with the server address they need to log in.

The payload is the real thing

After the second submission, the script triggers a download of WatchGuard’s genuine Mobile VPN with SSL installer (version 12.11.5) direct from cdn.watchguard.com. Huntress verified the file’s Authenticode signature from WatchGuard Technologies and confirmed the binary had not been altered.

With no trojanised MSI or sideloaded DLL in the chain, there is nothing for EDR to flag, and the victim gets exactly the install they expected. Detection was thin across the board: as of 8 October only seven VirusTotal vendors flagged the lure domain and two flagged the collector.

Old domain, new backend

WatchGuard’s Secplicity team first reported watchguard-vpn[.]net in January as part of a wider credential-harvesting campaign spoofing WatchGuard, F5, Fortinet, SonicWall and Sophos clients, though at that point the domain had no working backend. Microsoft later attributed related activity to Storm-2561, a financially motivated actor active since May 2025. WHOIS data shows the domain was registered again on 22 August, with the collector domain following on 14 September. Huntress says it cannot establish whether the same operators controlled both registrations.

In the case investigated, Huntress flagged the activity 21 seconds after the site loaded, and browser history suggests the user did not complete both rounds. The domain was offline as of 13 October, and Huntress has shared infrastructure details with WatchGuard.

Recommendations

• Reset passwords for any account entered on the site and treat the associated VPN endpoint as known to the attacker.
• Enforce MFA on SSL VPN access.
• Monitor for VPN logins from hosting providers, unfamiliar ASNs or new countries.
• Block watchguard-vpn[.]net, watchguard-ssl[.]online, 80.249.132[.]140 and 158.94.209[.]19.
• Publish and bookmark official download links such as software.watchguard.com.

Full research: https://www.huntress.com/blog/fake-watchguard-vpn-credential-phishing

The post Fake WatchGuard VPN site steals credentials, then serves the genuine signed client appeared first on IT Security Guru.

Zero trust has become one of the most overused terms in security marketing, often applied to products that simply add another layer of network segmentation. This piece looks at what zero trust actually specifies according to its foundational standard, the implementation order that works in practice, and why identity is the dependency most organizations underestimate.

What Does Zero Trust Actually Specify, Beyond the Marketing Language?

Zero trust gets used loosely enough that it has largely lost precision as a term, applied to everything from a VPN replacement to a full architectural rebuild. That imprecision is a real problem for organizations trying to evaluate vendor claims, since two products both marketed as zero trust solutions can address entirely different parts of the actual model.

Organizations working through this evaluation often look at established regional providers as part of their planning. Among them, cybersecurity solutions in Dubai offer a starting point for comparing how different providers translate the zero trust framework into an actual implementation roadmap, which varies considerably depending on an organization’s existing infrastructure.

At its core, the specification requires continuous verification of every access request, whether it originates inside or outside the traditional network perimeter, and it removes the assumption that anything on the internal network is inherently trustworthy simply by virtue of its location.

Zero trust component	What it actually requires
Identity verification	Every access request authenticated, not just the initial network entry
Least privilege access	Access scoped to the minimum needed for a specific task
Micro segmentation	Network divided so lateral movement is contained, not just perimeter defended
Continuous monitoring	Access patterns evaluated ongoing, not just at login

That table names the components. The harder part, and the part most vendor pitches skip, is the order in which an organization actually implements them.

What Implementation Order Actually Works, and What Stalls?

Organizations that attempt zero trust as a single, comprehensive rollout tend to stall, since the scope quickly exceeds what any team can execute without disrupting normal operations. Organizations that succeed tend to sequence the work, starting with identity infrastructure before touching network segmentation.

That sequencing is not arbitrary. Identity is the hard dependency underneath every other component of the model. Microsegmentation without solid identity verification just creates smaller trusted zones rather than removing the underlying trust assumption. Continuous monitoring without reliable identity data produces noise rather than usable signal. Getting identity right first is what makes everything built on top of it actually function as intended.

IT Security Guru’s coverage of automated tools in SaaS penetration testing touches a related sequencing question from a different angle: the growing reliance on automation to keep pace with continuous verification demands, which is exactly the kind of tooling that becomes necessary once an organization’s zero trust model matures past the identity foundation stage.

Organizations that skip the identity-first ordering often end up with what looks like a zero trust deployment on paper but functions as a rebranded VLAN structure underneath, technically segmented but still relying on implicit trust once a user or device gets past the initial checkpoint.

Where Does the NIST Standard Actually Draw the Line?

Rather than relying on vendor definitions, it helps to work from the actual specification. NIST Special Publication 800-207 lays out the zero trust architecture in detail, defining the core logical components and the tenets that distinguish a genuine implementation from marketing language attached to conventional network security.

The standard makes it clear that zero trust is a set of principles guiding architecture decisions, not a single product or technology you can buy and deploy wholesale. That framing alone rules out a large share of what gets marketed under the term, since a genuine implementation touches identity management, policy enforcement, and monitoring together rather than any one of them in isolation.

How Can an Organization Tell Real Progress From a Rebranded VLAN?

A few honest checks separate genuine progress toward zero trust from a relabeled version of existing network security. Evaluate access decisions per request based on current context, not grant broad access once a user authenticates at the start of a session. Policy enforcement should apply consistently, whether a request originates inside or outside the traditional network boundary. Monitoring should also detect anomalous access patterns after the fact, not just block unauthorized access at the point of entry.

An organization that cannot clearly explain how it makes access decisions on a per-request basis is likely still operating on the old trust model, whatever the marketing materials on its security stack claim.

FAQ

What is zero trust, in the simplest accurate terms?

It is a security model that requires continuous verification of every access request, regardless of whether it originates inside or outside the traditional network perimeter, removing the assumption that internal network location implies trustworthiness.

Why does identity have to come before network segmentation in implementation?

Identity verification is the dependency the rest of the model relies on. Segmentation and monitoring without reliable identity data produce smaller trusted zones or noisy alerts, rather than genuinely removing implicit trust.

How can an organization tell if its zero trust deployment is genuine?

Access decisions should be evaluated per request based on current context, not granted broadly after initial login, and policy enforcement should apply consistently regardless of where a request originates.

Is zero trust a product an organization can simply buy?

No. NIST’s foundational specification describes it as a set of architectural principles, not a single purchasable technology. A genuine implementation brings together identity, policy enforcement, and monitoring rather than relying on any one component alone.

The post Zero Trust in Practice: Moving Beyond the Buzzword appeared first on IT Security Guru.

Vega, the pioneer of Agentic Cyber Defense, today announced the appointment of Scott Simkin as Chief Marketing Officer. Simkin joins as Vega II unleashes the best model trained for cyber defense to transform every alert, across all data sources, into a conclusive verdict at the speed of the attack. The platform keeps every lesson and gets faster with every fight, so defenders can finally outpace adversarial AI.

“Once a generation, a company changes how security gets done. For Cyber Defense in the age of AI, that company is Vega,” said Shay Sandler, co-founder and CEO of Vega. “Scott built the stories and execution engine behind the two biggest names in security operations. Now he will help Vega define the post-SIEM era. There is no one I would rather have leading this charge.”

Simkin is one of the industry’s best-known storytellers, having twice helped define a category and drive growth at massive scale. At Palo Alto Networks, he served as Vice President of Marketing for the end-to-end Cortex platform, one of the fastest-growing portfolios spanning security operations, cloud security, and Unit 42 services, with annual revenue approaching $2 billion. Earlier, he helped pioneer the XDR category, which has since replaced EDR as the standard for modern endpoint security. At CrowdStrike, he led product marketing, technical marketing, portfolio positioning, and campaigns across the full Falcon platform. He also launched Falcon Next-Gen SIEM, which CrowdStrike says now exceeds $600 million in annual recurring revenue. Two years after founding, Vega already defends some of the world’s largest banks, healthcare providers, and Fortune 200 enterprises, and Simkin joins to turn that momentum into dominant market leadership.

“For three years, CISOs have asked me the same question about AI in their SOC: isn’t this just an iteration on the SIEM? They were right, and Vega is the answer,” said Simkin. “AI across all your data, in place, without moving or ingesting it. Better outcomes, faster, at a lower total cost. That’s Vega, and no one else comes close. I’m grateful for a career at the companies that built this market, and I’ve never been more certain about where Cyber Defense is going. Vega has the technology and the people this moment demands. There was only one choice.”

Experience Vega II at Cyber Defense at the Frontier on Oct. 21, 2026, at 8 a.m. PT / 11 a.m. ET / 4 p.m. BST.

Read the blog · Register for the virtual summit · Get a demo today

The post Vega Appoints Category Builder Scott Simkin as Chief Marketing Officer to Define the Post-SIEM Era appeared first on IT Security Guru.

Certes has received Frost & Sullivan’s 2026 Global Enabling Technology Leadership Recognition in post-quantum cryptography (PQC), following an independent evaluation of vendors in the market.

The recognition centres on a problem most security teams are now facing: migrating embedded cryptography across legacy applications, cloud environments and critical infrastructure will take years, but “harvest now, decrypt later” attacks mean data intercepted today could be exposed once sufficiently powerful quantum computers arrive. Frost & Sullivan notes that the risk is greatest for data with long regulatory, legal or commercial lifespans, and that protecting it needs to run in parallel with the longer migration effort rather than wait for it to finish.

Separating cryptography from the stack

At the heart of Certes’ platform is its Cryptographic Abstraction Layer (CAL), which sits between applications and infrastructure and lifts cryptographic protection out of the underlying technology stack. Rather than waiting for each vendor to ship a quantum-safe update and then managing disruptive upgrades, security teams can manage cryptographic change centrally and apply it to data flowing between systems.

The platform comprises the Certes Enforcement Point (CEP), which encrypts and decrypts within the data path, and the Certes Policy Manager (CPM), which manages policies and cryptographic controls centrally. Frost & Sullivan singled out its policy-specific key architecture as a key differentiator: each policy-controlled application or data flow can have its own key material, separate rotation schedules and customer-controlled key components. This is combined with quantum-based random number generation and customer-owned keys to support data sovereignty.

Certes’ patented Layer 4 payload protection encrypts the payload while preserving original network headers, so routing, QoS, monitoring, SD-WAN and flow visibility tools continue to work without applications being rewritten or networks re-architected. Deployment options span physical appliances, virtual machines on VMware ESXi, KVM, Red Hat and Nutanix AHV, and Windows and Linux client agents. Version 7 extends enforcement closer to workloads and users through expanded agent and cloud deployment options, reducing unprotected segments in the data’s journey.

Beyond quantum

The report also highlights uses beyond PQC migration. Cryptographic segmentation can separate IT and OT environments and limit lateral movement in flat networks, while a virtual air gap capability can dynamically isolate critical applications, data flows and backups during an active attack while preserving recovery. Certes’ encryption can also stop sensitive data being exposed to internal or external LLMs, giving organisations tighter governance over AI adoption.

Ozgun Pelit, Senior Industry Analyst at Frost & Sullivan, said: “Certes stands out in the emerging post-quantum security market through its focus on protecting data independently of the applications and infrastructure around it. Its combination of cryptographic abstraction, crypto-agility and centralized policy enforcement provides organisations with a practical way to reduce near-term quantum risk while navigating what will inevitably be a complex, multi-year migration.”

Paul German, CEO at Certes, said: “The next cryptographic revolution could arrive before many organizations have finished implementing the last one. Post-quantum cryptography is only the beginning. As AI and quantum technologies advance, cryptographic change will accelerate, and organisations cannot afford to rebuild their applications, networks and security infrastructure every time it happens.”

He added: “In a world where cryptography must constantly evolve, the ability to change it without changing everything else isn’t a luxury. It’s a necessity.”

The full Frost & Sullivan report is available HERE

The post Certes wins Frost & Sullivan PQC recognition for decoupling encryption from infrastructure appeared first on IT Security Guru.