CSOonline

The UK’s National Cyber Security Centre (NCSC) wants to deploy autonomous AI agents capable of finding and neutralizing cyberattacks on national networks in real time, marking Britain’s push toward a sovereign, machine-speed cyber defense system. The blueprint, called Cyber Shield, was developed jointly with the Department for Science, Innovation and Technology (DSIT). “The objective of Cyber Shield is to build a national-scale, collaborative approach to agentic cyber defence, using frontier AI to identify, reduce and resolve our national cyber risk,” the NCSC said in a blog post. The proposal comes as the NCSC warns that AI is already helping attackers perform activities such as vulnerability discovery and reconnaissance “at a much greater scale and faster pace,” reducing the time available for defenders to respond. While the agency said it has not yet observed fully autonomous attacks across the complete intrusion lifecycle, it expects frontier AI models to eventually operate from initial access through actions on objectives. Cyber Shield relies on AI agents According to the blueprint, Cyber Shield would rely on AI-powered “red” and “blue” agents to identify weaknesses in systems, detect threats, and progressively automate cyber defense activities. “In the near future, we envisage a world where cyber defence is supported by ‘red’ and ‘blue’ agents which identify weaknesses in systems (‘red’) and defend against threats in real time (‘blue’),” the NCSC said in the blog. Initially, the AI agents would identify vulnerabilities and threats at machine speed before progressing toward automated remediation. They would also generate and share security insights, detect and contain breaches, collaborate across organizational boundaries, and operate under the control of participating organizations. The NCSC said it plans to begin by partnering with network defenders across government and critical UK sectors before transitioning to commercially scalable deployments. “Our aim is to transition to commercially scalable solutions to deliver a level of national resilience which is ready for the future threat,” the agency said. AI is shrinking defenders’ response window “The UK faces a cyber threat that is growing in scale, speed and sophistication,” the NCSC said. “Frontier AI is accelerating this trend, with the potential to shift the balance in favour of attackers – and with serious implications for defenders.” According to the agency, AI is already helping attackers conduct offensive cyber activities, including vulnerability discovery and reconnaissance, “at a much greater scale and faster pace.” “As a result, activities that once took weeks can now take minutes, reducing the time available for defenders to respond, detect, and contain them,” the blog post added. The Cyber Shield framework also prioritizes explainable AI, federated AI agents, automated vulnerability discovery and mitigation, coordinated detection and response, and national-scale scanning and mitigation capabilities. Among its longer-term objectives is the development of “fully automated vulnerability mitigation workflows” that would allow defenders to operate “beyond human scale,” initially across critical networks. Sanchit Vir Gogia, chief analyst at Greyhound Research, said the blueprint reflects a broader shift toward operational AI in cybersecurity but also highlights governance challenges. “Once an agent can alter a live environment, it stops being an assistant and joins the control plane,” Gogia said. “Every automated action must answer for its authority, its change and its reversal, and an agent that cannot explain itself has no business touching production.” Gogia said the NCSC itself distinguishes between AI-assisted exposure identification and threat detection, which organizations can begin adopting today, and fully automated mitigation, which the blueprint identifies as an open research challenge. Industry partnerships seen as critical The NCSC said Cyber Shield cannot be delivered by the government alone and will require collaboration with industry, academia, frontier AI developers, and operators of critical national infrastructure. “The Cyber Shield vision is ambitious and wide-reaching, and faces significant delivery challenges. It cannot be developed and operated by the NCSC or government alone,” the agency said. According to the blog post, the NCSC and DSIT are establishing pathways for partners to contribute research, technologies, and operational expertise as the blueprint evolves. The NCSC did not immediately respond to a request for comment on when Cyber Shield is expected to move beyond the blueprint stage. Gogia said the blueprint is unlikely to immediately change enterprise technology procurement because it does not yet define an operational standard. “Nobody will demand Cyber Shield-compatible products, because there is no operating standard to buy against,” he said. “What changes first is the criteria vocabulary. Serious buyers no longer ask whether a tool has agentic AI. They ask what it is permitted to change.” View the full article

The UK’s National Cyber Security Centre (NCSC) wants to deploy autonomous AI agents capable of finding and neutralizing cyberattacks on national networks in real time, marking Britain’s push toward a sovereign, machine-speed cyber defense system. The blueprint, called Cyber Shield, was developed jointly with the Department for Science, Innovation and Technology (DSIT). “The objective of Cyber Shield is to build a national-scale, collaborative approach to agentic cyber defence, using frontier AI to identify, reduce and resolve our national cyber risk,” the NCSC said in a blog post. The proposal comes as the NCSC warns that AI is already helping attackers perform activities such as vulnerability discovery and reconnaissance “at a much greater scale and faster pace,” reducing the time available for defenders to respond. While the agency said it has not yet observed fully autonomous attacks across the complete intrusion lifecycle, it expects frontier AI models to eventually operate from initial access through actions on objectives. Cyber Shield relies on AI agents According to the blueprint, Cyber Shield would rely on AI-powered “red” and “blue” agents to identify weaknesses in systems, detect threats, and progressively automate cyber defense activities. “In the near future, we envisage a world where cyber defence is supported by ‘red’ and ‘blue’ agents which identify weaknesses in systems (‘red’) and defend against threats in real time (‘blue’),” the NCSC said in the blog. Initially, the AI agents would identify vulnerabilities and threats at machine speed before progressing toward automated remediation. They would also generate and share security insights, detect and contain breaches, collaborate across organizational boundaries, and operate under the control of participating organizations. The NCSC said it plans to begin by partnering with network defenders across government and critical UK sectors before transitioning to commercially scalable deployments. “Our aim is to transition to commercially scalable solutions to deliver a level of national resilience which is ready for the future threat,” the agency said. AI is shrinking defenders’ response window “The UK faces a cyber threat that is growing in scale, speed and sophistication,” the NCSC said. “Frontier AI is accelerating this trend, with the potential to shift the balance in favour of attackers – and with serious implications for defenders.” According to the agency, AI is already helping attackers conduct offensive cyber activities, including vulnerability discovery and reconnaissance, “at a much greater scale and faster pace.” “As a result, activities that once took weeks can now take minutes, reducing the time available for defenders to respond, detect, and contain them,” the blog post added. The Cyber Shield framework also prioritizes explainable AI, federated AI agents, automated vulnerability discovery and mitigation, coordinated detection and response, and national-scale scanning and mitigation capabilities. Among its longer-term objectives is the development of “fully automated vulnerability mitigation workflows” that would allow defenders to operate “beyond human scale,” initially across critical networks. Sanchit Vir Gogia, chief analyst at Greyhound Research, said the blueprint reflects a broader shift toward operational AI in cybersecurity but also highlights governance challenges. “Once an agent can alter a live environment, it stops being an assistant and joins the control plane,” Gogia said. “Every automated action must answer for its authority, its change and its reversal, and an agent that cannot explain itself has no business touching production.” Gogia said the NCSC itself distinguishes between AI-assisted exposure identification and threat detection, which organizations can begin adopting today, and fully automated mitigation, which the blueprint identifies as an open research challenge. Industry partnerships seen as critical The NCSC said Cyber Shield cannot be delivered by the government alone and will require collaboration with industry, academia, frontier AI developers, and operators of critical national infrastructure. “The Cyber Shield vision is ambitious and wide-reaching, and faces significant delivery challenges. It cannot be developed and operated by the NCSC or government alone,” the agency said. According to the blog post, the NCSC and DSIT are establishing pathways for partners to contribute research, technologies, and operational expertise as the blueprint evolves. The NCSC did not immediately respond to a request for comment on when Cyber Shield is expected to move beyond the blueprint stage. Gogia said the blueprint is unlikely to immediately change enterprise technology procurement because it does not yet define an operational standard. “Nobody will demand Cyber Shield-compatible products, because there is no operating standard to buy against,” he said. “What changes first is the criteria vocabulary. Serious buyers no longer ask whether a tool has agentic AI. They ask what it is permitted to change.” View the full article

In a client engagement last year, an LLM-based deployment agent with standing access to a production Kubernetes cluster triggered a four-hour outage through a malformed configuration push. In the IAM, the agent appeared as a service account with a long-lived API key, no MFA, no scoped revocation path. When the incident review team asked which human had authorized the agent’s last action, no one in the room could answer. I have watched a version of that question go unanswered in three engagements over the past year, in three different sectors, with three different vendor stacks. Every CISO deck right now contains a slide about agentic AI. Far fewer contain a slide about who, in identity terms, these agents actually are. That gap is the more dangerous one. The first slide is a strategy question. The second is a control question — and it is the one your auditors, your incident responders and your board will eventually ask. Gartner’s Top Cybersecurity Trends 2026, published by Director Analyst Alex Michaels, names both halves of that gap — agentic AI oversight (Trend 1) and IAM adaptation to AI agents (Trend 4) — as the forces redefining cyber risk this year. This piece sets out a six-stage maturity model for non-human and agent-based identities (NHIs), the six minimum requirements that have to be met before any production deployment is defensible and the single most consequential reporting decision in the access-and-identity dimension: refusing the arithmetic mean across human and non-human identity governance. Why agent-based systems break the existing identity model A conventional service account performs a narrow, predictable task: it fetches a backup, runs a scheduled report, signs a build artifact. Its scope is fixed at design time. The controls around it — rotation, vaulting, audit — are well-understood. An agent-based system does not work this way. It receives an intent, decomposes it into steps, calls whichever tools or APIs it judges appropriate and produces an outcome that was not specified action-by-action in advance. KuppingerCole’s 2026 Leadership Compass on Non-Human Identity Management notes that NHIs now outnumber human users in many enterprise environments, in some cases by a factor of 25 to 50. The same compass, authored under Principal Analyst Martin Kuppinger, observes that the tooling built around joiner-mover-leaver lifecycles was never designed to discover, attribute or govern these identities at that scale. The OWASP GenAI Security Project has catalogued the resulting attack surface in two iterations — the Agentic AI Threats & Mitigations taxonomy in February 2025 and the more operational OWASP Top 10 for Agentic Applications later that year, categories ASI01 through ASI10. The notable finding is that three of the four highest-rated risks are identity questions: tool misuse and exploitation (ASI02), identity and privilege abuse including delegated and inherited trust (ASI03) and rogue agents that act outside their intended behavior (ASI10). A fourth, agentic supply chain vulnerabilities (ASI04), is identity adjacent. CISA’s first joint Five Eyes advisory on the topic — Careful Adoption of Agentic AI Services, published 1 May 2026 with NSA, the Australian Signals Directorate’s ACSC, the Canadian Centre for Cyber Security, NCSC-NZ and NCSC-UK — converges on the same conclusion. Privilege risk is named the foundational concern. The Center for Internet Security followed with its own report on prompt injection as the top compounding risk in April 2026, and NIST’s AI Agent Standards Initiative, launched February 2026, is now drafting the formal standards that will sit alongside this guidance. In other words, the dominant risk class introduced by agentic AI is not novel cryptography or some new exploit primitive. It is the unbounded scope of an identity that the existing IAM model was never asked to govern. Six minimum requirements before any agent goes to production Before any maturity discussion is useful, there is a floor. The following six requirements mark the line below which an agent-based system is not responsibly deployable in an enterprise environment. They are derived from incidents and audit findings I have collected across pharma, energy, finance and manufacturing engagements, and they are technically feasible on modern IAM and PAM platforms — though rarely on the IAM stacks most enterprises actually have today. Each agent receives a uniquely attributable non-human identity. Shared service accounts across multiple agents, or shared between an agent and a human administrator, are not acceptable. Permissions are granted under an on-behalf-of model. The agent acts on the authority of a named human principal, inheriting that principal’s permissions, scoped to a defined purpose. It never acts from its own standing authority. No long-lived credentials. No API key valid for more than an hour. No embedded secrets in code. Short-lived, context-bound credentials only, revocable on anomaly. Complete audit trail through SIEM integration. Every agent action is logged with timestamp, executing identity, instructing human principal, input context and outcome. Continuous re-authentication. For long-running agents, identity is re-validated risk-based at regular intervals — not just at session start. Real-time revocation. The capability to disconnect an agent from systems within seconds is not optional. It is the only control that actually contains an agent-based incident in flight. An organization that cannot meet all six does not have an agent governance problem. It has a deployment readiness problem. The model below assumes these are in place by Stage 3; anything earlier is the discovery phase. The six-stage NHI maturity model Most enterprise maturity scales measure the access-and-identity dimension against the yardstick of human identity: is there central IAM, is MFA enforced for privileged access, does the joiner-mover-leaver lifecycle work? These remain the right questions, but they stop short. An organization that scores Stage 4 on human identity governance and Stage 1 on agent governance does not have a mature identity practice. It has a well-lit half and a blind half. The following six-stage scale is cumulative — each stage assumes everything below it. The threshold of responsibility sits at Stage 3. In my view, production deployment of agent-based systems below Stage 3 is not defensible to a board, a regulator or an incident review. StageLabelCriterion for non-human / agent-based identitiesAudit survivability0UnrecognizedNon-human identities exist but are not in the inventory. Shared service accounts, long-lived keys, no audit trail.No — agent activity is invisible to forensics.1VisibleIdentities are inventoried and assigned to an asset class, but not yet under independent governance.No — no per-agent accountability.2UniqueEach identity is uniquely attributable (no shared accounts); initial lifecycle rules exist but are applied inconsistently.Partial — who acted is answerable; on whose authority is not.3ControlledThe six minimum requirements are fully met: on-behalf-of model, short-lived credentials, SIEM audit trail, real-time revocation.Yes — minimum defensible posture.4Bounded and monitoredThe agent’s action is bounded; every action is reviewable and — where the process allows — reversible. Agent activity metrics are evaluated, not just collected.Yes — containment is provable.5Self-regulatingAnomalies in agent behavior are detected automatically and trigger risk-based pause or revocation. Each agent has a named accountable owner.Yes — state of the art. Stages 4 and 5 deserve unpacking because they are where the model departs from access control and begins to govern behavior. Bounded means the agent’s mandate has explicit limits it cannot act outside of. Reviewable means every action is logged with intent, execution and result. Reversible means an action can be rolled back before it produces irreversible effect — a hard constraint in any environment where actions touch physical processes, financial transactions or external commitments. Self-regulating means the system detects anomalies in agent behavior and intervenes before a human reasonably could. The ‘human in the loop’ is not automatically governance One misconception consistently overrates organizations’ agent governance. The presence of a human in the decision loop is widely treated as sufficient oversight. It is not. If a human is asked to approve hundreds or thousands of agent actions without the time to inspect each one, what exists is not control but an approval automation with a human signature on it. Human review does not scale to the action volume of an autonomous system. A mature governance posture acknowledges this. It moves control from per-action approval to structural constraint: bound what the agent can do at all, monitor its behavior for anomaly and ensure that oversight is loyal to the principal, not to the executing system. An organization that rests its agent governance entirely on human per-action approvals does not reach Stage 4 of the model, regardless of how thoroughly those approvals are documented. Stage 4 requires structural bounding, not scaling handwork. OWASP as an audit-ready evidence base Maturity assessment risks drifting into subjective self-rating. The OWASP categories cited above can be operationalized into audit questions that anchor each stage in checkable evidence: OWASP attack surface (Top 10 for agentic applications)Audit question for maturity assessmentMet from stageASI03 — Identity and privilege abuseDoes each agent have a unique identity, with no shared accounts?2ASI02 — Tool misuse and exploitationAre the interfaces an agent is permitted to use explicitly bounded?4ASI01 — Goal hijackIs each agent’s mandate clearly bounded and protected against manipulation?4ASI04 — Agentic supply chain vulnerabilityIs the agent’s software composition documented via SBOM?4ASI10 — Rogue agentAre anomalies in agent behavior detected and routed to pause or revoke?5 The column on the right matters. A common rating error is to grade an organization high because it has handled the easy requirements — unique identities, basic logging — without addressing the demanding ones. Tying the upper stages to the difficult criteria prevents that inflation. Report human and non-human identity separately The single most consequential reporting decision is to refuse the arithmetic mean. The access-and-identity dimension on a maturity radar should not collapse a Stage 4 human-identity practice and a Stage 1 agent-identity practice into a reassuring middle number. Both ratings belong on the same axis, but they belong reported separately. A representative finding from current engagements: human identity governance at Stage 4 — central IAM, MFA, lifecycle managed — and agent governance at Stage 1, with agents recently inventoried but still authenticating via long-lived API keys against shared service accounts, without their own audit trail. The combined average would read Stage 2 to 3 and look acceptable. The separate reporting reveals that the unmanaged half is precisely the identity class with the largest and least predictable scope of action. That visibility is what triggers the prioritized roadmap action; an aggregated score buries it. The named-accountable-owner test If I run only one diagnostic in a new engagement, this is the one. For every production agent-based system in the environment, ask: who, by name, is accountable if this agent causes harm? An agent without a named accountable owner is the non-human counterpart of the workstation everyone uses, and no one owns. Stage 5 of the model formally requires a named accountable owner per deployed agent. The reason is operational, not bureaucratic: the question ‘who is responsible for this system?’ must be answered before the incident, not during it. In practice, that accountability binds best to the role that already carries the operational risk of the affected process — typically the asset owner in the business function. Anchoring it there prevents agent-based systems from drifting into the organizational gray zone between IT, security and the business, which is exactly where unattributed action originates. The maturity model in this article is a starting structure. The honest first step in adopting it is not to score well. It is to score truthfully, report human and non-human identity governance separately and treat the gap between them as the first item on the security roadmap for the agentic-AI period — before the next agent goes to production. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

