When Information Becomes the Attack Surface – Understanding AI Agent Traps

AI agents go beyond answering questions. They can autonomously browse websites, read emails, search company files, query software tools, and more. AI models producing incorrect answers is hardly a threat, until agents encounter information that’s maliciously designed to influence what it sees, believes, remembers, or executes.

An agent leverages webpages, document stores, wikis, images, emails, or tools to produce intended outputs. But what happens when these sources mask malicious instructions? These trap AI agents into making a wrong interpretation or taking unintended action. Scientists from Google DeepMind categorized these “traps” into six categories, including content injection, semantic manipulation, cognitive state, behavioral control, systemic, and human-in-the-loop traps. The last two are more theoretical and expected to become more relevant as AI agent use grows. It helps to understand these traps to determine the necessary mitigations.

Content Injection: When Instructions Hide in Plain Sight

Content injections exploit the difference between what a human sees and what an agent parses, as well as the system’s difficulty in keeping trusted instructions separate from untrusted external data.

A webpage might appear harmless, but its underlying code, metadata, hidden text, or image can contain malicious instructions for an AI system. An AI model accepts attacker-controlled data from an external source, such as a website or file. If this system fails to distinguish between data and instructions, the model may start processing instructions within that content. The objective behind such injection of malicious content is to alter the AI’s response, disclose sensitive information or enable an unauthorized action. In NIST evaluations of agent hijacking, malicious instructions succeeded across five tested injection tasks, on average, 57% of the time.

A support ticket with underlying malicious instructions can manipulate an AI agent into retrieving customer data from the CRM and sending it to an attacker-controlled address. If the agent has excessive permission, this exfiltration becomes all the easier.

Semantic Manipulation: Shapeshifting the Information

Semantic manipulation need not explicitly tell the agent what to do; it feeds repetition, emotional language, selective context, a false sense of authority, and coordinated claims to the agent to skew context and guide the agent towards the ‘attacker preferred’ conclusion.

Advertisement. Scroll to continue reading.

Imagine a scenario where you have tasked an agent to zero in on a supplier. It comes across search results that repeatedly extol the virtues of a specific supplier, describe a specific company as the gold standard, highlight its strengths and amplify doubts about competitors. This increases the chances of the agent recommending this supplier. Conventional signature-based security tools may not flag anything malicious, as the attacks leverage ‘reasoning’ to influence rather than rely on malicious code.

Here, manipulation of the surrounding information environment becomes the manipulation of the decision itself.

Cognitive State Traps: Poisoning Agent Knowledge

Some agent systems use retrieval databases, interaction histories, or persistent memory stores to maintain context and continuity across tasks. This creates an opportunity for poisoned information to influence later outputs or actions. E.g., a poisoned document in a shared repository that an agent refers to and trusts as evidence, or a manipulated exchange that becomes an agent’s memory, only to rear its head during future tasks.

Research presented at the USENIX conference found that, in controlled tests, inserting five specially crafted texts per target question caused a RAG system to produce the attacker’s chosen answer in about 90% of cases, even when its knowledge base contained millions of legitimate texts.

With information governance becoming an integral component of AI security, organizations must be aware of which sources agents retrieve information from, who can modify those sources, how claims can be verified, and whether stored memories can be reviewed or removed.

Behavioral Control: Turning Influence into Action

Behavioral control operates at the juncture where interpretation is translated into action. Malicious content may attempt to make the AI agent send data, approve a transaction, execute code, invoke another tool or trigger a myriad of other actions. Here, the extent of the consequence depends on the extent of the agent’s access. Grant the agent only the data access and tool permissions required for the specific task. This could be the difference between an agent delivering a misleading summary and the same agent reading confidential files and communicating this information externally, resulting in data loss.

The More Theoretical Frontier

Systemic traps and human-in-the-loop traps remain less developed, but they deserve attention. Systemic traps could induce many similar agents to behave in correlated ways, causing congestion, market disruption, or cascading failures. Human-in-the-loop traps could use a compromised agent to mislead the person expected to approve its actions.

These risks may become more plausible as agent populations grow and users become accustomed to trusting agent-generated summaries.

Control for Agent Traps

A single control won’t alleviate the agent trap threat. A defensive framework must have aspects like source verification, content screening, memory governance, restricted permissions, isolated execution, monitoring, and an independent approval framework with a human in the loop for high-impact actions. Security must follow authority, and there should be clear lines of separation between the ability to interpret and the authority to act.

The future of agentic AI use will depend not only on what these agents can do but also on how they decide what to trust. The fact that they can complete a task is not up to doubt, but they must be able to recognize when the environment they are operating in and harnessing is trying to manipulate them.

Learn More at the AI Risk Summit | Ritz-Carlton, Half Moon Bay

