NIST Opens Updated IoT Security Guidance to Public Review
The National Institute of Standards and Technology (NIST) announced Wednesday that it’s seeking public feedback on updated Internet of Things (IoT) security guidelines.
Updated to reflect current security needs, the guidance provides general considerations on the impact of IoT products on risk assessments and aims to establish cybersecurity requirements to support security controls.
The initial public draft (IPD) of SP 800-213 Revision 1, titled ‘IoT Product Cybersecurity Guidelines for the Federal Government: Establishing IoT Product Cybersecurity Requirements’, is available for download on NIST’s website (PDF), with the public comment period ending August 24.
As organizations increasingly rely on IoT products, they need to understand that these products are system elements and must be taken into account in the risk management process, NIST argues.
The updated guidelines build on SP 800-213A, which provides a catalog of IoT product cybersecurity capabilities and non-technical capabilities for both manufacturers and consumers.
“Just as not every Federal Information Technology (IT) system uses every control, not every capability in the catalog is needed in every IoT product. Ultimately, the goal is to enable organizations to securely incorporate IoT products into their systems and meet their security requirements,” NIST notes.
Advertisement. Scroll to continue reading.
Given the evolution of the technical, operational, and risk landscape over the past five years, SP 800-213 required an update to cover current challenges.
The updated guidelines focus on IoT products rather than IoT devices, “to clarify the difference between the ‘product’ and the system it is deployed within, ensure organizations consider all IoT product components, and provide organizations clarity and flexibility related to applying cybersecurity to IoT products.”
With the IPD focusing on new IoT products, NIST is asking for public feedback on the changes included in the update, and on whether the terms are clearly defined and relate to the intended outcomes.
In addition to reviewing the updated guidelines, organizations are also encouraged to reference SP 800-30, Revision 1 (Guide for Conducting Risk Assessments), SP 800-53 Rev. 5 (Security and Privacy Controls for Information Systems and Organizations), and other publications related to risk assessment due to the integration of IoT products into information systems.
“The IPD reflects current needs, with lessons learned from stakeholders who use these guidelines. Particularly, it’s focused on providing clearer guidance, more relevant content, and better alignment to today’s environment,” NIST notes.
Chrome 149 Update Resolves 18 Severe Vulnerabilities
Google on Wednesday rolled out a new Chrome 149 update that resolves 18 vulnerabilities, including four critical and 14 high-severity security defects.
More than half of the addressed issues, including three critical and seven high-severity, are use-after-free flaws, a type of memory corruption bug that could lead to remote code execution (RCE).
In Chrome, use-after-free vulnerabilities can be combined with security holes in the underlying operating system or in a privileged browser process to escape the sandbox.
The remaining eight issues patched in this update are out-of-bounds read, inappropriate implementation, uninitialized use, and insufficient validation of untrusted input bugs.
Per Google’s advisory, the most severe of the flaws was reported by an anonymous researcher. The company has yet to disclose the bug bounty amount to be rewarded for the report.
The remaining 17 security defects were discovered by Google, a trend that has been ongoing for the past couple of months, likely fueled by the use of AI.
Advertisement. Scroll to continue reading.
Also notable is the fact that, following a spike in new vulnerability discoveries in April and May, which culminated in a massive batch of 429 patches in early June, the number of fresh security weaknesses addressed with each new Chrome release has dropped into the lower two digits.
Google makes no mention of any of the newly resolved vulnerabilities being exploited in the wild.
The latest Chrome iteration is now rolling out as versions 149.0.7827.196/197 for Windows and macOS and as version 149.0.7827.196 for Linux.
Cisco SD-WAN Zero-Day Exploited Months Before Patching
Google’s Mandiant team has detailed the exploitation of a Cisco Catalyst SD-WAN vulnerability that was exploited as a zero-day months prior to its disclosure.
The vulnerability, tracked as CVE-2026-20245, is the 7th Cisco SD-WAN product flaw whose exploitation came to light in 2026.
CVE-2026-20245 affects the CLI of Cisco Catalyst SD-WAN Manager and allows an authenticated local attacker to execute arbitrary commands with root privileges using specially crafted files.
The security hole was disclosed by Cisco in early June, and patches were released roughly one week later.
Mandiant’s investigation began in early 2026 after observing an unidentified threat actor targeting SD-WAN infrastructure at a service provider.
The attacker established initial access to an SD-WAN Manager instance via SSH in March 2026. They then exploited CVE-2026-20245 to escalate privileges to root.
Advertisement. Scroll to continue reading.
According to Mandiant, the same victim’s SD-WAN Manager systems were previously targeted — either by the same or a different threat actor — possibly through the exploitation of other vulnerabilities, CVE-2026-20127 or CVE-2026-20182, which at the time were also zero-days.
In the March attack, the hackers authenticated to the SD-WAN Manager instance via SSH using the ‘vmanage-admin’ account and then used that access to change the default admin account’s password.
“The threat actor subsequently used their active vmanage-admin session to change the password of the admin account back to its original state before terminating their active session. This activity was likely performed to reduce the probability of detection by an administrator trying to log into the device during day-to-day operations,” Mandiant explained.
It added, “The vmanage-admin and admin accounts are default accounts on Cisco Catalyst SD-WAN controllers that have different privileges, but neither possesses root shell access.”
Once they had admin privileges to the targeted system, the attacker exploited CVE-2026-20245 to escalate privileges and achieve full root-level access.
In an effort to evade detection, the threat actor deleted all files created during the attack, restored altered system configurations, and ran a script to ensure no evidence remained.
“This campaign underscores the living off the edge paradigm, where threat actors prioritize the compromise of network appliances to bypass traditional security perimeters. As organizations increasingly adopt software-defined networking, the orchestrators managing these environments become primary targets.” Mandiant said.
Separately, a cybersecurity firm has reported seeing attacks exploiting CVE-2026-20230, a Cisco Unified CM vulnerability patched in early June. However, Cisco told SecurityWeek that it cannot confirm in-the-wild exploitation as of June 24.
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.
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.
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?”
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.
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.”
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.
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.
Emanuel Salmona, CEO at Nagomi Security
“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.
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.”
Obbe Knoop, founder and CEO at Lanxit
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.