In a client engagement last year, an LLM-based deployment agent with standing access to a production Kubernetes cluster triggered a four-hour outage through a malformed configuration push. In the IAM, the agent appeared as a service account with a long-lived API key, no MFA, no scoped revocation path. When the incident review team asked which human had authorized the agent’s last action, no one in the room could answer. I have watched a version of that question go unanswered in three engagements over the past year, in three different sectors, with three different vendor stacks. Every CISO deck right now contains a slide about agentic AI. Far fewer contain a slide about who, in identity terms, these agents actually are. That gap is the more dangerous one. The first slide is a strategy question. The second is a control question — and it is the one your auditors, your incident responders and your board will eventually ask. Gartner’s Top Cybersecurity Trends 2026, published by Director Analyst Alex Michaels, names both halves of that gap — agentic AI oversight (Trend 1) and IAM adaptation to AI agents (Trend 4) — as the forces redefining cyber risk this year. This piece sets out a six-stage maturity model for non-human and agent-based identities (NHIs), the six minimum requirements that have to be met before any production deployment is defensible and the single most consequential reporting decision in the access-and-identity dimension: refusing the arithmetic mean across human and non-human identity governance. Why agent-based systems break the existing identity model A conventional service account performs a narrow, predictable task: it fetches a backup, runs a scheduled report, signs a build artifact. Its scope is fixed at design time. The controls around it — rotation, vaulting, audit — are well-understood. An agent-based system does not work this way. It receives an intent, decomposes it into steps, calls whichever tools or APIs it judges appropriate and produces an outcome that was not specified action-by-action in advance. KuppingerCole’s 2026 Leadership Compass on Non-Human Identity Management notes that NHIs now outnumber human users in many enterprise environments, in some cases by a factor of 25 to 50. The same compass, authored under Principal Analyst Martin Kuppinger, observes that the tooling built around joiner-mover-leaver lifecycles was never designed to discover, attribute or govern these identities at that scale. The OWASP GenAI Security Project has catalogued the resulting attack surface in two iterations — the Agentic AI Threats & Mitigations taxonomy in February 2025 and the more operational OWASP Top 10 for Agentic Applications later that year, categories ASI01 through ASI10. The notable finding is that three of the four highest-rated risks are identity questions: tool misuse and exploitation (ASI02), identity and privilege abuse including delegated and inherited trust (ASI03) and rogue agents that act outside their intended behavior (ASI10). A fourth, agentic supply chain vulnerabilities (ASI04), is identity adjacent. CISA’s first joint Five Eyes advisory on the topic — Careful Adoption of Agentic AI Services, published 1 May 2026 with NSA, the Australian Signals Directorate’s ACSC, the Canadian Centre for Cyber Security, NCSC-NZ and NCSC-UK — converges on the same conclusion. Privilege risk is named the foundational concern. The Center for Internet Security followed with its own report on prompt injection as the top compounding risk in April 2026, and NIST’s AI Agent Standards Initiative, launched February 2026, is now drafting the formal standards that will sit alongside this guidance. In other words, the dominant risk class introduced by agentic AI is not novel cryptography or some new exploit primitive. It is the unbounded scope of an identity that the existing IAM model was never asked to govern. Six minimum requirements before any agent goes to production Before any maturity discussion is useful, there is a floor. The following six requirements mark the line below which an agent-based system is not responsibly deployable in an enterprise environment. They are derived from incidents and audit findings I have collected across pharma, energy, finance and manufacturing engagements, and they are technically feasible on modern IAM and PAM platforms — though rarely on the IAM stacks most enterprises actually have today. Each agent receives a uniquely attributable non-human identity. Shared service accounts across multiple agents, or shared between an agent and a human administrator, are not acceptable. Permissions are granted under an on-behalf-of model. The agent acts on the authority of a named human principal, inheriting that principal’s permissions, scoped to a defined purpose. It never acts from its own standing authority. No long-lived credentials. No API key valid for more than an hour. No embedded secrets in code. Short-lived, context-bound credentials only, revocable on anomaly. Complete audit trail through SIEM integration. Every agent action is logged with timestamp, executing identity, instructing human principal, input context and outcome. Continuous re-authentication. For long-running agents, identity is re-validated risk-based at regular intervals — not just at session start. Real-time revocation. The capability to disconnect an agent from systems within seconds is not optional. It is the only control that actually contains an agent-based incident in flight. An organization that cannot meet all six does not have an agent governance problem. It has a deployment readiness problem. The model below assumes these are in place by Stage 3; anything earlier is the discovery phase. The six-stage NHI maturity model Most enterprise maturity scales measure the access-and-identity dimension against the yardstick of human identity: is there central IAM, is MFA enforced for privileged access, does the joiner-mover-leaver lifecycle work? These remain the right questions, but they stop short. An organization that scores Stage 4 on human identity governance and Stage 1 on agent governance does not have a mature identity practice. It has a well-lit half and a blind half. The following six-stage scale is cumulative — each stage assumes everything below it. The threshold of responsibility sits at Stage 3. In my view, production deployment of agent-based systems below Stage 3 is not defensible to a board, a regulator or an incident review. StageLabelCriterion for non-human / agent-based identitiesAudit survivability0UnrecognizedNon-human identities exist but are not in the inventory. Shared service accounts, long-lived keys, no audit trail.No — agent activity is invisible to forensics.1VisibleIdentities are inventoried and assigned to an asset class, but not yet under independent governance.No — no per-agent accountability.2UniqueEach identity is uniquely attributable (no shared accounts); initial lifecycle rules exist but are applied inconsistently.Partial — who acted is answerable; on whose authority is not.3ControlledThe six minimum requirements are fully met: on-behalf-of model, short-lived credentials, SIEM audit trail, real-time revocation.Yes — minimum defensible posture.4Bounded and monitoredThe agent’s action is bounded; every action is reviewable and — where the process allows — reversible. Agent activity metrics are evaluated, not just collected.Yes — containment is provable.5Self-regulatingAnomalies in agent behavior are detected automatically and trigger risk-based pause or revocation. Each agent has a named accountable owner.Yes — state of the art. Stages 4 and 5 deserve unpacking because they are where the model departs from access control and begins to govern behavior. Bounded means the agent’s mandate has explicit limits it cannot act outside of. Reviewable means every action is logged with intent, execution and result. Reversible means an action can be rolled back before it produces irreversible effect — a hard constraint in any environment where actions touch physical processes, financial transactions or external commitments. Self-regulating means the system detects anomalies in agent behavior and intervenes before a human reasonably could. The ‘human in the loop’ is not automatically governance One misconception consistently overrates organizations’ agent governance. The presence of a human in the decision loop is widely treated as sufficient oversight. It is not. If a human is asked to approve hundreds or thousands of agent actions without the time to inspect each one, what exists is not control but an approval automation with a human signature on it. Human review does not scale to the action volume of an autonomous system. A mature governance posture acknowledges this. It moves control from per-action approval to structural constraint: bound what the agent can do at all, monitor its behavior for anomaly and ensure that oversight is loyal to the principal, not to the executing system. An organization that rests its agent governance entirely on human per-action approvals does not reach Stage 4 of the model, regardless of how thoroughly those approvals are documented. Stage 4 requires structural bounding, not scaling handwork. OWASP as an audit-ready evidence base Maturity assessment risks drifting into subjective self-rating. The OWASP categories cited above can be operationalized into audit questions that anchor each stage in checkable evidence: OWASP attack surface (Top 10 for agentic applications)Audit question for maturity assessmentMet from stageASI03 — Identity and privilege abuseDoes each agent have a unique identity, with no shared accounts?2ASI02 — Tool misuse and exploitationAre the interfaces an agent is permitted to use explicitly bounded?4ASI01 — Goal hijackIs each agent’s mandate clearly bounded and protected against manipulation?4ASI04 — Agentic supply chain vulnerabilityIs the agent’s software composition documented via SBOM?4ASI10 — Rogue agentAre anomalies in agent behavior detected and routed to pause or revoke?5 The column on the right matters. A common rating error is to grade an organization high because it has handled the easy requirements — unique identities, basic logging — without addressing the demanding ones. Tying the upper stages to the difficult criteria prevents that inflation. Report human and non-human identity separately The single most consequential reporting decision is to refuse the arithmetic mean. The access-and-identity dimension on a maturity radar should not collapse a Stage 4 human-identity practice and a Stage 1 agent-identity practice into a reassuring middle number. Both ratings belong on the same axis, but they belong reported separately. A representative finding from current engagements: human identity governance at Stage 4 — central IAM, MFA, lifecycle managed — and agent governance at Stage 1, with agents recently inventoried but still authenticating via long-lived API keys against shared service accounts, without their own audit trail. The combined average would read Stage 2 to 3 and look acceptable. The separate reporting reveals that the unmanaged half is precisely the identity class with the largest and least predictable scope of action. That visibility is what triggers the prioritized roadmap action; an aggregated score buries it. The named-accountable-owner test If I run only one diagnostic in a new engagement, this is the one. For every production agent-based system in the environment, ask: who, by name, is accountable if this agent causes harm? An agent without a named accountable owner is the non-human counterpart of the workstation everyone uses, and no one owns. Stage 5 of the model formally requires a named accountable owner per deployed agent. The reason is operational, not bureaucratic: the question ‘who is responsible for this system?’ must be answered before the incident, not during it. In practice, that accountability binds best to the role that already carries the operational risk of the affected process — typically the asset owner in the business function. Anchoring it there prevents agent-based systems from drifting into the organizational gray zone between IT, security and the business, which is exactly where unattributed action originates. The maturity model in this article is a starting structure. The honest first step in adopting it is not to score well. It is to score truthfully, report human and non-human identity governance separately and treat the gap between them as the first item on the security roadmap for the agentic-AI period — before the next agent goes to production. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Security leaders have been on a spending sprint. The global AI in cybersecurity market is valued at $44 billion in 2026 and is projected to reach $213 billion by 2034, a trajectory that reflects genuine belief that machine learning will close the gap between the volume of threats and the capacity of human analysts. That belief is not wrong. What is wrong is where most organizations focus when the tools stop working. When AI-driven detection underperforms, the instinct is to tune the algorithm, retrain the model or push the vendor for a better product. The real culprit, in most cases, is sitting upstream in the data pipelines long before any model ever sees an event. Fragmented telemetry, inconsistent schemas and stale behavioral baselines are quietly degrading the performance of AI security systems across the enterprise. Fixing the algorithm without fixing the data is like recalibrating a scale while the input keeps changing. The tool sprawl problem nobody talks about at the data level Most large enterprises are not working with clean, unified security data. They are working with decades of accumulated infrastructure decisions. Research shows the average enterprise runs 83 different security products from 29 separate vendors, and SOC teams absorb nearly 3,000 alerts per day, with 63 percent going unaddressed. Each of those tools generates its own telemetry in its own format, with its own field naming conventions, timestamp standards and metadata schemas. Human analysts develop an intuition for navigating that inconsistency. Machine learning models do not. A behavioral detection model trained to correlate authentication events across your identity platform, your endpoint agent and your cloud access broker will produce unreliable results if those three tools call the same field three different names. The model is not broken. It is being fed structurally incoherent data and asked to find patterns in the noise. What schema drift actually costs you This is where the problem becomes invisible and expensive. Schema drift, the gradual mutation of data formats across security pipelines over time, rarely triggers an alert. Log formats change when vendors push updates. New telemetry sources add fields that did not previously exist. Identity platforms rename attributes without notifying the security engineering team. Over months, the statistical patterns that trained your behavioral detection models no longer match the data those models are receiving in production. The downstream effects are exactly what most CISOs are already experiencing: Elevated false positive rates, analyst fatigue and detection gaps that only become visible after an incident. What most security leaders do not realize is that those symptoms trace back to the data layer, not the algorithm layer. Gartner projects that through 2026, organizations will abandon 60 percent of AI projects due to insufficient data quality, and the pattern is playing out in security operations as visibly as anywhere else. Stale baselines are an attacker advantage The data freshness problem is underappreciated as a security risk. Behavioral AI models build baselines from historical activity. In fast-changing enterprise environments, those baselines go stale faster than most security teams recognize. The shift to hybrid work changed access patterns dramatically. Cloud adoption changed which resources users interact with and when. Mergers and acquisitions introduce new user populations with entirely different behavioral profiles. When AI models evaluate today’s activity against baselines built from a workforce and infrastructure that no longer exist, the results are predictable: Legitimate access triggers anomaly alerts, and sophisticated attackers who study baseline patterns can blend in precisely because the model’s assumptions have not kept up with the environment. IBM research on data quality costs puts the average annual cost of poor data quality at $12.9 million per organization. In a security context, that figure does not capture the incident response costs, regulatory exposure or reputational damage that follow from a detection failure rooted in bad data architecture. The organizational gap that keeps this problem in place The reason this issue persists is structural. Data pipelines are typically managed by data or infrastructure engineering teams. Detection models are owned by SOC analysts or threat intelligence teams. The AI systems that sit between those two functions often belong to neither. When detection quality drops, security teams tune parameters. Engineering teams focus on pipeline cost and availability. Nobody owns the analytical consistency of the data flowing through the system, because no one’s job description covers that specific gap. This is a leadership problem before it is a technical one. CISOs who want AI security tools to perform as advertised need to close that ownership gap and treat security telemetry with the same rigor applied to other business-critical data assets. Three priorities for security leaders Addressing this does not require a platform replacement or a multi-year transformation program. It requires deliberate attention to three areas: Standardize telemetry schemas across your security stack. A unified schema, even an imperfect one, gives machine learning models a consistent foundation. Establish naming conventions for common fields, normalize timestamp formats and document deviations when vendors cannot comply. This is not a one-time project. It is ongoing governance. Build data quality monitoring into every ingestion pipeline. Before any event reaches an ML system, validate it for missing fields, timestamp anomalies and schema deviations. Catching data drift at ingestion is far cheaper than diagnosing detection failures after a real incident or after an attacker has already moved laterally. Apply governance discipline to security data, not just business data. Lineage tracking, validation rules and version-controlled schemas belong in security pipelines as much as they belong in financial reporting pipelines. Security telemetry is a critical business asset and should be managed accordingly. The AI-powered security tools in your stack are capable of delivering real value against modern threats. But that capability is entirely contingent on the quality, consistency and freshness of the data flowing into them. Before your organization invests another dollar in model tuning or platform upgrades, ask a harder and more productive question: When did anyone last audit the pipelines those models actually depend on? This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Security leaders have been on a spending sprint. The global AI in cybersecurity market is valued at $44 billion in 2026 and is projected to reach $213 billion by 2034, a trajectory that reflects genuine belief that machine learning will close the gap between the volume of threats and the capacity of human analysts. That belief is not wrong. What is wrong is where most organizations focus when the tools stop working. When AI-driven detection underperforms, the instinct is to tune the algorithm, retrain the model or push the vendor for a better product. The real culprit, in most cases, is sitting upstream in the data pipelines long before any model ever sees an event. Fragmented telemetry, inconsistent schemas and stale behavioral baselines are quietly degrading the performance of AI security systems across the enterprise. Fixing the algorithm without fixing the data is like recalibrating a scale while the input keeps changing. The tool sprawl problem nobody talks about at the data level Most large enterprises are not working with clean, unified security data. They are working with decades of accumulated infrastructure decisions. Research shows the average enterprise runs 83 different security products from 29 separate vendors, and SOC teams absorb nearly 3,000 alerts per day, with 63 percent going unaddressed. Each of those tools generates its own telemetry in its own format, with its own field naming conventions, timestamp standards and metadata schemas. Human analysts develop an intuition for navigating that inconsistency. Machine learning models do not. A behavioral detection model trained to correlate authentication events across your identity platform, your endpoint agent and your cloud access broker will produce unreliable results if those three tools call the same field three different names. The model is not broken. It is being fed structurally incoherent data and asked to find patterns in the noise. What schema drift actually costs you This is where the problem becomes invisible and expensive. Schema drift, the gradual mutation of data formats across security pipelines over time, rarely triggers an alert. Log formats change when vendors push updates. New telemetry sources add fields that did not previously exist. Identity platforms rename attributes without notifying the security engineering team. Over months, the statistical patterns that trained your behavioral detection models no longer match the data those models are receiving in production. The downstream effects are exactly what most CISOs are already experiencing: Elevated false positive rates, analyst fatigue and detection gaps that only become visible after an incident. What most security leaders do not realize is that those symptoms trace back to the data layer, not the algorithm layer. Gartner projects that through 2026, organizations will abandon 60 percent of AI projects due to insufficient data quality, and the pattern is playing out in security operations as visibly as anywhere else. Stale baselines are an attacker advantage The data freshness problem is underappreciated as a security risk. Behavioral AI models build baselines from historical activity. In fast-changing enterprise environments, those baselines go stale faster than most security teams recognize. The shift to hybrid work changed access patterns dramatically. Cloud adoption changed which resources users interact with and when. Mergers and acquisitions introduce new user populations with entirely different behavioral profiles. When AI models evaluate today’s activity against baselines built from a workforce and infrastructure that no longer exist, the results are predictable: Legitimate access triggers anomaly alerts, and sophisticated attackers who study baseline patterns can blend in precisely because the model’s assumptions have not kept up with the environment. IBM research on data quality costs puts the average annual cost of poor data quality at $12.9 million per organization. In a security context, that figure does not capture the incident response costs, regulatory exposure or reputational damage that follow from a detection failure rooted in bad data architecture. The organizational gap that keeps this problem in place The reason this issue persists is structural. Data pipelines are typically managed by data or infrastructure engineering teams. Detection models are owned by SOC analysts or threat intelligence teams. The AI systems that sit between those two functions often belong to neither. When detection quality drops, security teams tune parameters. Engineering teams focus on pipeline cost and availability. Nobody owns the analytical consistency of the data flowing through the system, because no one’s job description covers that specific gap. This is a leadership problem before it is a technical one. CISOs who want AI security tools to perform as advertised need to close that ownership gap and treat security telemetry with the same rigor applied to other business-critical data assets. Three priorities for security leaders Addressing this does not require a platform replacement or a multi-year transformation program. It requires deliberate attention to three areas: Standardize telemetry schemas across your security stack. A unified schema, even an imperfect one, gives machine learning models a consistent foundation. Establish naming conventions for common fields, normalize timestamp formats and document deviations when vendors cannot comply. This is not a one-time project. It is ongoing governance. Build data quality monitoring into every ingestion pipeline. Before any event reaches an ML system, validate it for missing fields, timestamp anomalies and schema deviations. Catching data drift at ingestion is far cheaper than diagnosing detection failures after a real incident or after an attacker has already moved laterally. Apply governance discipline to security data, not just business data. Lineage tracking, validation rules and version-controlled schemas belong in security pipelines as much as they belong in financial reporting pipelines. Security telemetry is a critical business asset and should be managed accordingly. The AI-powered security tools in your stack are capable of delivering real value against modern threats. But that capability is entirely contingent on the quality, consistency and freshness of the data flowing into them. Before your organization invests another dollar in model tuning or platform upgrades, ask a harder and more productive question: When did anyone last audit the pipelines those models actually depend on? This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Poorly segmented networks and weak security controls continue to undercut security organizations’ ability to identify and contain attacks, giving attackers free rein after initial compromise, according to a recent study based on real-world enterprise security telemetry. Zero Networks’ 2026 Lateral Movement Exposure Report — based on analysis of 54 trillion activities across 312 live enterprise environments — found that more than 80% of enterprise servers are reachable from anywhere inside the network. The study found that 87% of enterprise servers accept inbound Remote Desktop Protocol (RDP) or SSH (Secure Shell) connections from broad internal sources, giving attackers wide access pathways once inside the network. Furthermore, 78% of enterprise servers are reachable via SMB (Server Message Block) or WinRM (Windows Remote Management) — networking protocols attackers commonly exploit to achieve lateral movement as part of ransomware or other attacks. In addition, 43% of internal authentication traffic still relies on NTLM (New Technology Lan Manager), a legacy protocol frequently abused for credential relay and privilege escalation attacks. And 12% of organizations maintain direct user-to-server administrative pathways, meaning a single compromised employee device can provide immediate access to high-value systems. “These findings perfectly align with the reality our threat hunters at Huntress see on the front lines every day,” Dray Agha, senior manager of security operations at managed detection and response firm Huntress, tells CSO. “Most network perimeters are hard on the outside but lose that hostility and become flat on the inside network.” The accessibility of most enterprise servers from inside compromised network means attackers have little need for sophisticated zero-day exploits once they breach the perimeter. “They [attackers] are simply ‘living off the land’ using the exact same administrative tools and open pathways (like RDP and SMB) that IT teams use,” Agha adds. Robby Winchester, chief global professional services officer at cybersecurity firm SpecterOps, also says Zero Networks’ findings are “right on point with what we typically observe.” “On nearly every red team and penetration test we’ve conducted, our testers have achieved lateral movement,” Winchester explains. “Using tools like BloodHound show us that attack paths are pervasive and hard to eliminate without visibility, underscoring how hard it is to prevent lateral movement.” Interconnected by design At issue is the fact that security teams have spent years strengthening the perimeter while accepting a significant degree of implicit trust within the network. But moving away from this approach is far from trivial, says David Sancho, senior threat researcher at Trend Micro. “The uncomfortable reality is that many enterprise environments remain highly interconnected by design,” Sancho says. “RDP, SMB, SSH, and WinRM exist because administrators need to get work done.” Legacy protocols such as NTLM persist because replacing them can be operationally challenging but replacing these aging technologies is nonetheless advisable because their presence makes it easier for attackers to dive deeper into compromised networks. Still, Sancho notes that broad exposure does not automatically equate to widespread exploitation in all circumstances. “Reachability indicates potential blast radius, not a certainty of compromise,” he explains. “At the same time, the findings highlight an ongoing operational challenge: balancing security with usability.” Moreover, Sancho adds, “restricting administrative pathways, retiring legacy protocols, and implementing stronger segmentation are all sensible measures, but they are often difficult to execute in complex environments built over decades.” Dhruv Datta, founder and co-CTO at GolfWiz AI, also sees reachable servers as only one aspect of the wider problem of enterprise security resilience. “A reachable server may still be protected by identity controls, endpoint monitoring, access policies, or other safeguards,” Datta tells CSO. “The practical risk also depends on the privileges an attacker has gained, the controls around each protocol, and how quickly suspicious activity is detected.” Still, defenders must do more to limit where an attacker can move to stand any chance of protecting sensitive systems, argues Joe Brinkley, director of offensive security research at penetration testing as a services firm Cobalt. This requirement is becoming even more pressing with the rising use of automated and AI-driven lateral movement. “Organizations must pivot away from a strategy of pure detection and prioritize deterministic containment through micro-segmentation and strict, identity-driven least privilege,” Brinkley advises. Countermeasures Internal reachability of sensitive systems creates major ransomware and privilege escalation risks. Simply focusing on improving perimeter defences is wholly inadequate. Mitigating the path to attack and making life harder for attackers involves a combination of improved network segmentation, identity controls, red-team testing, and tighter separation of privileged access. View the full article