https://www.securityweek.com/when-information-becomes-the-attack-surface-understanding-ai-agent-traps/

Microsoft and Allies Smash Shared Infrastructure of Amadey and StealC Malware

Microsoft, law enforcement, and several cybersecurity companies have collaborated to take down infrastructure shared by two widely used malware families: Amadey and StealC.

The action, part of the long-running Operation Endgame, involved the use of AI, legal action, and the exploitation of a vulnerability in a malware control panel, and resulted in hundreds of domains and servers being targeted for takedown.

While many cybercrime operations have been disrupted in recent years as part of Operation Endgame, this one stands out because law enforcement and companies targeted what they described as the “cybercrime assembly line”.

Making the rounds since 2018, Amadey is a malware-as-a-service loader that gives threat actors access to systems, enabling them to deliver secondary payloads. StealC is an infostealer that has been around since 2023, helping cybercriminals obtain credentials, cryptocurrency wallets, cookies, and other valuable data.

Amadey and StealC have often been used together — the former has enabled hackers to gain access to systems, while the latter has been used to steal information from the breached systems.

AI-powered analysis of the two malware families revealed that they use the same command-and-control (C&C) infrastructure, making it easier for Microsoft and its partners to conduct takedown activities.

Advertisement. Scroll to continue reading.

“This operation marked a shift in strategy: instead of focusing solely on individual threats, Europol, law enforcement and judicial authorities, as well as private industry partners disrupted the entire chain that allows cyberattacks to scale,” said Europol.

More than 25 million unique credentials stolen from over 385,000 systems were seized, and 18,000 compromised computers were identified and secured. Europol said crypto assets valued at more than $47 million were identified and flagged to restrict their use.

Researchers also discovered a vulnerability in the StealC C&C panel that enabled uploading a web shell to the server. While this flaw was exploited to collect data in support of the takedown operation, there is evidence that a StealC affiliate also used it to steal other affiliates’ data.

Microsoft, Europol, ESET, Bitsight, IBM X-Force, Proofpoint, and Japan’s Mitsui Bussan Secure Directions (MBSD) have published blog posts describing the action taken against Amadey and StealC.

The announcement comes shortly after law enforcement and cybersecurity companies worked together to take down the SocGholish botnet.

https://www.securityweek.com/microsoft-and-allies-smash-shared-infrastructure-of-amadey-and-stealc-malware/

Exclusive: Meet AIVEX, a New Triage Model Built to Reduce Supply Chain Threat and Risk

Remediation priority (vulnerability triaging) traditionally focuses on Software Bill of Materials (SBOMs) and Vulnerability Exploitability eXchange (VEX) statements provided with the software and supplemented by CVSS scores. That is not enough in today’s environment.

SBOMs list the components within the software. They emanated from Executive Order 14028 designed to reduce supply chain attacks. VEX statements emerged soon afterward to indicate whether any known vulnerabilities are exploitable. The separate CVSS score is used as a severity indicator for vulnerability remediation priority. It’s not working – supply chain attacks continue.

A major cause is a growing lack of context around exploitation. In the AI Age, the effect of exploitation may differ depending on which stage of an AI lifecycle in which it occurs. Lack of context reduces the effectiveness of remediation priority, while the expansion of AI software will magnify the problem. Supply chain attacks will continue to grow.

(Understanding ‘context’ is essential for understanding anything and everything in life. We perceive things – in this case data – but those things are meaningless in isolation. It is the surrounding, often invisible, context in which we see things that gives them any meaning. For another and different example of the importance of context, again involving AI, see the effect of bad AI context on AI decision-making.)

Devashri Datta is an independent researcher and security architect (specializing in DevSecOps automation, software supply chain security, and governance of large-scale vulnerability and compliance systems) has a solution. This solution comprises two new elements in the triage process: a safety relevance interpretation layer (SRIL) to provide context, and an extension (known as AIVEX) to the CycloneDX VEX to make the context machine readable.

SRIL provides context, and AIVEX transforms the context into a CycloneDX‑compatible schema suitable for use within the organization’s existing tooling.

Advertisement. Scroll to continue reading.

Datta’s article explaining SRIL (Moving Beyond Severity Scores: A VEX-Driven Interpretation Layer for Software Supply Chain Governance) will be published by ISACA on July 1. Today, she sat down with SecurityWeek to discuss the failure of existing SBOM/VEX/CVSS, and the manner in which AIVEX/SRIL can change things.

A growing concern

AI can transform a data threat against systems into a physical threat against people – it is increasingly and autonomously driving physical robots.

If a firm has two CVSS scores — a CVSS 9.8 critical remote code execution flaw in a back-office analytics dashboard and a moderate CVSS 5.2 input-validation bug in the sensor-fusion module of an autonomous delivery robot operating in a public warehouse — current logic dictates patching the former first. But the latter could possibly harm or even kill innocent members of the public. The existing triage logic of using SBOMs, VEX and CVSS scores does not provide this context.