Poorly segmented networks and weak security controls continue to undercut security organizations’ ability to identify and contain attacks, giving attackers free rein after initial compromise, according to a recent study based on real-world enterprise security telemetry. Zero Networks’ 2026 Lateral Movement Exposure Report — based on analysis of 54 trillion activities across 312 live enterprise environments — found that more than 80% of enterprise servers are reachable from anywhere inside the network. The study found that 87% of enterprise servers accept inbound Remote Desktop Protocol (RDP) or SSH (Secure Shell) connections from broad internal sources, giving attackers wide access pathways once inside the network. Furthermore, 78% of enterprise servers are reachable via SMB (Server Message Block) or WinRM (Windows Remote Management) — networking protocols attackers commonly exploit to achieve lateral movement as part of ransomware or other attacks. In addition, 43% of internal authentication traffic still relies on NTLM (New Technology Lan Manager), a legacy protocol frequently abused for credential relay and privilege escalation attacks. And 12% of organizations maintain direct user-to-server administrative pathways, meaning a single compromised employee device can provide immediate access to high-value systems. “These findings perfectly align with the reality our threat hunters at Huntress see on the front lines every day,” Dray Agha, senior manager of security operations at managed detection and response firm Huntress, tells CSO. “Most network perimeters are hard on the outside but lose that hostility and become flat on the inside network.” The accessibility of most enterprise servers from inside compromised network means attackers have little need for sophisticated zero-day exploits once they breach the perimeter. “They [attackers] are simply ‘living off the land’ using the exact same administrative tools and open pathways (like RDP and SMB) that IT teams use,” Agha adds. Robby Winchester, chief global professional services officer at cybersecurity firm SpecterOps, also says Zero Networks’ findings are “right on point with what we typically observe.” “On nearly every red team and penetration test we’ve conducted, our testers have achieved lateral movement,” Winchester explains. “Using tools like BloodHound show us that attack paths are pervasive and hard to eliminate without visibility, underscoring how hard it is to prevent lateral movement.” Interconnected by design At issue is the fact that security teams have spent years strengthening the perimeter while accepting a significant degree of implicit trust within the network. But moving away from this approach is far from trivial, says David Sancho, senior threat researcher at Trend Micro. “The uncomfortable reality is that many enterprise environments remain highly interconnected by design,” Sancho says. “RDP, SMB, SSH, and WinRM exist because administrators need to get work done.” Legacy protocols such as NTLM persist because replacing them can be operationally challenging but replacing these aging technologies is nonetheless advisable because their presence makes it easier for attackers to dive deeper into compromised networks. Still, Sancho notes that broad exposure does not automatically equate to widespread exploitation in all circumstances. “Reachability indicates potential blast radius, not a certainty of compromise,” he explains. “At the same time, the findings highlight an ongoing operational challenge: balancing security with usability.” Moreover, Sancho adds, “restricting administrative pathways, retiring legacy protocols, and implementing stronger segmentation are all sensible measures, but they are often difficult to execute in complex environments built over decades.” Dhruv Datta, founder and co-CTO at GolfWiz AI, also sees reachable servers as only one aspect of the wider problem of enterprise security resilience. “A reachable server may still be protected by identity controls, endpoint monitoring, access policies, or other safeguards,” Datta tells CSO. “The practical risk also depends on the privileges an attacker has gained, the controls around each protocol, and how quickly suspicious activity is detected.” Still, defenders must do more to limit where an attacker can move to stand any chance of protecting sensitive systems, argues Joe Brinkley, director of offensive security research at penetration testing as a services firm Cobalt. This requirement is becoming even more pressing with the rising use of automated and AI-driven lateral movement. “Organizations must pivot away from a strategy of pure detection and prioritize deterministic containment through micro-segmentation and strict, identity-driven least privilege,” Brinkley advises. Countermeasures Internal reachability of sensitive systems creates major ransomware and privilege escalation risks. Simply focusing on improving perimeter defences is wholly inadequate. Mitigating the path to attack and making life harder for attackers involves a combination of improved network segmentation, identity controls, red-team testing, and tighter separation of privileged access. View the full article

GitHub continues to be a scintillating target for attackers because it sits in the middle of the software supply chain and gives threat actors three things they crave: source code, secrets, and automated pipelines to run amok in. Datadog Security Research has been tracking what it calls a “sustained pattern” of GitHub API abuse over the past several months that seeks to map organizations and their members. While individually these requests are “unremarkable,” they become dangerous when they move across environments for weeks at a time, and, worse, progress to full-out cloning. The biggest challenge is that they blend into normal API usage patterns. GitHub has been a goldmine for criminals looking to breach organizations because many development lifecycles are insecure, said David Shipley of Beauceron Security. Typically, threat actors are after API keys and cloud secrets. “Now with everyone being pushed to do more, faster, with AI agents coding, the treasure trove of secrets is likely even bigger,” he said. “In short, to steal a line from a previous gold rush of the analog era, ‘there’s gold in them thar hills.'” Scott Miserendino, CTO at security and compliance company DataBee, agreed. “Github is the most popular source code repository for both open-source and enterprise projects,” he said. “Its sheer volume of projects, along with being home to some of the most popular and widely used software, make it a target.” He noted that intellectual property theft such as the unauthorized cloning of private repositories can be used to gain use of proprietary software or find vulnerabilities that can be exploited. A second popular attack involves searching for repositories containing default credentials to popular software. Using them, attackers may develop and test assaults on accounts that are present in production environments or come installed by default on certain appliances. And, Datadog senior security engineer Julie Agnes Sparks wrote in a blog post, “the activity is not a single actor. Rather, it’s a blend of custom automated scanner tools, opportunistic abuse of leaked credentials, and coordinated networks of burner (ghost) accounts.” A simple but effective way to map GitHub users Sparks explained that a “large share” of GitHub’s API surface can be reached without authentication; it is public by design. Requests against APIs typically produce standard HTTP 200 responses. This means a threat actor can build detailed maps of organizations, their public repositories, their members, who they follow, their starred repos, and projects they interact with. This traffic blends into normal API usage and thus does not seem suspicious, she said. Furthermore, GitHub only collects geolocation data when a user interacts with private repositories, recording who they are and what access token they used, not when they interact with external resources. This limits geolocation and VPN/proxy-based attribution. Typically, threat actors have performed automated scraping with custom or legitimate-sounding user agents, taking advantage of GitHub “ghost” accounts, profiles created anywhere from two to five years ago and left dormant. This is an attractive method because, Sparks noted, “an account with a multi-year history reads as more legitimate than one registered the same week it starts scraping.” Typically, these accounts are used for a “burst” of just one to three weeks across many enterprises at once, then usage stops. The researchers identified more than 50 ghost accounts across multiple user agents, clustered into families with names like user432023, user412023, or kobalt*. Some campaigns did use the legitimate accounts of GitHub users who had inadvertently posted their OAuth tokens or personal access tokens (PATs), or have had their endpoints compromised or exposed in other ways. Attackers use a mix of data exfiltration agents with names like GitHub-Company-Scraper, GitHub-Scraper-Tool/1.0., and GitHubAnalytics/1.5,designed to blend into normal data analysis traffic. The bulk of requests target the open source query language /graphql, which is “well suited” for bulk queries across enterprises, users, and repositories, Sparks noted. Normal REST endpoints are used for org-mapping. The focus of the campaigns was “narrow and consistent,” and the concern “lies in the aggregate,” Sparks said. In isolation, requests target public repositories without authentication and return successful responses. This rarely produces “meaningful access” into an enterprise’s repositories. But a group of accounts moving in sync across shared GitHub accounts with versioned, custom tooling over a period of weeks represents more troubling and systematic behavior. She cited one event in which dozens of distinct, legitimate, but compromised GitHub user accounts made API requests to a single organization within a window of only a few minutes, although in that case the attack failed, because they targeted private repository commit paths. How enterprises can protect their GitHub environments Sparks pointed out that these behaviors can be hunted for and detected “if you are watching the right fields,” such as those identifying the user agent, token type, autonomous system number (ASN), or attempted action. “User agents, event activity, and actor names are vital clues to unauthorized activity in your environment,” Sparks emphasized. She suggested reviewing unusual user agent behavior across GitHub audit logs, particularly for those that extend to private repositories where the platform also captures the IP address, actor name, and programmatic access type. Enterprises should also enable GitHub audit log streaming, baseline user agents, and perform proactive threat hunting. Most importantly, she said, they should develop detections unique to their GitHub organization, noting, “It’s important to know what normal looks like in your environment.” Simply put, added Miserendino, enterprises should be following security best practices, including enabling multi-factor authentication (MFA) on all accounts, performing periodic user access reviews, removing any unused or unneeded accounts, and scanning repositories for credentials stored in plaintext rather than in a secret store. This article originally appeared on InfoWorld. View the full article

GitHub continues to be a scintillating target for attackers because it sits in the middle of the software supply chain and gives threat actors three things they crave: source code, secrets, and automated pipelines to run amok in. Datadog Security Research has been tracking what it calls a “sustained pattern” of GitHub API abuse over the past several months that seeks to map organizations and their members. While individually these requests are “unremarkable,” they become dangerous when they move across environments for weeks at a time, and, worse, progress to full-out cloning. The biggest challenge is that they blend into normal API usage patterns. GitHub has been a goldmine for criminals looking to breach organizations because many development lifecycles are insecure, said David Shipley of Beauceron Security. Typically, threat actors are after API keys and cloud secrets. “Now with everyone being pushed to do more, faster, with AI agents coding, the treasure trove of secrets is likely even bigger,” he said. “In short, to steal a line from a previous gold rush of the analog era, ‘there’s gold in them thar hills.'” Scott Miserendino, CTO at security and compliance company DataBee, agreed. “Github is the most popular source code repository for both open-source and enterprise projects,” he said. “Its sheer volume of projects, along with being home to some of the most popular and widely used software, make it a target.” He noted that intellectual property theft such as the unauthorized cloning of private repositories can be used to gain use of proprietary software or find vulnerabilities that can be exploited. A second popular attack involves searching for repositories containing default credentials to popular software. Using them, attackers may develop and test assaults on accounts that are present in production environments or come installed by default on certain appliances. And, Datadog senior security engineer Julie Agnes Sparks wrote in a blog post, “the activity is not a single actor. Rather, it’s a blend of custom automated scanner tools, opportunistic abuse of leaked credentials, and coordinated networks of burner (ghost) accounts.” A simple but effective way to map GitHub users Sparks explained that a “large share” of GitHub’s API surface can be reached without authentication; it is public by design. Requests against APIs typically produce standard HTTP 200 responses. This means a threat actor can build detailed maps of organizations, their public repositories, their members, who they follow, their starred repos, and projects they interact with. This traffic blends into normal API usage and thus does not seem suspicious, she said. Furthermore, GitHub only collects geolocation data when a user interacts with private repositories, recording who they are and what access token they used, not when they interact with external resources. This limits geolocation and VPN/proxy-based attribution. Typically, threat actors have performed automated scraping with custom or legitimate-sounding user agents, taking advantage of GitHub “ghost” accounts, profiles created anywhere from two to five years ago and left dormant. This is an attractive method because, Sparks noted, “an account with a multi-year history reads as more legitimate than one registered the same week it starts scraping.” Typically, these accounts are used for a “burst” of just one to three weeks across many enterprises at once, then usage stops. The researchers identified more than 50 ghost accounts across multiple user agents, clustered into families with names like user432023, user412023, or kobalt*. Some campaigns did use the legitimate accounts of GitHub users who had inadvertently posted their OAuth tokens or personal access tokens (PATs), or have had their endpoints compromised or exposed in other ways. Attackers use a mix of data exfiltration agents with names like GitHub-Company-Scraper, GitHub-Scraper-Tool/1.0., and GitHubAnalytics/1.5,designed to blend into normal data analysis traffic. The bulk of requests target the open source query language /graphql, which is “well suited” for bulk queries across enterprises, users, and repositories, Sparks noted. Normal REST endpoints are used for org-mapping. The focus of the campaigns was “narrow and consistent,” and the concern “lies in the aggregate,” Sparks said. In isolation, requests target public repositories without authentication and return successful responses. This rarely produces “meaningful access” into an enterprise’s repositories. But a group of accounts moving in sync across shared GitHub accounts with versioned, custom tooling over a period of weeks represents more troubling and systematic behavior. She cited one event in which dozens of distinct, legitimate, but compromised GitHub user accounts made API requests to a single organization within a window of only a few minutes, although in that case the attack failed, because they targeted private repository commit paths. How enterprises can protect their GitHub environments Sparks pointed out that these behaviors can be hunted for and detected “if you are watching the right fields,” such as those identifying the user agent, token type, autonomous system number (ASN), or attempted action. “User agents, event activity, and actor names are vital clues to unauthorized activity in your environment,” Sparks emphasized. She suggested reviewing unusual user agent behavior across GitHub audit logs, particularly for those that extend to private repositories where the platform also captures the IP address, actor name, and programmatic access type. Enterprises should also enable GitHub audit log streaming, baseline user agents, and perform proactive threat hunting. Most importantly, she said, they should develop detections unique to their GitHub organization, noting, “It’s important to know what normal looks like in your environment.” Simply put, added Miserendino, enterprises should be following security best practices, including enabling multi-factor authentication (MFA) on all accounts, performing periodic user access reviews, removing any unused or unneeded accounts, and scanning repositories for credentials stored in plaintext rather than in a secret store. This article originally appeared on InfoWorld. View the full article

A prompt injection attack can trick GitHub’s preview Agentic Workflows into retrieving content from private repositories and publishing it publicly, exposing a broader risk as enterprises deploy AI agents with privileged access to software development environments, according to new research from Noma Security. The AI security company detailed the attack, dubbed GitLost, in a blog post, saying an unauthenticated attacker could exploit GitHub’s preview Agentic Workflows by submitting a crafted GitHub issue to a public repository. If the AI agent has read access to private repositories within the same organization, it can retrieve sensitive information and publish it in a public comment, the company said. GitHub Agentic Workflows combine GitHub Actions with AI models such as Claude or GitHub Copilot, allowing developers to define workflows in Markdown. At the same time, AI agents read issues, invoke tools, and perform tasks on their behalf. “What will happen when the GitHub agent reads something it should not trust?” Noma researcher Sasi Levi wrote. “The answer is a textbook indirect prompt-injection attack, the kind of attack that quietly sends private data to anyone on the internet.” Public GitHub issue became the attack vector According to Noma, the attack did not rely on stolen credentials, malware, or software vulnerabilities. Instead, an attacker embedded hidden instructions within a GitHub Issue submitted to a public repository. Because the AI agent interpreted the issue as instructions rather than untrusted content, it accessed a private repository and posted its contents back to the public issue, the blog post added. “The root cause of the GitLost vulnerability is, by now, a familiar one in agentic AI systems: prompt injection,” Levi wrote. “In this specific case, any malicious actor can create a GitHub Issue and, in the issue body, hide commands in plain English that GitHub’s agent will follow.” To demonstrate the attack, the researchers created what appeared to be a routine GitHub Issue requesting documentation updates. Once the workflow was triggered, the AI agent retrieved the README file from a private repository and published its contents in a publicly visible comment. The researchers also said they bypassed GitHub’s prompt-based guardrails by making a minor wording change that caused the AI agent to comply with instructions it had previously rejected. GitHub did not immediately respond to a request for comment. Research points to a broader AI agent risk Noma said GitLost illustrates a broader architectural challenge for AI agents rather than a flaw unique to GitHub. “The issue is not that GitHub’s AI agent is unusually insecure,” Levi wrote. “The issue is that any AI agent with access to both untrusted external content and sensitive internal resources can become an unintended bridge between the two if trust boundaries are not enforced.” Independent cybersecurity researcher and red teamer Vibhum Dubey said the findings expose a more fundamental issue than prompt injection alone. “This isn’t prompt injection in the abstract—this is GitHub shipping agent permissions before shipping agent security,” Dubey said. “The vulnerability exposes that AI agents operate on a service account permission model, not a user permission model. That’s an architectural assumption security teams made before considering LLMs as an attack vector.” According to Dubey, the prompt injection itself is almost secondary. “What’s dangerous is that trust boundaries exist in GitHub’s data model but nowhere in the agent’s execution context,” he said. “The agent doesn’t ‘know’ a repository is private. It just sees ‘accessible.’ As more organizations deploy agents, we’re accumulating these invisible permission gaps.” Experts urge tighter controls on AI agents Dubey said organizations should rethink how AI agents are granted permissions rather than treating the issue primarily as a monitoring challenge. “Three concrete fixes: Agents get explicit repository whitelists, not broad service account access. All user inputs, including commit messages, PR descriptions, and issues, should be validated before reaching the LLM. And have an emergency kill-switch ready,” he said. “Most teams can disable a compromised API key. Can you disable a rogue agent?” Dubey said GitLost demonstrates how AI agents can effectively become an insider threat once granted broad organizational access. “The brilliance of GitLost isn’t that it fooled an AI. It’s that it weaponized GitHub’s assumption that service accounts are trustworthy,” he said. “Agents were explicitly built to bypass human judgment and operate autonomously. That’s exactly why they’re dangerous: we normalized cross-boundary operations the moment we automated them.” Noma also recommended applying least-privilege access controls, limiting AI agents’ cross-repository access, and treating GitHub Issues, pull requests, and comments as untrusted input. View the full article

A prompt injection attack can trick GitHub’s preview Agentic Workflows into retrieving content from private repositories and publishing it publicly, exposing a broader risk as enterprises deploy AI agents with privileged access to software development environments, according to new research from Noma Security. The AI security company detailed the attack, dubbed GitLost, in a blog post, saying an unauthenticated attacker could exploit GitHub’s preview Agentic Workflows by submitting a crafted GitHub issue to a public repository. If the AI agent has read access to private repositories within the same organization, it can retrieve sensitive information and publish it in a public comment, the company said. GitHub Agentic Workflows combine GitHub Actions with AI models such as Claude or GitHub Copilot, allowing developers to define workflows in Markdown. At the same time, AI agents read issues, invoke tools, and perform tasks on their behalf. “What will happen when the GitHub agent reads something it should not trust?” Noma researcher Sasi Levi wrote. “The answer is a textbook indirect prompt-injection attack, the kind of attack that quietly sends private data to anyone on the internet.” Public GitHub issue became the attack vector According to Noma, the attack did not rely on stolen credentials, malware, or software vulnerabilities. Instead, an attacker embedded hidden instructions within a GitHub Issue submitted to a public repository. Because the AI agent interpreted the issue as instructions rather than untrusted content, it accessed a private repository and posted its contents back to the public issue, the blog post added. “The root cause of the GitLost vulnerability is, by now, a familiar one in agentic AI systems: prompt injection,” Levi wrote. “In this specific case, any malicious actor can create a GitHub Issue and, in the issue body, hide commands in plain English that GitHub’s agent will follow.” To demonstrate the attack, the researchers created what appeared to be a routine GitHub Issue requesting documentation updates. Once the workflow was triggered, the AI agent retrieved the README file from a private repository and published its contents in a publicly visible comment. The researchers also said they bypassed GitHub’s prompt-based guardrails by making a minor wording change that caused the AI agent to comply with instructions it had previously rejected. GitHub did not immediately respond to a request for comment. Research points to a broader AI agent risk Noma said GitLost illustrates a broader architectural challenge for AI agents rather than a flaw unique to GitHub. “The issue is not that GitHub’s AI agent is unusually insecure,” Levi wrote. “The issue is that any AI agent with access to both untrusted external content and sensitive internal resources can become an unintended bridge between the two if trust boundaries are not enforced.” Independent cybersecurity researcher and red teamer Vibhum Dubey said the findings expose a more fundamental issue than prompt injection alone. “This isn’t prompt injection in the abstract—this is GitHub shipping agent permissions before shipping agent security,” Dubey said. “The vulnerability exposes that AI agents operate on a service account permission model, not a user permission model. That’s an architectural assumption security teams made before considering LLMs as an attack vector.” According to Dubey, the prompt injection itself is almost secondary. “What’s dangerous is that trust boundaries exist in GitHub’s data model but nowhere in the agent’s execution context,” he said. “The agent doesn’t ‘know’ a repository is private. It just sees ‘accessible.’ As more organizations deploy agents, we’re accumulating these invisible permission gaps.” Experts urge tighter controls on AI agents Dubey said organizations should rethink how AI agents are granted permissions rather than treating the issue primarily as a monitoring challenge. “Three concrete fixes: Agents get explicit repository whitelists, not broad service account access. All user inputs, including commit messages, PR descriptions, and issues, should be validated before reaching the LLM. And have an emergency kill-switch ready,” he said. “Most teams can disable a compromised API key. Can you disable a rogue agent?” Dubey said GitLost demonstrates how AI agents can effectively become an insider threat once granted broad organizational access. “The brilliance of GitLost isn’t that it fooled an AI. It’s that it weaponized GitHub’s assumption that service accounts are trustworthy,” he said. “Agents were explicitly built to bypass human judgment and operate autonomously. That’s exactly why they’re dangerous: we normalized cross-boundary operations the moment we automated them.” Noma also recommended applying least-privilege access controls, limiting AI agents’ cross-repository access, and treating GitHub Issues, pull requests, and comments as untrusted input. View the full article

Cybercriminals are exploiting India’s tax filing season with a new malware campaign that refuses to put all its eggs in one basket. Researchers at Cyderes have uncovered a sophisticated phishing operation that poses as the Indian Tax Department to deliver two remote access trojans (RATs) through a multi-stage infection chain, giving attackers persistent access to compromised systems. Indians receive fake tax assessment emails that pressure them into downloading what appears to be an official ITR utility. But the convincing government branding hides a carefully engineered infection sequence that abuses legitimate Windows binaries, DLL side-loading, in-memory execution, and process injection to gain persistent access. According to Cyderes, the operation deploys a Gh0st RAT derivative and a .NET-based implant related to the QuasarRAT/AsyncRAT family, each communicating with separate command-and-control (C2) servers. “The dual-implant design gives the attacker redundant access even if one channel is blocked or detected,” Cyderes researchers said in a blog post. A stealthy, multi-stage infection chain To avoid detection, the campaign layers its execution chain, rather than dropping malware immediately after initial access. Once the victims are lured into downloading and opening the archives posing as legitimate Income Tax Department utilities, trusted Windows executables are abused to load malicious DLLs. This allows the malware to borrow the legitimacy of signed binaries while sidestepping security controls. “The infection begins with ‘COU_ITR-1_to_4_AY2026-27.exe’, a legitimate and digitally signed binary that the attacker repurposes as a launcher,” the researchers said, adding that it is a known technique where an attacker “places a malicious library in a path the trusted binary will check first, giving the malware a clean entry point.” The campaign then runs its subsequent infection stages, which employ multiple defense-evasion techniques, including anti-analysis checks, AMSI patching, encrypted in-memory execution of .NET assemblies, and session-aware process injection into svchost.exe. The multiple attack stages include DLL sideloading, privilege checking to ensure the attack process is running with admin rights, and session-aware payload injection. Dual implants for operational resilience The campaign was particularly flagged for its deliberate use of two distinct RAT families rather than relying on a single backdoor. While one implant is based on the long-running Gh0st RAT lineage, the second belongs to the QuasarRAT/AsyncRAT ecosystem. Both provide remote administration capabilities, allowing attackers to execute commands, collect data, deploy additional payloads, and maintain long-term access to infected endpoints. Each of these RATs communicates with a dedicated command-and-control (c2) infrastructure, likely to survive detection and blocking of either during incident response. Cyderes recommended focusing on behavioral detections rather than relying solely on EDR signatures, as the campaign abuses trusted Windows components and in-memory execution. Key indicators include DLL sideloading, unexpected service creation, AMSI tampering, native processes hosting the .NET runtime, and process injection into svchost.exe. The disclosure also provided a detailed set of IOCs, including file hashes, malicious domains, C2 infrastructure, and host artifacts associated with both RAT families. View the full article