As software-driven autonomous robots increasingly pervade our physical world, context becomes ever more important. “But VEX stops short of safety context,” explained Datta. “It can tell you a vulnerability is not exploitable; but it cannot tell you that if it were exploitable, the consequence would be a vehicle losing steering control at highway speed.”

The commercial consequence of an autonomous robot causing death because of a software vulnerability that could have been fixed but wasn’t fixed would probably be bankruptcy.

This is the anomalous consequence of relying on CVSS scores: AI turns low threat into very high risk.

The AI Attack Surface

The inability of CVSS to indicate context is a growing concern and has reduced the CVSS value for DevSecOps engineers. Today, with the rise of AI and autonomous robots, a new solution is urgent. But context within AI software is complicated because AI’s attack surface is not the same as a traditional software attack surface.

“An AI system, particularly an agentic one capable of taking actions in the real world, has attack surfaces distributed across training data, model weights, inference pipeline, tool integrations, and deployment infrastructure,” explained Datta. “A compromise at any stage can alter behavior in ways that are difficult to detect and harder to attribute.”

She tackles this problem through the combination of SRIL and AIVEX.

SRIL

SRIL is not just a vague idea. “Flexera has adopted this and is shipping the version to customers next week; similarly, Anchore is working on it and will ship it in the next version,” she explained.

So, what is it? “SRIL is a structured annotation layer designed to sit above existing vulnerability data, enriching CVSS scores and VEX statements with four dimensions of context that safety-critical environments need but current standards do not provide,” she continued.

The four dimensions are:

Safety domain classification (does the vulnerable component operate within a safety-critical function such as a sensor in an autonomous vehicle);
Lifecycle stage mapping (the attack surface differs between different stages of an AI – training data integrity has a different level of risk than inference-time input validation);
Consequence severity modifier (independent of the CVSS score, what is the real-world consequence if this vulnerability is exploited?)
Exploitability in context (does the deployment environment, threat actor model, and asset exposure change the exploitability calculation in ways the base VEX statement does not capture?).

In combination, said Datta, “These dimensions allow security teams to generate a safety-adjusted priority – a triage score that reflects not just how severe a vulnerability is in isolation, but how much it matters in the specific operational context where affected software is deployed.”

This is a manual effort required from the DevSecOps team, but one that is fully justified by the potential blast radius of an unpatched low-severity AI vulnerability causing robotic third party harm.

AIVEX