Cybercriminals are exploiting India’s tax filing season with a new malware campaign that refuses to put all its eggs in one basket. Researchers at Cyderes have uncovered a sophisticated phishing operation that poses as the Indian Tax Department to deliver two remote access trojans (RATs) through a multi-stage infection chain, giving attackers persistent access to compromised systems. Indians receive fake tax assessment emails that pressure them into downloading what appears to be an official ITR utility. But the convincing government branding hides a carefully engineered infection sequence that abuses legitimate Windows binaries, DLL side-loading, in-memory execution, and process injection to gain persistent access. According to Cyderes, the operation deploys a Gh0st RAT derivative and a .NET-based implant related to the QuasarRAT/AsyncRAT family, each communicating with separate command-and-control (C2) servers. “The dual-implant design gives the attacker redundant access even if one channel is blocked or detected,” Cyderes researchers said in a blog post. A stealthy, multi-stage infection chain To avoid detection, the campaign layers its execution chain, rather than dropping malware immediately after initial access. Once the victims are lured into downloading and opening the archives posing as legitimate Income Tax Department utilities, trusted Windows executables are abused to load malicious DLLs. This allows the malware to borrow the legitimacy of signed binaries while sidestepping security controls. “The infection begins with ‘COU_ITR-1_to_4_AY2026-27.exe’, a legitimate and digitally signed binary that the attacker repurposes as a launcher,” the researchers said, adding that it is a known technique where an attacker “places a malicious library in a path the trusted binary will check first, giving the malware a clean entry point.” The campaign then runs its subsequent infection stages, which employ multiple defense-evasion techniques, including anti-analysis checks, AMSI patching, encrypted in-memory execution of .NET assemblies, and session-aware process injection into svchost.exe. The multiple attack stages include DLL sideloading, privilege checking to ensure the attack process is running with admin rights, and session-aware payload injection. Dual implants for operational resilience The campaign was particularly flagged for its deliberate use of two distinct RAT families rather than relying on a single backdoor. While one implant is based on the long-running Gh0st RAT lineage, the second belongs to the QuasarRAT/AsyncRAT ecosystem. Both provide remote administration capabilities, allowing attackers to execute commands, collect data, deploy additional payloads, and maintain long-term access to infected endpoints. Each of these RATs communicates with a dedicated command-and-control (c2) infrastructure, likely to survive detection and blocking of either during incident response. Cyderes recommended focusing on behavioral detections rather than relying solely on EDR signatures, as the campaign abuses trusted Windows components and in-memory execution. Key indicators include DLL sideloading, unexpected service creation, AMSI tampering, native processes hosting the .NET runtime, and process injection into svchost.exe. The disclosure also provided a detailed set of IOCs, including file hashes, malicious domains, C2 infrastructure, and host artifacts associated with both RAT families. View the full article

I’ve spent two years doing incident response and threat intel, and the one habit I’d keep if I had to give up every other is also the most boring. I don’t act on a piece of intelligence until I’ve checked it against the thing it claims to describe. It’s slow. It’s tedious. Almost nobody does it, because checking costs the exact time the feed was supposed to save. So, we read the report, nod and move on. That works fine most weeks. The weeks it doesn’t are the ones I remember, and the one I keep coming back to started with a feed that sounded completely sure of itself and had it backwards. A cluster the feed got wrong I was mapping infrastructure behind a loader operation, sweeping a single service port through a commercial platform. It handed back a cluster of hosts; all tagged the same thing: Chalubo RAT. The tag didn’t stop me. The metadata did. Every host in the cluster carried one first-seen date, down to the day. Real infrastructure never looks that clean. Operators stand hosts up a few at a time, over weeks, whenever they get to it. A whole cluster sharing one first-seen date almost always means you’re looking at the day the feed’s pipeline ingested the batch, not the day anyone actually saw those hosts live. So now I had two things I didn’t trust: The family name and the too-perfect date. Easiest way to settle it was to close the feed and go look at the malware. Chalubo is a Linux botnet. It brute-forces SSH and throws DDoS traffic. What I had in front of me was a Windows shellcode loader, a DonutLoader variant, the kind of thing that sits at the front of a ransomware intrusion. Different platform, different job. Calling one the other isn’t a near miss. It’s a category error. So, I detonated it in an isolated lab, captured the traffic, mapped the C2 and pulled the config. It spoke a protocol of its own: Payload delivery on one custom channel, a steganographic beacon on a second, across a ten-host cluster, with a config format that had nothing to do with Chalubo. The reason for the bad tag turned out to be dull. The feed’s rule for that port keyed on the port plus a loose pattern, my loader tripped it and the label propagated across the whole batch with the ingest date stapled on. This isn’t a knock on the vendor. Fingerprinting malware families across the entire internet is genuinely hard. The damage starts one step later, with whatever the reader does with that tag. Believe it, and you spend the week hardening against a Linux DDoS botnet while a Windows ransomware precursor sits quietly on your network. Wrong threat. Wrong priorities. The feed didn’t just come up empty. It pointed the response in the wrong direction, with total confidence and a familiar logo on it. Nothing about the tag looked wrong. The file was the only thing that said otherwise. The same gap, in a federal advisory For a while I filed this as a commercial-feed problem, the tax you pay for buying intel from a vendor cutting corners at scale. Then the same shape turned up in one of the best sources any of us get for free. Earlier this year I spent some time inside the joint FBI and CISA advisory on Ghost, or Cring depending on who’s naming it, a ransomware crew that’s hit organizations in seventy-plus countries. Like everyone, I opened the PDF first. Its indicator table is literally headed “MD5 File Hashes”: 14 samples, each pinned to an MD5 and nothing else. MD5’s been broken for years. It’s the whole reason detection moved to SHA-256, and an MD5-only indicator doesn’t drop cleanly into half the tooling defenders actually run. Then I opened the other copy of the same advisory. It doesn’t only ship as a PDF. There’s a machine-readable STIX bundle too, the format built to feed straight into a TIP or a SIEM. Same advisory, same code, different file. Six of those fourteen samples carried SHA-256 in the STIX, with SHA-1 and fuzzy hashes next to them, none of it in the PDF table. The stronger indicators were in the official release the entire time, sitting in the file almost nobody opens. Read the PDF like most people do, and you walk away with weaker detections than whoever opened the STIX, and nothing tells you there’s a difference. That same bundle cut the other way too, and this is the part worth slowing down on. Down in its relationships sat a threat-actor object naming APT41, Winnti, Wicked Panda, wired to several of the Ghost indicators. The advisory’s text never says APT41. It goes out of its way to call the attribution “variable over time.” Pull on the thread and it falls apart: No vendor has ever tied Ghost to APT41, and the object looks like automated enrichment, not a human analyst’s call. The STIX isn’t lying to you. The problem is subtler. Feed it into your TIP and you’ve quietly inherited a nation-state attribution nobody actually made. One file was missing good data. The other was carrying data nobody vetted. You only catch either by looking. And it’s not a one-country quirk. A while later I reversed a Go backdoor, GAMYBEAR, the one UAC-0241 pointed at Ukrainian schools and state bodies, documented in a CERT-UA advisory. Good report. It nailed the behavior. But the actual loader gave up more than fifteen binary-level corrections to what the advisory had: A persistence mechanism attributed to the wrong component, a broken TLS implementation and a handful of indicators that only held once I checked them against the real sample instead of the writeup. That’s the kind of detail that keeps a detection alive after the operator renames the file. Commercial vendor. Federal agency. Foreign CERT. Three sources, all accurate, all carrying something other than the full truth in the copy most people read. What I do differently now The lesson wasn’t trust intelligence more or trust it less. It’s narrower than that. An indicator is a claim, and a claim gets checked before you stake a defense on it, most of all when it’s the advisory covering your own organization, because that’s the one whose blind spots quietly become yours. It’s cheap enough to make routine. If I were standing up a detection program next week, three things would be in from day one. Treat any automated family label as a guess until something specific backs it. A row of identical first-seen dates is a fact about a pipeline, not a record of an attack. When an advisory ships in more than one format, open the machine-readable copy and don’t stop at the PDF, because the structured file tends to hold both the stronger indicators and the unvetted ones, and you want to see both. And for anything that actually matters, run a live sample through your own stack before you call it covered. The gap between an indicator and a detection that fires is exactly where attackers like to live. I still reach for all three kinds of source every week, and I’ll defend every one of them. They were never the problem. The checking was always the cheap part. Assuming I could skip it was the expensive one. A report is where the work starts. Not where it stops. The full teardowns behind these three cases are published on GitHub: The DonutLoader protocol analysis, the Ghost detection content and the GAMYBEAR reversing notes and rule, each in its own repository. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

I’ve spent two years doing incident response and threat intel, and the one habit I’d keep if I had to give up every other is also the most boring. I don’t act on a piece of intelligence until I’ve checked it against the thing it claims to describe. It’s slow. It’s tedious. Almost nobody does it, because checking costs the exact time the feed was supposed to save. So, we read the report, nod and move on. That works fine most weeks. The weeks it doesn’t are the ones I remember, and the one I keep coming back to started with a feed that sounded completely sure of itself and had it backwards. A cluster the feed got wrong I was mapping infrastructure behind a loader operation, sweeping a single service port through a commercial platform. It handed back a cluster of hosts; all tagged the same thing: Chalubo RAT. The tag didn’t stop me. The metadata did. Every host in the cluster carried one first-seen date, down to the day. Real infrastructure never looks that clean. Operators stand hosts up a few at a time, over weeks, whenever they get to it. A whole cluster sharing one first-seen date almost always means you’re looking at the day the feed’s pipeline ingested the batch, not the day anyone actually saw those hosts live. So now I had two things I didn’t trust: The family name and the too-perfect date. Easiest way to settle it was to close the feed and go look at the malware. Chalubo is a Linux botnet. It brute-forces SSH and throws DDoS traffic. What I had in front of me was a Windows shellcode loader, a DonutLoader variant, the kind of thing that sits at the front of a ransomware intrusion. Different platform, different job. Calling one the other isn’t a near miss. It’s a category error. So, I detonated it in an isolated lab, captured the traffic, mapped the C2 and pulled the config. It spoke a protocol of its own: Payload delivery on one custom channel, a steganographic beacon on a second, across a ten-host cluster, with a config format that had nothing to do with Chalubo. The reason for the bad tag turned out to be dull. The feed’s rule for that port keyed on the port plus a loose pattern, my loader tripped it and the label propagated across the whole batch with the ingest date stapled on. This isn’t a knock on the vendor. Fingerprinting malware families across the entire internet is genuinely hard. The damage starts one step later, with whatever the reader does with that tag. Believe it, and you spend the week hardening against a Linux DDoS botnet while a Windows ransomware precursor sits quietly on your network. Wrong threat. Wrong priorities. The feed didn’t just come up empty. It pointed the response in the wrong direction, with total confidence and a familiar logo on it. Nothing about the tag looked wrong. The file was the only thing that said otherwise. The same gap, in a federal advisory For a while I filed this as a commercial-feed problem, the tax you pay for buying intel from a vendor cutting corners at scale. Then the same shape turned up in one of the best sources any of us get for free. Earlier this year I spent some time inside the joint FBI and CISA advisory on Ghost, or Cring depending on who’s naming it, a ransomware crew that’s hit organizations in seventy-plus countries. Like everyone, I opened the PDF first. Its indicator table is literally headed “MD5 File Hashes”: 14 samples, each pinned to an MD5 and nothing else. MD5’s been broken for years. It’s the whole reason detection moved to SHA-256, and an MD5-only indicator doesn’t drop cleanly into half the tooling defenders actually run. Then I opened the other copy of the same advisory. It doesn’t only ship as a PDF. There’s a machine-readable STIX bundle too, the format built to feed straight into a TIP or a SIEM. Same advisory, same code, different file. Six of those fourteen samples carried SHA-256 in the STIX, with SHA-1 and fuzzy hashes next to them, none of it in the PDF table. The stronger indicators were in the official release the entire time, sitting in the file almost nobody opens. Read the PDF like most people do, and you walk away with weaker detections than whoever opened the STIX, and nothing tells you there’s a difference. That same bundle cut the other way too, and this is the part worth slowing down on. Down in its relationships sat a threat-actor object naming APT41, Winnti, Wicked Panda, wired to several of the Ghost indicators. The advisory’s text never says APT41. It goes out of its way to call the attribution “variable over time.” Pull on the thread and it falls apart: No vendor has ever tied Ghost to APT41, and the object looks like automated enrichment, not a human analyst’s call. The STIX isn’t lying to you. The problem is subtler. Feed it into your TIP and you’ve quietly inherited a nation-state attribution nobody actually made. One file was missing good data. The other was carrying data nobody vetted. You only catch either by looking. And it’s not a one-country quirk. A while later I reversed a Go backdoor, GAMYBEAR, the one UAC-0241 pointed at Ukrainian schools and state bodies, documented in a CERT-UA advisory. Good report. It nailed the behavior. But the actual loader gave up more than fifteen binary-level corrections to what the advisory had: A persistence mechanism attributed to the wrong component, a broken TLS implementation and a handful of indicators that only held once I checked them against the real sample instead of the writeup. That’s the kind of detail that keeps a detection alive after the operator renames the file. Commercial vendor. Federal agency. Foreign CERT. Three sources, all accurate, all carrying something other than the full truth in the copy most people read. What I do differently now The lesson wasn’t trust intelligence more or trust it less. It’s narrower than that. An indicator is a claim, and a claim gets checked before you stake a defense on it, most of all when it’s the advisory covering your own organization, because that’s the one whose blind spots quietly become yours. It’s cheap enough to make routine. If I were standing up a detection program next week, three things would be in from day one. Treat any automated family label as a guess until something specific backs it. A row of identical first-seen dates is a fact about a pipeline, not a record of an attack. When an advisory ships in more than one format, open the machine-readable copy and don’t stop at the PDF, because the structured file tends to hold both the stronger indicators and the unvetted ones, and you want to see both. And for anything that actually matters, run a live sample through your own stack before you call it covered. The gap between an indicator and a detection that fires is exactly where attackers like to live. I still reach for all three kinds of source every week, and I’ll defend every one of them. They were never the problem. The checking was always the cheap part. Assuming I could skip it was the expensive one. A report is where the work starts. Not where it stops. The full teardowns behind these three cases are published on GitHub: The DonutLoader protocol analysis, the Ghost detection content and the GAMYBEAR reversing notes and rule, each in its own repository. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

With change a constant, cybersecurity professionals looking to improve their careers can benefit from the latest insights into employers’ needs. Data from Foote Partners on the skills and certification most in demand today may provide helpful signposts. Analyzing more than 660 certifications as part of its 2Q 2026 “IT Skills Demand and Pay Trends Report,” Foote Partners calculated the most valuable IT security certifications to pursue right now based on two dimensions. The first, the average pay premium, measures the difference in pay between IT pros with a particular credential and those without it. The second, market value increase, measures the increase in pay gains over the past six months. Together, average pay premium and market value increase can give cybersecurity pros a starting point in deciding which certification to pursue for more pay. Apart from considering their overall professional goals, security professionals should consider each certification’s training and exam costs, whether vendor-specific or vendor-neutral, and the lateral or vertical role opportunities it may open. Here are the top 13 certifications paying higher premiums today in descending order. GIAC Security Expert (GSE) The GIAC Security Expert (GSE) portfolio certification is for security leaders wishing to prove their status as a top information security practitioner by showing they have offensive and defensive skills and hands-on practical skills. Available for more than 15 years, the GSE is considered one of the broadest and deepest cybersecurity certifications. To earn the certification, candidates must complete any six practitioner certifications and any four applied knowledge certifications. GIAC allows candidates to customize the certification to fit their expertise and career. Candidates can also build their certification over any amount of time as along as the required certifications within the portfolio remain active. Practitioner certification exams are 2-5 hours in length, depending on the specific certification attempt, and applied knowledge certification exams are 4 hours in length. Training fees: Some training is offered in affiliation with SANS Institute and costs $8,780. Exam Fees: Because you need 10 certifications to achieve the GSE prices vary significantly. If you already hold a GIAC Certified Forensic Analyst (GCFA), the cost of one of the required certifications drops from $1,299 to $499. Most required certifications are priced at either $999 or $1,299 per attempt, though they can cost up to $11,190. GIAC Security Professional (GSP) The GIAC Security Professional (GSP) is designed to demonstrate the holder’s depth and breadth of information security knowledge. Launched approximately two years, this newer certification is the halfway point to the GSE. Customization of the certification is allowed, and to achieve it a candidate must complete any three practitioner certifications and any two applied knowledge certifications. Candidates can also build their certification over any amount of time as along as the required certifications within the portfolio remain active. Practitioner Certification exams are 2-5 hours in length, depending on the specific certification attempt, and Applied Knowledge Certification exams are 4 hours in length. Training fees: Some training is offered in affiliation with SANS Institute and costs $8,780. Exam Fees: Because you need five certifications to achieve the GSP prices vary significantly. If you already hold a GIAC Security Essentials (GSEC), the cost of one of the required certifications drops from $1,299 to $499. Most certifications required are priced at either $999 or $1,299 per attempt, though certification can cost up to $5,595. Microsoft Certified Azure Cybersecurity Architect Expert Those who earn the Microsoft Certified: Cybersecurity Architect Expert credential are able to translate a cybersecurity strategy into capabilities that protect the assets, business, and operations of an organization. Through the certification process, candidates learn to design, guide the implementation of, and maintain security solutions that follow zero-trust principles and best practices. You’ll also be able to design solutions for governance, risk, and compliance (GRC), security operations, and security posture management.​ As a prerequisite, candidate must have earned one of the following: Microsoft Certified: Azure Security Engineer Associate, Microsoft Certified: Identity and Access Administrator Associate, Microsoft Certified: Security Operations Analyst Associate certification. Training fees: Self-paced training is available from the course’s page and free of charge. There is also an option to find an instructor-led training with pricing starting at $1,300. Exam Fees: The exam costs $165 and Microsoft offers free practice assessments. Certificate of Cloud Security Knowledge (CCSK) As a certificate and not a certification — an important distinction — the Cloud Security Alliance (CSA) positions its Certificate of Cloud Security Knowledge as the foundation for future credentials and upskilling in the sector. From this perspective, the CCSK is helpful for cybersecurity analysts, compliance managers, security engineers, architects, and administrators. This vendor-neutral certificate has been recently updated and covers topics in zero trust, DevSecOps, cloud telemetry and security analytics, artificial intelligence, and more. CCSK offers a variety of training modalities, including an exam prep kit, instructor-led classes offered virtually and in person, and an online self-paced option. Candidates must score at least 80% on the exam, randomly pulling 60 multiple-choice questions from a test bank. Training fees: Prices vary based on modality. A self-paced course and exam bundle costs $795, and online, instructor-led training begins at$995. Exam fees: The exam costs $445, though discounts are available for corporate members, andUS military veterans can take it for free. Certified in Risk and Information Systems Control (CRISC) Administered by ISACA, theCertified in Risk and Information Systems Control certification provides candidates with training across four domains: corporate IT governance, risk assessment, risk response and reporting, and technology and security. CRISC is ideal for candidates who want to enhance and optimize business resilience and risk management across their organization. The exam consists of 150 questions across the four domains. Since ISACA began offering CRISC in 2010, more than 23,000 people have obtained the certification. ISACA claims 52% of certificate holders experienced on-the-job improvement, and CRISC is the “4th top-paying certification worldwide.” To qualify for CRISC, candidates must adhere to a code of professional ethics and have three years of work experience in risk assessment and risk response and reporting. On passing the exam, candidates must submit 20 CPE credits annually and120 continuing professional education (CPE) hours every three years to maintain their CRISC. Training fees: ISACA offers three resources: anonline review course, $895; a review manual inprint ordigital, $139; and anannual subscription to a 833-question test bank, $399. Discounts are available for ISACA members. Exam fees: $575, ISACA members; $760 for non-members; plus $50 application fee. Certified Information Systems Auditor (CISA) The Information Systems Audit and Control Association (ISACA)’s CISA is geared toward IT auditors who wish to upskill or earn a pay boost. According to ISACA, 70% of CISA holders report on-the-job improvement, and another 22% receive a raise. The course covers five domains: information systems auditing, implementation, and operations; protection of information assets; and IT governance. Thefour-hour exam consists of 150 multiple-choice questions, and candidates must earn 450 on ISACA’s scaled scoring system, with 800 representing a perfect score. Tomaintain their CISA, certification holders must take 20 CPE credits annually and 120 over three years through conferences, volunteering, on-demand learning, and other methods as well as paying maintenance fee. To qualify, you must have five years of experience in IT or IS audit, control, assurance, or security. You can apply for an experience waiver for up to three years. Training fees: ISACA offers four resources: anonline review course for $895, anannual subscription to a question bank for $399, and a print or digitalreview manual for $139. Discounts are available for ISACA members. Exam fees: $575, members; $760, non-members; plus $50 application fee. Certified Information Systems Security Professional (CISSP) CISSP is a generalist cert from ISC2 aimed at security pros who have already established a strong track record. Advanced-level analysts interested in getting CISSP certified will need to know all the ins and outs of security and risk management, asset security, operations, security assessment and testing, and more. The CISSP certification requires five years of full-time experience in at least two of its eight domains. The exam is adaptive, ranging from 100 to 150 questions, including multiple-choice and advanced items of varying formats. Candidates need to score 700 points out of 1,000 to pass the exam. Training fees:Online self-paced training fees start at $595 and can cost up to $1,993;online instructor-led bootcamp costs $2,880. Exam fee:$749 Certified Secure Software Lifecycle Professional (CSSLP) This ISC2 certification helps cyber pros build their career by training them to better incorporate security practices throughout software development phases. The CSSLP exam evaluates experience across eight domains: secure software concepts; secure software; lifecycle management; secure software requirements; secure software architecture and design; secure software implementation; secure software testing; secure software deployment, operations, maintenance; secure software supply chain. Those wishing to acquire the CSSLP must have four years of paid work experience as a software development lifecycle professional in one or more of the eight domains. Training fees:Online self-paced training fees start at $550 and can cost up to $1,718; online instructor-led bootcamp costs $2,650. Exam fee: $599 Check Point Certified Security Master (CCSM) To become a Check Point Certified Security Master (CCSM) security professionals must have an active Certified Security Expert (CCSE) and mast have completed two subsequent Check Point Specialist accreditations. CCSM validates advanced expertise in configuring, deploying, and troubleshooting Check Point solutions. Check Point certifications are valid for 24 months. Training fees: Training for CCSE is $3,500 Exam fee: The fee for CCSE is $300 GIAC Experienced Cybersecurity Specialist (GX-CS) The Experienced Cybersecurity Specialist (GX-CS) sits within the applied knowledge certifications with GIAC. The certification is for practitioners to show their qualifications for advanced, hands-on IT systems roles across cybersecurity. Its intent is to demonstrate the candidate can navigate evolving real-world threats. The certification covers five areas: network security analysis and tools; evaluation of Windows and Linux OS security; advanced security tools and techniques; common attacks and defenses; and implementing overall cybersecurity and information security. The GX-CS is for GSEC holders who acquired additional experience — the GSEC exam costs $999, and SANS Institute offers training for GSEC. Training fees: There are a few related affiliate training programs provided by SANS, each costing approximately $9,000. Exam fee: $499 for those with an active GSEC; otherwise $1,299. OffSec Certified Professional (OSCP+) To earn theOffSec Certified Professional certification, candidates must complete the affiliated course, PEN-200: Penetration Testing with Kali Linux, and pass the subsequent exam. The course covers 20 plus modules, including information gathering, vulnerability scanning, encryption and cryptography, Active Directory and AWS exploitation, and more. Certificate holders will have shown mastery of penetration testing methodologies ideal for new roles, such as an ethical hacker, incident responder, or threat hunter. The OSCP+ exam is entirely hands-on, and test-takers must compromise systems within a lab environment. OffSec does not enforce any prerequisites but recommends candidates be familiar with TCP/IP networking, scripting in Bash and Python, and Linux and Windows, which they can learn through itsNetwork Penetration Testing Essentials Learning Path. Training and exam fees: OffSec bundles the course and exam for $1,749 and as a yearly subscription that includes access to one 200 or 300-level course, the associated labs, and two exam attempts for $2,749 annually. OffSec Experienced Penetration Tester (OSEP) TheOffSec Experienced Penetration Tester is ideal for penetration testers and ethical hackers who need more advanced techniques to sharpen offensive skills against modern enterprise defenses. Across more than 20 modules, the certification introduces these professionals to advanced offensive techniques, EDR and AV evasion, advanced Windows offensive security and more. During the two-day proctored exam, professionals must connect to a lab environment via a VPN and compromise multiple machines within a network through several possible attack paths. To pass, professionals must achieve the objective stated within the control panel or score atleast 100 points — 10 points are awarded for every flag found in a local.txt or proof.txt file. Professionals who earn their OSEP can also obtain theirOSCE³ Certification to demonstrate their mastery of offensive security. They would also need to pass the exams for WEB-300: Advanced Web Attacks and Exploitation and EXP-301: Windows User Mode Exploit Development, after which the OSCE³ is automatically awarded. While there are no formal prerequisites for OSEP, OffSec recommends candidates take thePEN-200: Penetration Testing with Kali Linux or have a strong foundation in operating systems, networking, and scripting. Training and exam fees: OffSec bundles the course and exam for $1,749, and as a yearly subscription that includes access to one 200 or 300-level course, the associated labs, and two exam attempts for $2,749 annually. OffSec Exploitation Expert (OSEE) OffSec’s Offensive Security Exploitation Expert is a vendor-specific certification, focusing on advanced Windows exploitation, with OffSec deeming it its most challenging certification. As a penetration testing course, the material dives deep into topics such as advanced heap manipulations and disarming WDEG mitigations. Certificate holders can identify problematic code in Windows operating systems and develop exploits. For the practical exam, candidates must complete a comprehensive penetration test of software and create an exploit within a lab environment — all within 72 hours. To qualify, you must have experience debugging, developing Windows exploits, and using the following technologies: WinDBG, x86_64, IDA Pro, and basic C/C++ programming. OffSec recommends completing its300-level certifications before OSEE. Training and exam fees: OffSec offers only instructor-led, in-person training. Enterprises should inquire for more information. View the full article

With change a constant, cybersecurity professionals looking to improve their careers can benefit from the latest insights into employers’ needs. Data from Foote Partners on the skills and certification most in demand today may provide helpful signposts. Analyzing more than 660 certifications as part of its 2Q 2026 “IT Skills Demand and Pay Trends Report,” Foote Partners calculated the most valuable IT security certifications to pursue right now based on two dimensions. The first, the average pay premium, measures the difference in pay between IT pros with a particular credential and those without it. The second, market value increase, measures the increase in pay gains over the past six months. Together, average pay premium and market value increase can give cybersecurity pros a starting point in deciding which certification to pursue for more pay. Apart from considering their overall professional goals, security professionals should consider each certification’s training and exam costs, whether vendor-specific or vendor-neutral, and the lateral or vertical role opportunities it may open. Here are the top 13 certifications paying higher premiums today in descending order. GIAC Security Expert (GSE) The GIAC Security Expert (GSE) portfolio certification is for security leaders wishing to prove their status as a top information security practitioner by showing they have offensive and defensive skills and hands-on practical skills. Available for more than 15 years, the GSE is considered one of the broadest and deepest cybersecurity certifications. To earn the certification, candidates must complete any six practitioner certifications and any four applied knowledge certifications. GIAC allows candidates to customize the certification to fit their expertise and career. Candidates can also build their certification over any amount of time as along as the required certifications within the portfolio remain active. Practitioner certification exams are 2-5 hours in length, depending on the specific certification attempt, and applied knowledge certification exams are 4 hours in length. Training fees: Some training is offered in affiliation with SANS Institute and costs $8,780. Exam Fees: Because you need 10 certifications to achieve the GSE prices vary significantly. If you already hold a GIAC Certified Forensic Analyst (GCFA), the cost of one of the required certifications drops from $1,299 to $499. Most required certifications are priced at either $999 or $1,299 per attempt, though they can cost up to $11,190. GIAC Security Professional (GSP) The GIAC Security Professional (GSP) is designed to demonstrate the holder’s depth and breadth of information security knowledge. Launched approximately two years, this newer certification is the halfway point to the GSE. Customization of the certification is allowed, and to achieve it a candidate must complete any three practitioner certifications and any two applied knowledge certifications. Candidates can also build their certification over any amount of time as along as the required certifications within the portfolio remain active. Practitioner Certification exams are 2-5 hours in length, depending on the specific certification attempt, and Applied Knowledge Certification exams are 4 hours in length. Training fees: Some training is offered in affiliation with SANS Institute and costs $8,780. Exam Fees: Because you need five certifications to achieve the GSP prices vary significantly. If you already hold a GIAC Security Essentials (GSEC), the cost of one of the required certifications drops from $1,299 to $499. Most certifications required are priced at either $999 or $1,299 per attempt, though certification can cost up to $5,595. Microsoft Certified Azure Cybersecurity Architect Expert Those who earn the Microsoft Certified: Cybersecurity Architect Expert credential are able to translate a cybersecurity strategy into capabilities that protect the assets, business, and operations of an organization. Through the certification process, candidates learn to design, guide the implementation of, and maintain security solutions that follow zero-trust principles and best practices. You’ll also be able to design solutions for governance, risk, and compliance (GRC), security operations, and security posture management.​ As a prerequisite, candidate must have earned one of the following: Microsoft Certified: Azure Security Engineer Associate, Microsoft Certified: Identity and Access Administrator Associate, Microsoft Certified: Security Operations Analyst Associate certification. Training fees: Self-paced training is available from the course’s page and free of charge. There is also an option to find an instructor-led training with pricing starting at $1,300. Exam Fees: The exam costs $165 and Microsoft offers free practice assessments. Certificate of Cloud Security Knowledge (CCSK) As a certificate and not a certification — an important distinction — the Cloud Security Alliance (CSA) positions its Certificate of Cloud Security Knowledge as the foundation for future credentials and upskilling in the sector. From this perspective, the CCSK is helpful for cybersecurity analysts, compliance managers, security engineers, architects, and administrators. This vendor-neutral certificate has been recently updated and covers topics in zero trust, DevSecOps, cloud telemetry and security analytics, artificial intelligence, and more. CCSK offers a variety of training modalities, including an exam prep kit, instructor-led classes offered virtually and in person, and an online self-paced option. Candidates must score at least 80% on the exam, randomly pulling 60 multiple-choice questions from a test bank. Training fees: Prices vary based on modality. A self-paced course and exam bundle costs $795, and online, instructor-led training begins at$995. Exam fees: The exam costs $445, though discounts are available for corporate members, andUS military veterans can take it for free. Certified in Risk and Information Systems Control (CRISC) Administered by ISACA, theCertified in Risk and Information Systems Control certification provides candidates with training across four domains: corporate IT governance, risk assessment, risk response and reporting, and technology and security. CRISC is ideal for candidates who want to enhance and optimize business resilience and risk management across their organization. The exam consists of 150 questions across the four domains. Since ISACA began offering CRISC in 2010, more than 23,000 people have obtained the certification. ISACA claims 52% of certificate holders experienced on-the-job improvement, and CRISC is the “4th top-paying certification worldwide.” To qualify for CRISC, candidates must adhere to a code of professional ethics and have three years of work experience in risk assessment and risk response and reporting. On passing the exam, candidates must submit 20 CPE credits annually and120 continuing professional education (CPE) hours every three years to maintain their CRISC. Training fees: ISACA offers three resources: anonline review course, $895; a review manual inprint ordigital, $139; and anannual subscription to a 833-question test bank, $399. Discounts are available for ISACA members. Exam fees: $575, ISACA members; $760 for non-members; plus $50 application fee. Certified Information Systems Auditor (CISA) The Information Systems Audit and Control Association (ISACA)’s CISA is geared toward IT auditors who wish to upskill or earn a pay boost. According to ISACA, 70% of CISA holders report on-the-job improvement, and another 22% receive a raise. The course covers five domains: information systems auditing, implementation, and operations; protection of information assets; and IT governance. Thefour-hour exam consists of 150 multiple-choice questions, and candidates must earn 450 on ISACA’s scaled scoring system, with 800 representing a perfect score. Tomaintain their CISA, certification holders must take 20 CPE credits annually and 120 over three years through conferences, volunteering, on-demand learning, and other methods as well as paying maintenance fee. To qualify, you must have five years of experience in IT or IS audit, control, assurance, or security. You can apply for an experience waiver for up to three years. Training fees: ISACA offers four resources: anonline review course for $895, anannual subscription to a question bank for $399, and a print or digitalreview manual for $139. Discounts are available for ISACA members. Exam fees: $575, members; $760, non-members; plus $50 application fee. Certified Information Systems Security Professional (CISSP) CISSP is a generalist cert from ISC2 aimed at security pros who have already established a strong track record. Advanced-level analysts interested in getting CISSP certified will need to know all the ins and outs of security and risk management, asset security, operations, security assessment and testing, and more. The CISSP certification requires five years of full-time experience in at least two of its eight domains. The exam is adaptive, ranging from 100 to 150 questions, including multiple-choice and advanced items of varying formats. Candidates need to score 700 points out of 1,000 to pass the exam. Training fees:Online self-paced training fees start at $595 and can cost up to $1,993;online instructor-led bootcamp costs $2,880. Exam fee:$749 Certified Secure Software Lifecycle Professional (CSSLP) This ISC2 certification helps cyber pros build their career by training them to better incorporate security practices throughout software development phases. The CSSLP exam evaluates experience across eight domains: secure software concepts; secure software; lifecycle management; secure software requirements; secure software architecture and design; secure software implementation; secure software testing; secure software deployment, operations, maintenance; secure software supply chain. Those wishing to acquire the CSSLP must have four years of paid work experience as a software development lifecycle professional in one or more of the eight domains. Training fees:Online self-paced training fees start at $550 and can cost up to $1,718; online instructor-led bootcamp costs $2,650. Exam fee: $599 Check Point Certified Security Master (CCSM) To become a Check Point Certified Security Master (CCSM) security professionals must have an active Certified Security Expert (CCSE) and mast have completed two subsequent Check Point Specialist accreditations. CCSM validates advanced expertise in configuring, deploying, and troubleshooting Check Point solutions. Check Point certifications are valid for 24 months. Training fees: Training for CCSE is $3,500 Exam fee: The fee for CCSE is $300 GIAC Experienced Cybersecurity Specialist (GX-CS) The Experienced Cybersecurity Specialist (GX-CS) sits within the applied knowledge certifications with GIAC. The certification is for practitioners to show their qualifications for advanced, hands-on IT systems roles across cybersecurity. Its intent is to demonstrate the candidate can navigate evolving real-world threats. The certification covers five areas: network security analysis and tools; evaluation of Windows and Linux OS security; advanced security tools and techniques; common attacks and defenses; and implementing overall cybersecurity and information security. The GX-CS is for GSEC holders who acquired additional experience — the GSEC exam costs $999, and SANS Institute offers training for GSEC. Training fees: There are a few related affiliate training programs provided by SANS, each costing approximately $9,000. Exam fee: $499 for those with an active GSEC; otherwise $1,299. OffSec Certified Professional (OSCP+) To earn theOffSec Certified Professional certification, candidates must complete the affiliated course, PEN-200: Penetration Testing with Kali Linux, and pass the subsequent exam. The course covers 20 plus modules, including information gathering, vulnerability scanning, encryption and cryptography, Active Directory and AWS exploitation, and more. Certificate holders will have shown mastery of penetration testing methodologies ideal for new roles, such as an ethical hacker, incident responder, or threat hunter. The OSCP+ exam is entirely hands-on, and test-takers must compromise systems within a lab environment. OffSec does not enforce any prerequisites but recommends candidates be familiar with TCP/IP networking, scripting in Bash and Python, and Linux and Windows, which they can learn through itsNetwork Penetration Testing Essentials Learning Path. Training and exam fees: OffSec bundles the course and exam for $1,749 and as a yearly subscription that includes access to one 200 or 300-level course, the associated labs, and two exam attempts for $2,749 annually. OffSec Experienced Penetration Tester (OSEP) TheOffSec Experienced Penetration Tester is ideal for penetration testers and ethical hackers who need more advanced techniques to sharpen offensive skills against modern enterprise defenses. Across more than 20 modules, the certification introduces these professionals to advanced offensive techniques, EDR and AV evasion, advanced Windows offensive security and more. During the two-day proctored exam, professionals must connect to a lab environment via a VPN and compromise multiple machines within a network through several possible attack paths. To pass, professionals must achieve the objective stated within the control panel or score atleast 100 points — 10 points are awarded for every flag found in a local.txt or proof.txt file. Professionals who earn their OSEP can also obtain theirOSCE³ Certification to demonstrate their mastery of offensive security. They would also need to pass the exams for WEB-300: Advanced Web Attacks and Exploitation and EXP-301: Windows User Mode Exploit Development, after which the OSCE³ is automatically awarded. While there are no formal prerequisites for OSEP, OffSec recommends candidates take thePEN-200: Penetration Testing with Kali Linux or have a strong foundation in operating systems, networking, and scripting. Training and exam fees: OffSec bundles the course and exam for $1,749, and as a yearly subscription that includes access to one 200 or 300-level course, the associated labs, and two exam attempts for $2,749 annually. OffSec Exploitation Expert (OSEE) OffSec’s Offensive Security Exploitation Expert is a vendor-specific certification, focusing on advanced Windows exploitation, with OffSec deeming it its most challenging certification. As a penetration testing course, the material dives deep into topics such as advanced heap manipulations and disarming WDEG mitigations. Certificate holders can identify problematic code in Windows operating systems and develop exploits. For the practical exam, candidates must complete a comprehensive penetration test of software and create an exploit within a lab environment — all within 72 hours. To qualify, you must have experience debugging, developing Windows exploits, and using the following technologies: WinDBG, x86_64, IDA Pro, and basic C/C++ programming. OffSec recommends completing its300-level certifications before OSEE. Training and exam fees: OffSec offers only instructor-led, in-person training. Enterprises should inquire for more information. View the full article