The SRIL data is consumed and processed by the AIVEX. It generates context-rich decisions (such as ‘remediate now’, ‘defer’, or ‘monitor’ in machine readable format.

“The AI Vulnerability Exploitability eXchange is a proposed extension to the CycloneDX VEX schema. It makes SRIL machine-readable in structured fields for model provenance, inference-time attack surface classification, safety domain annotation, and AI lifecycle stage. It is designed to integrate with existing SBOM tooling rather than replace it,” explained Datta. “The CycloneDX working group has it under active consideration.”

VEX tells you whether a CVE is exploitable in a given product configuration. “AIVEX asks the question that comes afterward,” she continued. “If the vulnerable component is an AI model acting as an agent in the real world, what does exploitation actually mean? That’s a different problem class, and the industry doesn’t have a standard for it yet.”

AI compliance benefits

More realistic triaging is not the only benefit provided by SRIL/AIVEX. It also benefits increasingly arduous AI regulatory compliance. “A life cycle-based interpretation model improves traceability and auditability without introducing new compliance burdens. The US National Institute of Standards and Technology (NIST) Secure Software Development Framework promotes risk-informed decisions,” she explains in the paper being published on July 1.

“This model operationalizes that guidance by clarifying how SBOM and VEX data feed into real-world governance decisions. Importantly, the model does not redefine these standards; it helps organizations apply them consistently.”

She goes further, anticipating future international regulation convergence. The EU AI Act is in force, but full enforcement of its most demanding aspects for AI embedded in regulated products (conformity assessment, risk management, logging, human oversight) will only begin in August of this year.

Meanwhile, she explained, “NIST’s AI Risk Management Framework similarly emphasizes governance processes that account for operational context and real-world impact of AI system failures, not merely technical severity. Sector-specific guidance from FDA (medical devices), CISA (critical infrastructure), and the Department of Transportation (autonomous vehicles) is independently converging on the same need: a structured mechanism to connect vulnerability data to safety consequence.”

Such increasingly arduous regulations make demands without telling DevSecOps how to comply with those demands. “SBOMs tell you what components you have. VEX tells you whether they’re exploitable. But SRIL asks the question that regulators actually care about: if exploited, does it matter to a patient, a power grid or a passenger?”

https://www.securityweek.com/exclusive-meet-aivex-a-new-triage-model-built-to-reduce-supply-chain-threat-and-risk/

macOS Weaknesses Chained to Silently Disable Endpoint Security Agents

Cybersecurity firm XM Cyber has demonstrated a macOS attack technique that allows a standard, non-administrative user account to silently disable enterprise endpoint security tools, including EDR and MDM agents, without triggering alerts or requiring kernel exploits.

Some of the underlying primitives, including the abuse of weakly-validated XPC connections and the injection of malicious payloads into application Interface Builder (NIB) files, have been publicly documented by security researchers for years and partially addressed by Apple.

However, the research introduces a novel chain that exploits the persistence of the kernel’s code-signing trust cache after a legitimately signed application executes, allowing an attacker to inject a malicious payload that impersonates a trusted app component and silently invokes privileged XPC methods.

The cybersecurity company noted that the attack technique abuses legitimate macOS behavior rather than software vulnerabilities.

The technique was successfully demonstrated against CrowdStrike Falcon Sensor, which was fully unloaded from a standard user account, and against Kandji MDM, which was permanently deactivated via a two-stage chain. The Kandji exploit cleared the EDR guards and terminated the Endpoint Security Framework extension, XM Cyber said.

According to the security firm, CrowdStrike has paid a bug bounty and added detection, while Kandji has patched the issue and assigned CVE-2026-39118 to the flaw. A third, unnamed enterprise EDR vendor was also successfully targeted and is working on a patch.

Advertisement. Scroll to continue reading.

XM Cyber researcher Hillel Pinto will be releasing an open source discovery tool called XPC Hunter, which automates the identification of exploitable XPC privilege escalation surfaces across all installed macOS applications, with a full presentation planned for Black Hat US in August 2026.

SecurityWeek has reached out to Apple, CrowdStrike, and Kandji for comment and will update this article if they provide any clarifications.

https://www.securityweek.com/macos-weaknesses-chained-to-silently-disable-endpoint-security-agents/

Third DraftKings Hacker Sentenced to 18 Months in Prison

A third man charged for his role in a 2022 hacking attack on the sports and betting website DraftKings has been sentenced to prison, the Justice Department announced on Tuesday.

The DOJ has not named the targeted site, describing it as a fantasy sports and betting website, but its description of the attack matches the 2022 credential-stuffing attack targeting DraftKings. In that attack, hackers accessed more than 60,000 accounts using usernames and passwords obtained from other breaches.

Once they gained access to a DraftKings account, the cybercriminals either withdrew the available funds or sold access to the account on online marketplaces.

The third suspect charged in this case is Nathan Austad, aka Snoopy, who pleaded guilty in December 2025. He has now been sentenced to 18 months in prison and three years of supervised release. He has also been ordered to pay roughly $1.8 million in restitution and forfeiture.

According to the DOJ, Austad and his accomplices stole approximately $600,000 from 1,600 DraftKings accounts.

Austad also set up a website to sell compromised accounts, and investigators identified his cryptocurrency accounts, which had roughly $465,000, including funds from his criminal activities.

Advertisement. Scroll to continue reading.

The other individuals charged for the DraftKings attack are Kamerin Stokes, sentenced to 30 months in prison in April 2026, and Joseph Garrison, sentenced to 18 months in prison in early 2024.

Authorities made public some of the messages exchanged by the three men, indicating they clearly knew they were committing a crime.

“The defendants acknowledged the federal investigation into their conduct while they were committing their crimes, even having the hubris to say the FBI could not do anything about it. They were wrong,” said Jay Clayton, US Attorney for the Southern District of New York. “Austad’s prison sentence today demonstrates the commitment of the DOJ, the FBI, and all our federal partners to protecting our on-line markets.”

https://www.securityweek.com/third-draftkings-hacker-sentenced-to-18-months-in-prison/

Critical Ubiquiti Vulnerabilities in Attackers’ Crosshairs

Threat actors have been targeting three critical-severity vulnerabilities in Ubiquiti devices, the US cybersecurity agency CISA warns.

The exploited flaws, tracked as CVE-2026-34908, CVE-2026-34909, and CVE-2026-34910, with a CVSS score of 10/10, were patched last month.

CVE-2026-34908 is described as an improper access control issue that could allow remote attackers to make unauthorized changes to vulnerable UniFi OS devices.

CVE-2026-34909 is a path traversal defect that could be exploited to access files on the underlying operating system and manipulate them to access underlying accounts.

CVE-2026-34910 is described as an improper input validation weakness that allows attackers to execute command injection attacks over the network. A variant of the flaw, tracked as CVE-2026-33000 (CVSS score of 9.1), requires authentication.

On May 21, Ubiquiti announced that UniFi OS Server version 5.0.8 was released with patches for these vulnerabilities.

Advertisement. Scroll to continue reading.

The company made no mention of their in-the-wild exploitation, yet multiple users reported on the company’s forums and on Reddit that the bugs were exploited in the wild, likely as zero-days, to create rogue administrator accounts under the username ‘John Sim’, in what appear to have been automated reconnaissance attacks.

A BishopFox analysis of the patches shows that CVE-2026-34908 and CVE-2026-34909 are an authentication gateway bypass rooted in how NGINX processes crafted requests. In raw form, the requests begin with the auth-exempt prefix, while in normalized form they resolve to an authenticated internal route.

“We confirmed the bypass against a live [UniFi OS version] 5.0.6 virtual machine. Requests built this way reached internal backends that are supposed to require authentication,” BishopFox said.

The gateway bypass then leads to CVE-2026-34910, the lack of validation of package names in a function that handles updates. It allows an attacker to supply a crafted package name containing shell metacharacters, as well as an option that forces the command code path, leading to command injection.

“We validated the unauthenticated path against our live 5.0.6 test target using a benign, time-based oracle: a request whose injected portion simply causes the server to pause for a fixed interval before responding,” the company says.

As the Centre for Cybersecurity Belgium points out, UniFi OS devices are designed for managing infrastructure and are centrally integrated into networks. Their successful compromise could allow attackers to move laterally into enterprise environments.

On Tuesday, CISA added CVE-2026-34908, CVE-2026-34909, and CVE-2026-34910 to its Known Exploited Vulnerabilities (KEV) catalog, urging federal agencies to patch them within three days, in line with BOD 26-04 requirements.

The same applies to CVE-2025-67038 (CVSS score of 9.8), an unauthenticated OS command injection defect in Lantronix EDS5000 that could lead to code execution with root privileges. The issue was disclosed in April along with 21 other Lantronix and Silex vulnerabilities, collectively tracked as BRIDGE:BREAK.

https://www.securityweek.com/critical-ubiquiti-vulnerabilities-in-attackers-crosshairs/

Agentic AI Security: Wrong Context, Wrong Decisions at Machine Speed

Context is the central plank of AI in general, and agentic AI in particular. If an AI system doesn’t have the correct context, it cannot make the correct decisions.

Security is moving toward reliance on the autonomous and automatic action of agentic AI. It has little choice. The increasing speed, volume and efficiency of attacks automated by adversarial use of both generative and agentic AI will only be matched by defensive AI with as little slow human intervention (the proverbial man-in-the-loop) as possible.

But defensive agentic AI can get it wrong and make bad decisions through lack of context. We’re not yet ready for fully autonomous AI.

“The problem that keeps me up at night is simple: an agent is only as good as the context it operates on,” explains Emanuel Salmona, CEO and co-founder at Nagomi Security. “Give it an accurate, correlated view of your environment – your assets, your controls, your exposures, your threat landscape – and it can make decisions that genuinely reduce risk. Give it incomplete data and it will still act. Confidently. Quickly. Incorrectly. Automation without verified context is just a faster way to be wrong at scale.”

Confidence is provided by the LLM used by the agentic system (it’s what LLMs are designed and trained to do). Speed comes from the machine-speed performance of artificial intelligence. Potential inaccuracy is determined by the accuracy of the context it uses. Context is king. Inadequate context can lead to bad decisions confidently, quickly, and implemented automatically.

This reliance on context applies to all agentic AI used in business, including customer service automation, software development, financial operations, sales operations, and personal assistants – and autonomous SOC applications. Give them the wrong context and they will give you bad decisions.

Context

Context is of little relevance to LLMs. Context here is fundamentally the user’s prompt – to which the LLM responds in accordance with its training. The LLM’s context is this prompt window, comprising both query and response; and it is stateless.

Advertisement. Scroll to continue reading.

Agentic AI has a goal. Its context is stateful and includes anything and everything it is allowed to see and use to achieve its goal. If the context it is given does not include the relevance of a specific device to business continuity, the response it provides will not take that into consideration – it could make immediate shutdown its conclusion, unaware of the catastrophic business effect of shutting down that device at this moment.

Agentic AI does not stop until it achieves its goal. Put simply, based on the context it is given, it presents a possible response to a received alert to an LLM in the form of a prompt. If the LLM does not agree with the validity of the prompt it receives, its own response is added to the agent’s context – and a new proposal/prompt is issued based on the new context.

Eventually, the prompt and prompt response will agree, and the agent will, if so designed, enact the proposal automatically and, where allowed, autonomously. Since the end could in theory allow device isolation or shutdown, autonomous automatic shutdown could be the result (the end) governed by the context (the means). In agentic AI, the end must not justify the means; the means must justify the end. If the context is lacking, the decision of the AI will almost certainly also be lacking.

If the agent designer and developer gets the context right, agentic AI can be a massive boon to the security of the user. If the context is wrong or inadequate, any autonomous action could be catastrophic. The precise context must be defined by the agent’s goal. But getting it right is very difficult.

Too much context for an agent is similar to sensory overload for a human: slower reasoning and degraded performance, goal drift and loss of focus, oscillation between incompatible actions (the agent may get stuck in a never-ending loop), and potential hallucinations as it attempts to connect loosely related bits of data.

Learn More at the AI Risk Summit | Ritz-Carlton, Half Moon Bay

Too little context is even more problematic. Just as humans might guess the answer to a problem by assuming bits of data that seem logical, so an agent that is instructed to achieve a goal might invent data to bridge the gap in its contextual knowledge. Operational accuracy and reliability may be lost through more hallucination. That hallucination could be a very bad decision delivered confidently.

The real world is constantly changing, so an agent’s context must continually be updated. Here, its ability to learn and adapt its own context can help. For example, a professional assistant in the US could be instructed to initiate a video meeting with an engineer in Europe. If it does so using its US timezone, it could be out of sync with Europe. The engineer’s personal assistant might reject this and reply, ‘I can only accept calls within this (UTC) timeframe’. The US assistant receives this, and the knowledge could become part of its context for future reference.

The ease with which context can be improved and expanded offers hope that the use of agentic AI will improve. It will make bad decisions to begin with but will get better with usage – but the ability to do so must be built into the system.

The problem for agentic security

Using AI to automate the work of the SOC provides an example of potential agentic issues.

The primary purpose of the original SOC is to manually triage alerts and find and respond to those that are most urgent and dangerous to the business and its IT infrastructure. This is costly and time-consuming while the time-to-disaster is collapsing. The appeal of using AI to increase the speed of triaging and reduce its cost is obvious.

SOC analysts already receive an abundance of alerts from multiple sources: EDR, NDR and XDR, SIEM and SOAR, IAM and threat information platforms. And we should include the SBOMs that should be provided with all new software and should provide vulnerability details. Getting data is not the problem. Interpreting and using data is the problem.

The difficulty for agentic AI in security is twofold. Firstly, it can only operate within the data it is given (which is its context). The conclusion it reaches while analyzing an alert within the confines of its context is entirely dependent on the adequacy of that context. To make it more difficult, adequate context is continually changing since business and infrastructure is continually changing.

Secondly, even if the context is good, the recommendation from the agent is usually poor – its reasoning is not competently explained to the user. Even with a human in the loop, the information provided by the AI may simply be, ‘this alert means there is a critical issue with this device, act now’, or perhaps ‘critical’ or ‘mild’, or ‘8 out of 10’ or ‘3 out of 10’.

The attraction of feeding alerts into an agentic system to perform machine-speed autonomous triaging is obvious. But the process comes with a major flaw. “No board would accept a set of numbers without an audit trail, yet many accept intelligence that shapes approvals and decisions with no method of visibility,” says Adam Irwin, managing partner at Heligan Strategic Advisory.

Agentic automation feeds raw alerts to the agent without the benefit of SOC expert triaging and then makes a decision on those alerts that is accepted by management without the benefit of visible reasoning. We question what we see on paper but automatically assume that our AI is correct. We are likely to assume that an autonomous SOC is accurate, but we have no proof that it is.

One alternative approach

Obbe Knoop, founder and CEO at Lanxit, has a different approach – his Security Decision Intelligence Layer uses artificial intelligence, but is not an agentic AI system. He believes that agentic AI is not sufficiently mature to be trusted with autonomous action; decisions and actions should currently be left in the hands of human experts. But those experts are being hamstrung by receiving too much data, too little reasoning, and little or no context.

“I take an alert and I pull in all the context that I need to make a decision,” he explains. “I go to the VPN gateway, I go to the identity solution, for example Okta, I go to Active Directory, I go to CrowdStrike, I pull in threat intel, I look at the target’s CMDB, and I look at the business structure, purpose and employees.”

Knoop gathers the context, fresh every time at the time of use. His product analyzes alerts in that current context and makes a recommendation within minutes. But it doesn’t simply say, this is critical or this is not critical; it explains why it has made its conclusion, and what the user should do about the situation. It will even say, “I don’t have enough context to make a clear decision on this alert” rather than hallucinate a recommended but ultimately guessed action.

What it will not do is take any autonomous automated action on behalf of the user. The final decision on what action to take in response to a detected issue is left to the user, but with more understanding of what is happening, why it is an issue, and a recommendation on how it could be solved – all delivered in plain English.

Does he believe AI will eventually have the maturity to be allowed autonomous action? “Probably,” he says. “But we’re not there yet.” He offers autonomous vehicles as an example. They are largely but not completely trusted. In some regions, users are still required by law to keep hands on the steering wheel, just in case. His solution is to give as much accurate and current information as possible on a potential vulnerability with recommendations on how to solve it, but to allow the user to keep hands on the wheel.

This context-based decision-making is good in many ways, but still has one potential drawback. While CMDBs are often and mostly accurate, this is not guaranteed to be always true. Without constant and possibly fallible human oversight and manual maintenance wherever and whenever necessary, they can drift. An automatically interrogated CMDB may not always provide ground truth for the system’s current context.

Context to AI is like batter to a cake. If you don’t have the right ingredients mixed in the right amounts, you almost certainly won’t like the outcome.

Current state of AI decision-making

Our descriptions here are simplified, while AI and its use is evolving rapidly. LLMs are being given short-term memories, so they can have their own (limited) context, if only for the current session. Agentic AI concepts are also advancing in better context gathering, better decisions and usage with fewer hallucinations. Furthermore, the general acceptance that accurate interpretation of data is more important than sheer volume of data has become more widely recognized. Nevertheless, accurate and relevant context is the axis upon which all else revolves.

AI has been around for many years; but the current state of accessible AI is only a few years old. We should not expect it to behave as a mature technology, and yet we do. We don’t know how it will evolve, in either design or use, over the next few years. What is already clear, however, is the current state of agentic AI can offer huge benefits or surprising failures depending on how we develop and manage it. Getting the context within which it operates is essential for beneficial performance. This is possible, but as we have seen, it is very difficult to achieve because of all the pitfalls discussed above.

What is needed going forward is more efficient and reliable methods for gathering and aligning relevant context to each agentic goal, and better descriptions delivered by the AI on how and why decisions are made – with detailed explanations on the users’ options for next steps. There are signs that this is happening. We have security intelligence systems. We have autonomous agentic AI. If we combine the two in a single product and monitor its performance for a few years, we will be in a better position to understand how much and where we can allow autonomous decision making to become autonomous action taking.

https://www.securityweek.com/agentic-ai-security-wrong-context-wrong-decisions-at-machine-speed/

New ‘Mistic’ RAT Opens Door to Several Ransomware Families

An initial access broker (IAB) linked to multiple ransomware families has been using a new remote access trojan (RAT) in recent attacks, Broadcom’s Symantec and Carbon Black threat hunter team reports.

The threat actor, tracked as Woodgnat and KongTuke, and active since at least May 2024, is known to have ties to ransomware groups such as Qilin, Interlock, Rhysida, Akira, 8Base, and Black Basta.

Starting in April 2026, Woodgnat has been deploying the new Backdoor.Mistic RAT against the networks of organizations across multiple industries, including education, insurance, IT, and professional services.

Previously, the threat actor was observed deploying the ModeloRAT in attacks targeting other entities.

“The targeting appears to be opportunistic, with the attackers casting a wide net and then assessing which organizations they could sell access to rather than focusing on a single sector,” Broadcom’s researchers say.

Also tracked as MLTBackdoor, Mistic provides attackers with typical capabilities, including file download and upload, file manipulation, folder creation, and code execution. The attackers can also modify the frequency at which the malware checks for new commands and can instruct it to terminate itself.

Advertisement. Scroll to continue reading.

Woodgnat has been deploying the backdoor as a DLL, executing it via sideloading. In a recent attack, the threat actor also deployed a credential stealer alongside Mistic.

Additional tools observed in the intrusion include Curl, Reg.exe, Net (net.exe), PowerShell, Certutil, and WMIC (Windows Management Instrumentation), for data exfiltration, registry manipulation, network resource management, command execution, reconnaissance, lateral movement, file download, and browser certificate installation.

The IAB is known for distributing malware via compromised WordPress sites and for relying on social engineering to entice users into executing attacker-supplied commands, including the ClickFix, FileFix, and CrashFix techniques.

“In each case the victim is ultimately tricked into running an attacker-supplied PowerShell command. While the initial compromise may be opportunistic, the attackers profile the machines for potential interest to determine their value and if they can sell access to them,” Broadcom’s threat hunter team says.

Since April 2026, the threat actor has also been using helpdesk and IT-support lures delivered via Microsoft Teams to convince victims into executing malicious code.

https://www.securityweek.com/new-mistic-rat-opens-door-to-several-ransomware-families/

Exploitable CI/CD Vulnerabilities Expose Millions of Repositories to Hijacking

A systemic class of exploitable CI/CD vulnerabilities in the open source software supply chain exposes millions of repositories to takeover, cybersecurity firm Novee warns.

Referred to as Cordyceps, the security defects allow unauthenticated attackers to hijack developer workflows and gain full control over affected repositories.

Agentic coding, Novee says, has resulted in insecure patterns being reproduced across millions of repositories through automatically generated CI/CD workflows.

The flaws, ranging from command injection to authentication logic, artifact poisoning, and privilege escalation, impact build tooling from Microsoft, Google, Apache, Cloudflare, and the Python Software Foundation, with a ripple effect reaching thousands of other organizations.

Any unauthenticated attacker with a free account can exploit these weaknesses to forge approvals, push code, and exfiltrate credentials, without an organization membership or special privileges.

“Once the exploit pattern was identified, 654 repositories were flagged in a single scan, and more than 300 were confirmed fully exploitable – attacker-controlled code execution, credential theft, or outright supply chain compromise,” Novee says.

Advertisement. Scroll to continue reading.

The vulnerabilities, the cybersecurity firm says, reside in GitHub Actions YAML. Low-privileged workflows can be triggered via untrusted pull requests or comments, with the output ending in high-privilege workflows that authenticate to cloud providers with the maintainer’s permissions.

“These workflows run shell commands, authenticate to cloud providers, hold signing keys, and publish releases, yet they are treated as ‘configuration,’ not as security-critical code. The result: command injection, privilege escalation, and supply-chain compromise hiding in plain sight,” Novee says.

The cybersecurity firm identified the flaws in GitHub Actions .yml files, which are overlooked by traditional security scanners, but underlines that this is not a GitHub-exclusive weakness, and that any workflow management system is susceptible.

“When that same software is then installed by thousands of organizations, one compromised workflow in one repository can ripple outward into banks, cloud accounts, AI labs, and end-user devices,” Novee says.

Webinar Today: Modern Exposure Validation in the AI Era

Cordyceps was confirmed to impact Microsoft’s Azure Sentinel, Google’s AI Agent Development Kit, Apache’s Doris analytics database, Cloudflare’s Workers SDK, and Python Software Foundation’s Black code formatter, impacting all organizations that rely on these repositories.

The exploitation of these vulnerabilities could lead to supply chain compromise (through malicious packages published on NPM, PyPI, Crates.io, Docker/GHCR, and Helm), malicious code pushed to protected branches, forced CI checks, compromised credentials across AWS, GCP, and Netlify, compromised self-hosted runners, and bot impersonation.

“This supply chain vulnerability lies in the foundational open-source plumbing the entire industry runs on, and the kind of issue that hides from scanners because, technically, every individual piece is working as designed. The workflow does what it was told. The vulnerability exists only in the composition – untrusted data crossing a trust boundary that no one audited,” Novee says.

https://www.securityweek.com/exploitable-ci-cd-vulnerabilities-expose-millions-of-repositories-to-hijacking/

BeyondTrust, LastPass Impacted by Klue-Salesforce Incident

LastPass is the latest cybersecurity firm to have disclosed the impact from the Klue hack, which resulted in unauthorized access to customers’ Salesforce instances.

A threat actor calling itself Icarus used a compromised legacy credential to access Klue’s systems and generate OAuth tokens to breach third-party platforms Klue integrates with, such as Salesforce.

Icarus then accessed the connected Salesforce instances and exfiltrated data in bulk, using automated scripts. Salesforce and Gong have disabled the Klue integration in response to the attack, and over a dozen organizations have already confirmed the impact.

Incident notifications from the affected companies reveal that the attackers accessed business data accessible through the Klue integration, and that no internal systems were compromised.

LastPass’s notice follows the same lines: “The information accessed was limited to standard business contact information and related customer relationship management (CRM) data, including customer names, phone numbers, email addresses, and physical addresses, as well as support case data and sales-related data.”

The company says it has discontinued access to Klue, rotated exposed tokens, notified law enforcement, and launched an investigation together with Klue and Salesforce.

Advertisement. Scroll to continue reading.

“It is important to note that the scope of this incident is limited to only those systems that integrate with Klue’s application. LastPass products, services, and infrastructure were not impacted in any way, and customer vaults remain secure. There is also no evidence the threat actor accessed any Gong-related data,” LastPass said.

This week, in addition to LastPass, 8×8 and Pendo announced they were affected.

Late last week, HackerOne, Huntress, Insurity, Jamf, OneTrust, Recorded Future, Snyk, Sprout Social, and Tanium disclosed the impact from the attack. BeyondTrust also said business contact and sales-related information was stolen from its Salesforce instance, but the notification went unnoticed.

On its Tor-based leak site, Icarus has listed several organizations as having their Salesforce data stolen, including Swiss AI communications solutions provider Gms-net. SecurityWeek has emailed the technology company for a statement and will update this article if it responds.

Icarus’s website is currently down but, before becoming inaccessible, it listed at least four other companies that have yet to publicly disclose being affected by the Klue incident, which brings the number of victims to roughly 15.

Per Huntress’s estimates, however, numerous other Klue customers were likely impacted by the data breach and are expected to come forward.

https://www.securityweek.com/beyondtrust-lastpass-impacted-by-klue-salesforce-incident/