A critical vulnerability in the Kernel-based Virtual Machine (KVM) module of the Linux kernel allows attackers with root access in a guest VM to execute arbitrary code on the host system. This violates the most important security boundary that cloud providers and enterprises rely on to isolate sensitive processes on servers. The vulnerability, tracked as CVE-2026-53359, stems from a use-after-free memory bug in the shadow MMU emulation of KVM on x86 CPU architecture. According to Hyunwoo Kim, the researcher who discovered it, the flaw has been present in the Linux kernel code for the past 16 years and is the first KVM guest-to-host escape vulnerability that works on both Intel and AMD CPUs. Hyunwoo dubbed the flaw Januscape and reported it through Google’s kvmCTF, a vulnerability reward program that pays up to $250,000 for a full VM escape demonstrated in KVM, which Google uses in Google Cloud as well as Android infrastructure. “With guest-side actions alone, an attacker can compromise the host that runs their VM,” the research wrote in an advisory on GitHub. “For example, an attacker who has rented just a single instance on a public cloud could panic the host kernel to take down every other tenant VM on the same physical machine (DoS), or run code with root privilege on the host to take over the host and all the guests on it (RCE).” On some Linux distributions, including Red Hat Enterprise Linux (RHEL), the vulnerability can also be exploited for local privilege escalation inside the guest VM because the /dev/kvm device is world-writable (0666). The Januscape flaw was patched by the Linux kernel maintainers on June 16, but users should check for updates from their respective distribution maintainers. Because Linux has a large ecosystem of variants and support channels, it could take a while for the patches to trickle down to all existing flavors. VM escape proof of concept Hyunwoo released a proof-of-concept that demonstrates the kernel panic and denial-of-service condition, but he has held back on releasing the full VM escape exploit for now. Even though he said in his detailed write-up that achieving a full escape is difficult because the primitive is tricky, it doesn’t mean other researchers or malicious attackers wouldn’t be able to develop a working exploit. Januscape only works on servers with Intel and AMD CPUs, but Hyunwoo also disclosed a different KVM guest-to-host escape vulnerability dubbed ITScape (CVE-2026-46316) last month that works on ARM64 architecture. The researcher, who uses the moniker V4bel online, is also the person who developed the Dirty Frag Linux privilege escalation exploit earlier this year by combining the Dirty Pipe (CVE-2022-0847) and Copy Fail (CVE-2026-31431) kernel page-cache corruption techniques. VM escape exploits are among the most dangerous attacks to enterprise environments, which often use virtualization to isolate legacy applications and services that are no longer supported by their developers or whose compromise could pose a big risk to the entire infrastructure. Attackers have exploited VM escape vulnerabilities in the wild before, particularly targeting the VMware ESXi hypervisor, and there are even APT groups that specialize in targeting virtualized environments. View the full article

Palo Alto Networks’ security division, Unit 42, is warning of yet another campaign targeting Microsoft Teams users. The new campaign begins with Teams users receiving an email asking if they would like to participate in a survey. If they open the attached PDF file, they will shortly thereafter receive a voice call purporting to be from Microsoft Support. The fake support representative then attempts to gain permission to install a remote access tool, and in the process, Ether RAT — a Trojan that gives the scammers full access to the affected computer — is also installed. After that, it’s a simple matter to steal sensitive data and files from users, reports Bleeping Computer. In other words, there’s every reason to be on guard against both email surveys and support calls. View the full article

The Gentlemen ransomware underscores a challenge many CISOs face: stopping attackers after they gain an initial foothold. Researchers say the malware can spread across enterprise networks using legitimate Windows management tools while simultaneously attempting to weaken security and recovery systems. A report from Picus Security shows the malware combines self-propagation with the abuse of trusted administrative tools and attempts to impair recovery systems before encryption begins. The report follows a technical analysis of the encryptor published by Microsoft Threat Intelligence in late May. The Gentlemen is a ransomware-as-a-service operation written in Go and obfuscated with Garble. The group first emerged around mid-2025 as a closed operation and began offering its platform to affiliates in September 2025. The Picus report focuses on a Windows-targeting encryptor, but other researchers have reported broader Gentlemen tooling aimed at Linux and VMware ESXi environments. The group has been observed in attacks on organizations in sectors including education, transportation, healthcare, and financial services across North America, South America, Europe, Africa, and Asia. Its self-propagation capability is the most significant feature for enterprise defenders. When enabled, the malware can enumerate reachable systems, stage its binary through an SMB share, and attempt up to 21 remote execution operations against each target. Those methods include PsExec, WMIC, scheduled tasks, Windows services, PowerShell remoting, and WMI process creation. The redundancy is intended to improve the chances that at least one method will succeed, allowing the malware to continue spreading through the network. Before encryption, The Gentlemen attempts to weaken the victim environment by disabling Microsoft Defender, deleting shadow copies, and removing forensic artifacts. It also stops services linked to databases, backup tools, endpoint protection, and virtualization platforms, a tactic that can make recovery harder once encryption begins. The encryptor uses a hybrid Curve25519 and XChaCha20 encryption scheme with unique keys for each file, Picus said. In the sample cited by Picus, encrypted files were appended with the .umc16h extension, though other researchers have observed different extensions in separate Gentlemen campaigns. The group also uses double extortion tactics, threatening to leak stolen data if victims do not pay. Lateral movement and identity risks Once attackers gain an initial foothold, compromised identities and excessive privileges often matter more than the malware itself, said Sakshi Grover, senior research manager for Cybersecurity Services Research at IDC Asia/Pacific. “The Gentlemen reinforces a trend IDC has been observing across modern ransomware operations: attackers are increasingly exploiting trusted administrative tools, compromised identities, and excessive privileges rather than relying solely on sophisticated malware or zero-day exploits,” Grover said. For CISOs, that means ransomware defense cannot be judged only by whether the initial compromise is blocked. Organizations also need to limit how far an attacker can move once inside the network. Grover said security leaders should start with stronger controls around privileged accounts, including phishing-resistant MFA and tighter limits on who can access critical systems. Identity governance and network segmentation should then be used to reduce the number of paths an attacker can take once inside the environment. Those controls should be tested through adversary emulation and attack path testing, rather than assumed to be effective because they exist on paper. Backups and endpoint tools The Gentlemen’s attempt to impair security and recovery tools highlights a common weakness in enterprise ransomware planning, according to analysts. “Many organizations continue to equate deploying backup platforms or endpoint detection solutions with being ransomware resilient,” Grover said. “However, sophisticated ransomware increasingly targets these very capabilities before encryption begins.” Grover added that CISOs should test whether recovery systems remain usable during an active compromise, including backups that are meant to be immutable and endpoint tools protected against tampering. Those exercises should also account for the possibility that Active Directory or key security management consoles may be unavailable. The most dangerous assumption is that having backups is the same as being able to recover from ransomware, according to Devashri Datta, a cybersecurity researcher. “If your backups live on the same flat network or depend on the same compromised Active Directory credentials, they are not a recovery asset; they are part of the attack surface,” she said. Datta also pointed to over-reliance on endpoint detection and response tools. ESET researchers have linked The Gentlemen to a mature EDR-killer toolset, including variants that abuse vulnerable drivers to disrupt security software. An operational resilience problem The group’s model reflects the continued industrialization of ransomware-as-a-service, a framework that Datta said lowers the technical barrier for affiliates by pairing encryption with standardized evasion and propagation layers. For CISOs, the question is not whether backup and endpoint tools are in place, but whether they still work after attackers have gained administrative access. Datta said organizations need to assess exposure across identity infrastructure, Active Directory, cloud services, and backup environments. The priority, she said, is to reduce the paths available to attackers and prove, through regular resilience exercises, that the organization can contain an intrusion before it becomes a wider outage. View the full article

At some point, every security leader gets asked a version of the same question: Are we good? It tends to arrive when something is at stake and the person asking needs to know they can rely on the answer. I learned what that question really means at a firm I was with earlier in my career. We had received intelligence that threat actors were preparing to go after financial services firms over the holidays, counting on skeleton staffing and slower response times. We had procedures for exactly that kind of heightened alert, and we ran them. The moment that stayed with me came in a hallway. The head of business stopped me and asked, plainly, “Are we good?” He was not asking for a status report on our controls or a walkthrough of our incident response plan. He wanted a seasoned leader to look at him and say, with conviction, that we were good. That instinct, the need for someone accountable enough to say “we’re good” and mean it, sits at the center of a debate the cybersecurity industry keeps having: Whether the CISO role has become unsustainable. The list of responsibilities continues to grow. Security leaders are expected to oversee cyber resilience, regulatory compliance, third-party risk, business continuity, AI governance, incident response and an ever-more-complex threat landscape. Boards, regulators, customers and investors simultaneously demand greater visibility into cyber risk than ever before. The conclusion many people draw from this expansion is that the traditional CISO role can no longer work. If no single person can realistically master every domain that falls under modern cybersecurity, perhaps the role itself has become obsolete. I believe the opposite is true. The modern CISO is disappearing from one version of itself and re-emerging as something larger. It is undergoing the same evolution the CFO role experienced over the last two decades. Historically, CFOs were viewed primarily as financial operators. Their responsibilities centered on accounting, reporting, controls, audits and budgeting. As businesses grew larger, more global, more regulated and more dependent on technology, that model changed. The CFO evolved from a finance specialist into a strategic executive responsible for shaping enterprise-wide decisions. McKinsey documented this shift, finding that the number of functions reporting to CFOs had expanded significantly, and that business leaders had come to see them as critical drivers of change across the enterprise, not just stewards of the balance sheet. Nobody looked at that expanding mandate and concluded the CFO role was becoming irrelevant. They recognized that finance had become more important to the business. The same thing is happening in cybersecurity. For years, security was treated as a technical discipline operating on the periphery of the organization. Today, a significant cyber incident can halt operations, disrupt revenue, trigger regulatory scrutiny, damage customer trust and move markets. Cyber risk has become business risk, and that shift fundamentally changes what a CISO is for. Security leaders increasingly sit on enterprise risk committees alongside their peers, and regulators are paying far closer attention to how security is built into the design of products and systems from the outset. Both are signs that security has moved from a back-office function into the room where business risk gets decided. The data reflects how much the role has already changed. According to Splunk’s 2026 CISO Report, nearly all CISOs now count AI governance and risk management among their core responsibilities. Seventy-eight percent report personal liability concerns tied to security incidents, up from 56% just a year ago. The role now carries individual legal exposure alongside operational accountability. That is a description of an executive function, full stop. Modern security leaders are now expected to help boards understand risk, participate in strategic planning, navigate regulatory obligations, oversee resilience programs and establish governance around emerging technologies like artificial intelligence. These responsibilities extend well beyond traditional security operations, and the job has grown considerably faster than the organizational structures supporting it. Some companies have responded by building larger, more specialized security leadership teams. Microsoft’s Secure Future Initiative is the most prominent example. The company established a Cybersecurity Governance Council led by a Global CISO, with over a dozen Deputy CISOs appointed across major security domains including engineering, AI, cloud services, gaming and government systems. It represents one of the largest security transformations in the industry, involving thousands of engineers and a governance structure built to coordinate security across a genuinely sprawling organization. Some observers read structures like this as evidence that the traditional CISO model is breaking down. Look closer and you see the opposite. Microsoft expanded the organization supporting security leadership rather than dismantling it. Centralized accountability remains with a global CISO while execution is distributed across specialized leaders and teams. This is exactly what mature executive functions look like at scale. Large enterprises do not eliminate CFOs when finance grows more complex. They add controllers, treasury leaders, FP&A organizations and investor relations teams. Complexity does not eliminate executive accountability. It deepens the need for it. There is shared, organization-wide security: the SOC, vulnerability management and the other services the entire firm depends on. Then there is business-line security, led by deputy or business-unit CISOs whose job is to make sure their individual units are protected. Those embedded leaders drive requirements into the shared services and provide independent oversight of them, while staying close enough to their business to understand what it actually needs. One central executive owns the whole picture, with specialized leaders carrying it into every corner of the organization. One structural point follows directly from this: The CISO should never report to the CTO. The person accountable for security should not sit underneath the person accountable for building and shipping technology, because those two mandates can pull in different directions. Security belongs under the COO, the CRO or the CEO, where it can speak to risk independently and be heard. AI is accelerating this evolution further. Organizations are deploying autonomous systems capable of making recommendations, triggering workflows and acting at machine speed. What AI cannot do is own the decisions behind those actions. Someone still has to determine what can be delegated to machines, establish governance frameworks, define acceptable risk and answer for those choices to regulators, boards and shareholders. In most organizations, that someone is the CISO. The most practical place to start is a simple principle: every AI action should trace back to an accountable human. Framed that way, we are not delegating decisions to AI at all. We are putting machines to work while keeping a person answerable for what they do. That principle forces accountability to live somewhere specific in the organization rather than dissolving into the system. This is worth sitting with: AI may strengthen the case for executive security leadership rather than weaken it. For years, CISOs governed human behavior inside organizations. Now they govern human and machine behavior simultaneously, a mandate with no obvious ceiling. The cybersecurity industry keeps asking whether the CISO role can survive the demands being placed on it. The better question is whether organizations are adapting their leadership structures fast enough to support where the role is already heading. The future of security leadership is unlikely to be a loose collection of specialists operating without clear ownership. It will more closely resemble other mature executive functions, with specialized leaders operating under a single accountable executive who understands how risk connects to the business as a whole. As cyber risk becomes inseparable from business risk, that executive becomes indispensable. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Most software composition analysis tools read what developers declare. Insignary Clarity’s patented binary-first platform analyzes what is actually built, shipped, and deployed — including the open-source components that never appear in any manifest. Insignary, Inc., whose patented binary fingerprint technology has been cited in four Gartner research reports, today announced its recognition as a Sample Vendor for Reachability Analysis in the Gartner Hype Cycle for Secure Software Engineering, 2026. According to Gartner: “Open-source and third-party components may contain a long list of vulnerabilities, but not all of them directly impact your code base. Reachability analysis helps in triaging the vulnerabilities based on their exploitability.”*1 The urgency is clear across independent industry research. A 2024 Venafi survey of 800 security decision-makers across the U.S., U.K., Germany, and France found that 92% are concerned about AI-generated code, and 63% have considered banning it outright over security risk.*2 The U.S. National Vulnerability Database recorded more than 48,000 CVEs in 2025 — roughly 130 every day. AI coding assistants are accelerating the growth of unmanaged open-source dependencies. As organizations adopt these tools at scale, they face a widening challenge: understanding which open-source components enter production software, whether those components can be trusted, and how the resulting security and compliance risks are managed. The problem is structural. Most SCA tools read what developers declare — not what actually runs. AI-generated code, vendor libraries, and third-party binaries frequently bypass package managers and never appear in a manifest. “SBOMs are increasingly becoming a regulatory requirement around the world. However, software transparency is only as reliable as the accuracy of an SBOM itself. You cannot verify an SBOM by reading the manifest that created it. You verify an SBOM by examining the software that was actually built, shipped, and deployed. As software supply-chain regulations increasingly depend on SBOMs, the ability to validate software at the binary level becomes essential for organizations operating in regulated industries, critical infrastructure, and AI-enabled software environments.” — Taek Wan Kim, President & CEO, Insignary INSIGNARY CLARITY: BINARY-FIRST. AI-AWARE. Insignary Clarity scans both source and binary to build a complete Software Bill of Materials (SBOM) for the applications teams build, the third-party components they incorporate, and the IT infrastructure that bypasses the traditional secure development lifecycle. Key capabilities include: Binary SCA — identifies open-source components, vulnerabilities, and license obligations directly from compiled binaries, without requiring source code or package manifests AIBOM Generation — produces an AI Bill of Materials for software containing AI-generated or AI-assisted code, covering components that bypass traditional dependency declarations Reachability Analysis — determines which disclosed vulnerabilities actually reach executable code paths, enabling risk-based prioritization rather than raw CVE-count triage Continuous Vulnerability Alerting — monitors stored SBOMs against updated vulnerability databases and delivers automated alerts when newly disclosed CVEs match deployed components, without requiring a rescan “An SBOM is foundational to managing the complexity and securability of modern software deployments.”*3 RECOGNITION IN FOUR GARTNER REPORTS Insignary has been cited in four Gartner research reports*, Gartner Hype Cycle for Secure Software Engineering,2026, Gartner Hype Cycle for Application Security,2025, Gartner Scale Application Security With AI-Augmented Vulnerability Remediation,2025, and Gartner 3 Steps for Assessing an Open-Source Software Project, 2025. SUPPORTING GLOBAL SOFTWARE SUPPLY CHAIN REQUIREMENTS Insignary Clarity supports organisations meeting software supply-chain security requirements across North America and globally: U.S. Executive Order 14028 and OMB Memorandum M-26-05 — federal agencies may now independently verify vendor SBOMs rather than accepting a standard attestation form, raising the bar for all software sold into the U.S. government FDA Section 524B — every connected medical device premarket submission must include a binary-verified SBOM covering all compiled software components Canada’s Bill C-8 Critical Cyber Systems Protection Act (CCSPA), effective June 2026 — mandatory supply chain risk management for banking, telecommunications, energy, and transportation operators Additional frameworks: CISA and NSA SBOM guidance, NIST SSDF, Australia’s Information Security Manual (ISM), U.S. Connected Vehicle Rule, EU Cyber Resilience Act. TRUSTED BY GOVERNMENTS AND GLOBAL ENTERPRISES Globally, BearingPoint — one of Europe’s leading management and technology consulting firms and a strategic investor in Insignary — serves as the company’s exclusive distributor across Europe. Cybertrust Japan, another strategic investor, and its reselling partner TechMatrix drive adoption across Japanese manufacturing under a joint SBOM initiative. Customers include government organizations and global leaders across the electronics, defense, financial services, automotive, manufacturing, medical, and other technology sectors. GARTNER and Hype Cycle are trademarks of Gartner, Inc. and/or its affiliates. Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose. ABOUT INSIGNARY Insignary Inc. is a Toronto-based cybersecurity company specializing in binary composition analysis and software supply chain security. Its patented technology enables organizations to identify open-source software components, vulnerabilities, and software provenance directly from compiled binaries without requiring access to source code. The company’s flagship platform, Insignary Clarity, provides binary analysis and software composition analysis capabilities that enable organizations to verify the contents of deployed software and strengthen software supply chain governance. Insignary Clarity AIR extends this capability to the AI domain by helping organizations identify, assess, and manage risks associated with AI models, AI-generated software, and AI-driven development environments. The company serves enterprises, governments, and software vendors worldwide and is supported by strategic investors and partners including BearingPoint in Europe, Cybertrust Japan and TechMatrix in Japan, and TMA Solutions. Through its global partner ecosystem, Insignary supports software supply chain security initiatives across North America, Europe, and Asia. Website: https://insignary.com/ Full report: Gartner Hype Cycle for Secure Software Engineering, 2026 References: Gartner, Hype Cycle for Secure Software Engineering 2026 Venafi, “Machine Identity Management Development Survey,” 2024 Gartner, “Emerging Tech: A Software Bill of Materials Is Critical to Software Supply Chain Management.” Contact Principal Solutions Architect Jessica DY Lee Insignary [email protected] View the full article

Some autonomous AI agents fell victim to frauds, reinforcing how easily some high-end enterprise agents can be conned by schemes that would fool few, if any, humans, Zscaler found in a test of major LLMs. The security vendor looked at various forms of indirect prompt injection (IPI) traps and found that, whereas many models fell victim to the schemes, some of the lower-level LLMs fared better than their pricier siblings. The Zscaler testing found, for example, that four models were found to be “vulnerable”: Llama3-3-70b-instruct; Llama3-2-90b-instruct; Gemini-3-flash; and Gemini-2.5-pro. Three models were found to be “safe”: Llama4-maverick; Gemini-3.1-pro; and Gemini-3.1-flash-lite. Those results indicated that the scam resistance of Gemini-2.5-pro was seemingly weaker than that of Gemini-3.1-flash-lite. But Noah Kenney, principal consultant at Digital 520, said that there is not necessarily any valuable takeaway from that revelation, because agents constantly change behavior as they feed on new data and revise their analyzed assumptions. That means an agent that failed a specific test might very well pass the identical test an hour later, he said. “The risk of an agent is constantly changing and that can cause vastly different results. You can’t assume the results are generalizable. The test result is only at one point in time,” Kenney pointed out. Zscaler “is trying to prove a point that I don’t think the data necessarily proves.” Kenney added that having a clean “safe/vulnerable” classification is too simplistic to be useful. “That’s a binary classification. I would never recommend to a CISO to do a binary classification.” The full ZScaler blog post argued that many autonomous agents are susceptible to IPI traps. The company said it identified IPI embedded in multiple websites, where hidden instructions were designed to manipulate the behavior of an AI agent. In its internal validation across 26 LLMs, 4 models “failed to take appropriate actions,” which, it said, demonstrated “measurable real-world impact, showing that susceptibility varies by model and by the context provided to the LLM alongside the prompt.” The post added, “as AI agents become a more common interface to the web, the content itself is going to become a larger attack surface, highlighting that AI is a double-edged sword that can streamline workflows while also introducing new avenues for abuse.” Aman Mahapatra, chief strategy officer for Tribeca Softtech, a New York City-based technology consulting firm, said that although the results are not surprising, they are significant. The especially worrisome detail in the report is that any commercial LLM failed at all, “because the security model for agentic AI has historically assumed that model-level safety training would meaningfully attenuate this class of attack,” Mahapatra said. “It does not, and the Zscaler data is the first widely-cited public evidence.” A fundamental architecture issue Mahapatra also said that the examples cited by Zscaler are not nearly as concerning as the implications of the greater damage that could occur. “The Zscaler payment scam scenario, where an agent pays a fake $3 ‘developer license fee’ to obtain an API key, is the most benign version of this,” he said. “The same technique applied to an agent authorized for procurement, expense processing, vendor onboarding, or trade execution produces losses at completely different scales. I have watched Fortune 50 banks stand up agentic workflows in the last six months that would fail exactly this attack in a live examination.” Indeed, he noted, most AI vendors already understand the magnitude of risk from today’s AI agents. “Every model provider will admit privately that the fundamental architecture of transformer-based reasoning cannot cleanly separate untrusted content from trusted instructions when both share the context window,” Mahapatra said. “The attack surface is architectural, not just behavioral. That means the defense has to be architectural too, and this is where the enterprise agentic AI conversation is still lagging badly.” Zscaler’s testing also reinforced the difference in how AI agents and humans process information. “Humans are skeptical of instructions they did not expect. Agents are eager to follow structured metadata because their training rewards them for treating high-signal fields as authoritative. Humans notice when a payment request appears in the middle of an unrelated task. Agents will thread that payment request into their execution plan if the surrounding context frames it as procedurally necessary,” Mahapatra pointed out, noting that while humans have relationships with vendors, memories of prior interactions, and social context to give them verification signals, agents only have what is in the context window, and, he said, “the context window is now the primary attack surface.” Fritz Jean-Louis, principal cybersecurity advisor at Info-Tech Research Group, agreed that the risks described in the ZScaler post are concerning, because they are in areas not traditionally addressed by enterprise security. “These attacks differ from traditional threats in that they target how AI systems process, interpret, and act on information behind the scenes,” Jean-Louis said. “Agentic AI introduces new trust boundaries, including untrusted content influencing automated decision making, tools and plugins acting autonomously on behalf of users, and AI systems operating with broad, inherited permissions. This effectively transforms the challenge into an insider threat paradigm.” This article originally appeared on InfoWorld. View the full article

In a test of major LLMs, Zscaler found that some autonomous AI agents fell victim to frauds, reinforcing how easily some high-end enterprise agents can be conned by schemes that would fool few, if any, humans. The security vendor looked at various forms of indirect prompt injection (IPI) traps and found that, whereas many models fell victim to the schemes, some of the lower-level LLMs fared better than their pricier siblings. The Zscaler testing found, for example, that four models were found to be “vulnerable”: Llama3-3-70b-instruct; Llama3-2-90b-instruct; Gemini-3-flash; and Gemini-2.5-pro. Three models were found to be “safe”: Llama4-maverick; Gemini-3.1-pro; and Gemini-3.1-flash-lite. Those results indicated that the scam resistance of Gemini-2.5-pro was seemingly weaker than that of Gemini-3.1-flash-lite. But Noah Kenney, principal consultant at Digital 520, said that there is not necessarily any valuable takeaway from that revelation, because agents constantly change behavior as they feed on new data and revise their analyzed assumptions. That means an agent that failed a specific test might very well pass the identical test an hour later, he said. “The risk of an agent is constantly changing and that can cause vastly different results. You can’t assume the results are generalizable. The test result is only at one point in time,” Kenney pointed out. Zscaler “is trying to prove a point that I don’t think the data necessarily proves.” Kenney added that having a clean “safe/vulnerable” classification is too simplistic to be useful. “That’s a binary classification. I would never recommend to a CISO to do a binary classification.” The full ZScaler blog post argued that many autonomous agents are susceptible to IPI traps. The company said it identified IPI embedded in multiple websites, where hidden instructions were designed to manipulate the behavior of an AI agent. In its internal validation across 26 LLMs, 4 models “failed to take appropriate actions,” which, it said, demonstrated “measurable real-world impact, showing that susceptibility varies by model and by the context provided to the LLM alongside the prompt.” The post added, “as AI agents become a more common interface to the web, the content itself is going to become a larger attack surface, highlighting that AI is a double-edged sword that can streamline workflows while also introducing new avenues for abuse.” Aman Mahapatra, chief strategy officer for Tribeca Softtech, a New York City-based technology consulting firm, said that although the results are not surprising, they are significant. The especially worrisome detail in the report is that any commercial LLM failed at all, “because the security model for agentic AI has historically assumed that model-level safety training would meaningfully attenuate this class of attack,” Mahapatra said. “It does not, and the Zscaler data is the first widely-cited public evidence.” A fundamental architecture issue Mahapatra also said that the examples cited by Zscaler are not nearly as concerning as the implications of the greater damage that could occur. “The Zscaler payment scam scenario, where an agent pays a fake $3 ‘developer license fee’ to obtain an API key, is the most benign version of this,” he said. “The same technique applied to an agent authorized for procurement, expense processing, vendor onboarding, or trade execution produces losses at completely different scales. I have watched Fortune 50 banks stand up agentic workflows in the last six months that would fail exactly this attack in a live examination.” Indeed, he noted, most AI vendors already understand the magnitude of risk from today’s AI agents. “Every model provider will admit privately that the fundamental architecture of transformer-based reasoning cannot cleanly separate untrusted content from trusted instructions when both share the context window,” Mahapatra said. “The attack surface is architectural, not just behavioral. That means the defense has to be architectural too, and this is where the enterprise agentic AI conversation is still lagging badly.” Zscaler’s testing also reinforced the difference in how AI agents and humans process information. “Humans are skeptical of instructions they did not expect. Agents are eager to follow structured metadata because their training rewards them for treating high-signal fields as authoritative. Humans notice when a payment request appears in the middle of an unrelated task. Agents will thread that payment request into their execution plan if the surrounding context frames it as procedurally necessary,” Mahapatra pointed out, noting that while humans have relationships with vendors, memories of prior interactions, and social context to give them verification signals, agents only have what is in the context window, and, he said, “the context window is now the primary attack surface.” Fritz Jean-Louis, principal cybersecurity advisor at Info-Tech Research Group, agreed that the risks described in the ZScaler post are concerning, because they are in areas not traditionally addressed by enterprise security. “These attacks differ from traditional threats in that they target how AI systems process, interpret, and act on information behind the scenes,” Jean-Louis said. “Agentic AI introduces new trust boundaries, including untrusted content influencing automated decision making, tools and plugins acting autonomously on behalf of users, and AI systems operating with broad, inherited permissions. This effectively transforms the challenge into an insider threat paradigm.” This article originally appeared on InfoWorld. View the full article