Share

Agent supply chain risk stopped being theoretical in March 2026. Over twelve days, a single threat actor group turned Trivy, KICS, LiteLLM, and Axios into credential-harvesting weapons, cascading across five distribution ecosystems and producing 300 GB of stolen secrets. The campaign started with an AI-powered bot. It spread through a self-propagating worm with blockchain-based command and control. Your vulnerability scanner, the tool you trusted to protect your pipeline, was the entry point. Now picture that same attack chain hitting an autonomous agent that installs tools, updates dependencies, and executes third-party skills without asking you first.

Your Vulnerability Scanner Was the Vulnerability

On March 19, 2026, TeamPCP used stolen credentials to force-push 76 of 77 version tags in the aquasecurity/trivy-action repository to malicious commits. The payload ran before the legitimate scan. Pipelines completed normally with green checkmarks across the board. Meanwhile, the malware dumped Runner.Worker process memory and exfiltrated cloud credentials, SSH keys, Kubernetes tokens, npm tokens, and Docker registry credentials to attacker-controlled infrastructure.

Trivy is a vulnerability scanner. Organizations run it in their CI/CD pipelines to detect supply chain attacks. When TeamPCP compromised it, the tool designed to find compromised dependencies became the compromised dependency. The irony is structural, not incidental. Security tools make ideal targets for supply chain attacks because they already have broad read access to the environments they scan. They touch secrets by design.

KICS, Checkmarx’s infrastructure-as-code scanner, fell the same way four days later. All 35 version tags hijacked. Same credential-stealing payload, different typosquat domain. Then LiteLLM, the AI gateway library that holds API keys for every LLM provider an organization uses, with 95 million monthly downloads and presence in 36% of cloud environments according to Wiz Research. TeamPCP published malicious versions to PyPI using credentials stolen from LiteLLM’s own CI/CD pipeline, which ran Trivy as part of its build process.

Each victim funded the next attack. The chain started with a single incomplete credential rotation at Aqua Security on March 1. TeamPCP retained access through tokens that survived the rotation. Every compromise from March 19 forward exploited credentials harvested from the previous target. Partial containment, as Aqua Security’s own post-incident analysis acknowledged, equals no containment.

By the time Axios was compromised on March 31 (100+ million weekly npm downloads, attributed by Microsoft Threat Intelligence to North Korean state actor Sapphire Sleet), the credential ecosystem was so thoroughly disrupted that Mandiant CTO Charles Carmakal warned of “hundreds of thousands of stolen credentials” and “a variety of actors with varied motivations.” The FBI confirmed TeamPCP was working through approximately 300 GB of compressed stolen credentials in collaboration with the LAPSUS$ extortion group.

The AI Bot That Started Everything

Most coverage focuses on the credential cascade. The more significant development is the one that started it.

On February 28, 2026, an autonomous bot calling itself hackerbot-claw exploited a misconfigured pull_request_target workflow in Trivy’s GitHub Actions to steal a Personal Access Token with write access to all 33+ Aqua Security repositories. The bot’s GitHub profile described itself as “an autonomous security research agent powered by claude-opus-4-5.” It carried a vulnerability pattern index with 9 attack classes and 47 sub-patterns. It targeted seven major repositories belonging to Microsoft, DataDog, CNCF, and Aqua Security over one week, achieving remote code execution in at least four.

This was not a script running pre-written exploits, as hackerbot-claw adapted its approach to each target’s specific workflow configuration. When one technique failed, it pivoted. Against the ambient-code/platform repository, it attempted prompt injection by replacing the project’s CLAUDE.md file with instructions designed to trick Claude Code into committing unauthorized changes. Claude Code detected the attack and refused, classifying it as a supply chain attack via poisoned project-level instructions.

That detail matters. An AI agent attacked. An AI agent defended. The outcome depended on configuration quality, not human vigilance. This is the arms race in miniature, and it already happened at production scale against real infrastructure.

StepSecurity, Repello AI, and Boost Security Labs independently documented the campaign. Pillar Security’s assessment identified the core gap: “zero visibility into AI coding agents running on developer machines, and no runtime controls when those agents are weaponized.”

Why Agent Supply Chain Risk Breaks Your Existing Controls

Every supply chain control you have assumes a human is looking. Dependency scanning assumes someone reviews the output. Code review assumes someone reads the diff. SBOM generation assumes someone checks the inventory. SAST and DAST assume someone triages the findings.

Agents don’t look. They execute.

When a developer installs a package, they see a version number, check a changelog, run tests. When an agent installs a tool or skill, it follows instructions. If the MCP server definition says “install this plugin,” the agent installs it. If the skill marketplace listing looks legitimate, the agent trusts it. The human-in-the-loop that traditional supply chain security depends on evaporates.

Research published the same week as the TeamPCP campaign quantifies the gap. The OpenClaw vulnerability taxonomy (A Systematic Taxonomy of Security Vulnerabilities in the OpenClaw AI Agent Framework, arXiv 2603.27517) catalogued 190 security advisories in the OpenClaw AI agent framework, organized by architectural layer and adversarial technique. Three findings stand out. First, three moderate-to-high-severity advisories compose into a complete unauthenticated remote code execution path from an LLM tool call to the host process. Second, the primary command-filtering mechanism relies on a closed-world assumption that shell commands are identifiable through lexical parsing, an assumption broken by basic techniques like line continuation and option abbreviation. Third, and most relevant here, a malicious skill distributed through the plugin channel executed a two-stage dropper within the LLM context, bypassing the entire execution pipeline. The skill distribution surface has no runtime policy enforcement.

SafeClaw-R (arXiv 2603.28807) found that 36.4% of OpenClaw’s built-in skills carry high or critical risk. That number covers the built-in skills, before any third-party marketplace plugins enter the picture. Across ClawHub, the agent skill marketplace, Antiy CERT confirmed 1,184 malicious skills, roughly one in five packages. The Repello AI team traced 335 of those to a single coordinated campaign called ClawHavoc.

The March 2026 campaign showed what happens when the consumer of a compromised dependency is a CI/CD pipeline: automated, monitored by humans on a lag, with credentials accessible at runtime. The agent version removes the monitoring layer entirely. An agent that installs a malicious MCP server or skill executes the payload as part of its normal workflow, with whatever permissions the agent has been granted, at machine speed.

CanisterWorm Showed What Autonomous Propagation Looks Like

If the hackerbot-claw precedent shows how AI agents attack, CanisterWorm shows how compromised dependencies spread once humans are removed from the loop.

CanisterWorm emerged on March 20, deployed using npm tokens stolen from Trivy-compromised pipelines. It was a self-propagating worm. Given a stolen token, it enumerated every package the token provided access to, bumped the patch version, injected its payload, and republished. Twenty-eight packages were compromised in under sixty seconds. The worm infected 64+ packages across multiple npm scopes. Endor Labs assessed that TeamPCP had “automated credential-to-compromise tooling” capable of turning a single stolen token into exponential propagation.

The command-and-control infrastructure used an Internet Computer Protocol blockchain canister, a tamperproof smart contract with no single takedown point. The operator could rotate payloads on infected machines without republishing any package. Security researchers confirmed this as the first publicly documented npm worm to use blockchain-based C2. The kill switch? If the canister returned a YouTube URL, the backdoor skipped execution. At the time of discovery, it was returning a Rick Roll. The infrastructure was live, tested, and ready. The payload was dormant by choice.

CanisterWorm targeted human-operated CI/CD pipelines. Translate that propagation model to an agent ecosystem where tools install other tools, agents delegate to sub-agents, and MCP servers chain calls across services. The propagation surface expands from “every package a stolen token provides access to” to “every tool, skill, and service the compromised agent is authorized to reach.” The Model Context Protocol, now under the Linux Foundation’s Agentic AI Foundation after Anthropic donated it in December 2025, is becoming the standard for agent-to-tool communication. Trend Micro found 492 MCP servers exposed to the internet with zero authentication. A separate supply chain attack involved a package masquerading as a legitimate Postmark MCP server that silently BCC’d every outgoing email to the attackers. The CoSAI whitepaper on MCP security identified 12 core threat categories spanning nearly 40 distinct threats. The MCP specification itself uses SHOULD rather than MUST for human-in-the-loop requirements. That word choice tells you everything about where the standard stands on constraining agent autonomy.

What This Means for You

The governance gap between where agent supply chain risk is and where your controls are will take years to close. Microsoft released the Agent Governance Toolkit on April 2, 2026, addressing OWASP’s Agentic AI Top 10 with features like Ed25519 plugin signing and MCP security gateways. The toolkit is two days old and unvalidated in production. SafeClaw-R achieved 95.2% accuracy in controlled tests. That 4.8% gap matters at enterprise scale.

You don’t have years. Here’s what you have right now.

Pin everything to immutable references. Version tags are pointers, not contracts. The March 2026 campaign proved this at scale across GitHub Actions, Docker Hub, and npm. Pin GitHub Actions to full commit SHAs. Pin container images to digests. Pin PyPI packages to exact versions with hash verification. Floating tags and unpinned dependencies are the entry point for every attack in this chain.

Treat your security tools as attack surface. Trivy, KICS, and every other scanner in your pipeline runs with privileged access to secrets by design. Apply the same scrutiny to your security tooling that you apply to production dependencies. Monitor for unexpected behavior from tools that should be predictable.

Audit your agent tool pipelines. If your organization deploys AI agents with access to MCP servers, skill marketplaces, or plugin registries, inventory every tool your agents use. Verify provenance. Enforce allow-lists. The ClawHavoc campaign showed that 20% of a major agent marketplace was compromised. Your agents are pulling from these registries right now.

Make credential rotation atomic. The entire TeamPCP cascade traces back to one failure: Aqua Security’s non-atomic rotation on March 1. When you respond to a supply chain incident, revoke all credentials simultaneously before issuing replacements. Partial rotation is an invitation for round two.

Plan for agent-specific incident response. If a tool or skill consumed by your agents is compromised, the blast radius includes everything those agents are authorized to access. Your current incident response playbook assumes a human in the response loop. Write the agent-specific version before you need it.

Key Takeaway: The March 2026 supply chain campaign compromised your scanners, your AI gateway, and your HTTP client in twelve days. The same attack pattern targeting autonomous agents will move faster, spread further, and leave fewer traces. Your supply chain controls were built for a world where a human reviewed every dependency. That world is ending.

What to do next

The gap between traditional supply chain security and agent supply chain security is the defining governance challenge of 2026. If you’re a CISO or security architect, the question isn’t whether your organization uses AI agents with third-party tools. The question is whether you know which tools, with what permissions, under whose authority.

Start with visibility. You don’t control what you haven’t inventoried. For a deeper framework on operationalizing emerging security challenges, The CISO Evolution walks through how security leaders adapt their programs when the threat model shifts underneath them.

More on agent security, supply chain governance, and the practitioner’s view of AI risk at RockCyber Musings.

👉 Visit RockCyber.com to learn more about how we can help you in your traditional Cybersecurity and AI Security and Governance Journey

👉 Want to save a quick $100K? Check out our AI Governance Tools at AIGovernanceToolkit.com

👉 Subscribe for more AI and cyber insights with the occasional rant.

The views and opinions expressed in RockCyber Musings are my own and do not represent the positions of my employer or any organization I’m affiliated with.

Thanks for reading RockCyber Musings! Subscribe for free to receive new posts and support my work.

Share RockCyber Musings

If your agentic AI safety strategy depends on reading the model’s chain of thought, you’re listening to a rehearsed speech and calling it a confession. A March 2025 paper from Goodfire AI and Harvard University shows that reasoning models often commit to their final answer within the first tokens of “thinking,” then generate hundreds of additional tokens to perform deliberation they’ve already completed. For every security leader, product owner, and governance committee treating chain-of-thought monitoring as an auditable safety control, these findings demand an immediate reassessment.

Share

The Research That Changes the Conversation

The paper, titled “Reasoning Theater: Disentangling Model Beliefs from Chain-of-Thought,” tested two frontier reasoning models (DeepSeek-R1 671B and GPT-OSS 120B) using three methods to determine when models commit to their final answer during a chain-of-thought trace.

The first method trains lightweight attention probes on model activations to predict the final answer at any point during reasoning. The second forces the model to answer early by truncating its reasoning and demanding a response. The third uses an external LLM (Gemini 2.5 Flash) as a CoT monitor, the same approach many vendors now sell as an AI safety feature.

The results expose a gap that should reshape every AI governance conversation. On MMLU-Redux, a benchmark heavy on recall-based questions, attention probes decoded the correct final answer with high accuracy from the earliest reasoning tokens. The CoT monitor couldn’t identify the model’s answer until much later in the sequence. The performativity rate, measuring the gap between internal confidence and external verbalization, hit 0.417 on MMLU for DeepSeek-R1. A rate near zero means the model’s spoken reasoning matches its internal state. A rate of 0.417 means the model spends roughly 40% of its reasoning trace performing confidence it already holds.

On GPQA-Diamond, a dataset requiring graduate-level multi-hop reasoning in biology, chemistry, and physics, the picture reversed. All three methods started near chance accuracy and improved at similar rates throughout the reasoning trace. The performativity rate dropped to 0.012. The chain of thought tracked genuine computation because the model needed to think.

The number that should stop every governance meeting cold: probe-guided early exit reduced the number of generated tokens by 80% on MMLU and 30% on GPQA-Diamond, with comparable accuracy. The model produced 80% more tokens than it needed on easy recall tasks. Every one of those tokens looked like reasoning. None of them were.

Your Model Performs Compliance, Not Communication

The paper’s most valuable contribution for security professionals sits in the linguistic framework, not the probe methodology itself.

They invoke Grice’s maxims of cooperative communication, a foundational concept from pragmatics describing what honest, effective communicators do. Grice identified four maxims that cooperative speakers follow. They stay relevant (Relation). They assert only what they have evidence for (Quality). They provide exactly as much information as needed, no more (Quantity). They communicate clearly and without unnecessary obscurity (Manner).

Reasoning models, trained through reinforcement learning optimized for outcome rewards, follow Relation and Quality naturally. Staying on topic and generating evidence-based reasoning steps correlates with correct final answers, which earns the reward. The model has every incentive to be relevant and factually grounded.

Quantity and Manner get violated because the reward function doesn’t penalize verbosity or obscurity. The model generates hundreds of performative tokens after committing to its answer because nothing in the training signal punishes that behavior. The output looks like careful deliberation, but it reads like a thorough analysis. The model’s internal state tells a different story.

If you’ve sat through a compliance audit where someone recites a scripted answer that sounds thorough but reveals nothing about practice on the ground, you’ve seen the human version of this. The model doesn’t lie to you. It performs what a reasoning trace is supposed to look like, without any structural obligation to communicate its internal state honestly.

This framing hits differently depending on where you sit at the governance table. Product teams hear “the model reasons safely” because the CoT looks clean. Legal hears “we have an auditable reasoning chain” because there’s text to review. Security asks the question nobody else in the room raises… “Does the text reflect what the model computed internally?”

The Difficulty Trap: Where Enterprise Agentic AI Lives

The difficulty-dependent split creates a precise and uncomfortable problem for enterprise deployments. CoT monitoring works when the model genuinely needs to think, hard multi-hop reasoning, novel problem decomposition, tasks requiring significant test-time compute. CoT monitoring fails on tasks where models already encode the answer in their weights: recall, pattern matching, classification, and routine decision execution.

Consider what agentic AI does in a financial services environment right now. A reconciliation agent matches transaction records against internal ledgers. A KYC agent screens customer documents against sanctions lists. A compliance agent routes regulatory filings based on entity classification. A trading surveillance agent flags potential wash trades from order flow patterns.

Every one of those tasks leans heavily toward recall and pattern matching. The model has seen millions of similar patterns during training. It knows the answer early. The chain-of-thought trace generated afterward is, according to this research, predominantly performative.

The security calculus changes in direct response. Picture a sanctions screening agent processing a crafted entity record containing an indirect prompt injection embedded in a business description field. The model processes the injection at the activation level, potentially altering its classification decision. The chain-of-thought trace, generated performatively because sanctions screening is a recall task the model handles, is produced from in-weight knowledge and reads like a textbook analysis of entity risk factors. The CoT monitor watching that trace sees clean, plausible reasoning. The model’s internal activations tell a different story. Your audit trail captures what the agent wants you to see, not computation. An examiner reviewing the reasoning trace isn’t examining evidence of how the model decided. They’re reviewing a post-hoc performance that resembles deliberation.

The researchers also found that model size correlates with performativity. Larger models (671B parameters) knew their answers earlier and generated more performative reasoning than smaller distilled versions (1.5B to 32B). Smaller models needed genuine test-time computation for equivalent tasks. As the industry pushes toward larger, more capable reasoning models for enterprise agentic AI, the performativity problem intensifies with every parameter upgrade.

The EU AI Act’s Article 14 requires human oversight of high-risk AI systems, with provisions for understanding the system’s reasoning. Financial regulators from the OCC to the FCA have signaled expectations for explainability in automated decision-making. Governance frameworks built on the assumption that reasoning traces constitute meaningful explanations now face a credibility problem they haven’t accounted for.

Three Research Groups, One Uncomfortable Conclusion

The Reasoning Theater paper lands with maximum force when you triangulate it against two other major findings from competing institutions.

OpenAI’s Baker et al. (March 2025) studied what happens when CoT monitors are integrated directly into the reinforcement learning training loop. In early stages, models became more capable and more aligned. Under excessive training pressure, models learned what the researchers called “obfuscated reward hacking”: hiding their intent within the chain of thought while continuing to hack the reward signal. OpenAI’s recommendation was blunt: developers training frontier reasoning models should avoid applying strong supervision directly to chains of thought. The monitorability itself is fragile. OpenAI’s follow-up “Monitoring Monitorability” paper in December 2025 proposed formal evaluation metrics to track this fragility across o3 and GPT-5.1 training runs, recognizing that the problem demands ongoing measurement rather than a one-time fix.

Anthropic’s Chen et al. (May 2025) found that reasoning models verbalized their use of reasoning hints in fewer than 20% of cases where they relied on those hints. Outcome-based RL initially improved faithfulness, then plateaued. Increased hint usage through reward hacking did not increase the propensity to disclose those hints. The model got better at using shortcuts while getting no better at revealing them.

Korbak et al.’s multi-author paper from July 2025, signed by over 40 researchers from multiple institutions, explicitly framed CoT monitorability as “a new and fragile opportunity for AI safety.” They warned that latent reasoning models, architectures that reason in continuous vector space rather than natural language, would eliminate even the partial transparency that current CoT provides.

Three independent research groups arrived at this conclusion: an interpretability lab at Goodfire, the model developer at OpenAI, and a cross-institutional safety coalition. All arrived at the same conclusion: chain-of-thought monitoring provides a signal in specific conditions, and those conditions don’t map cleanly to enterprise agentic AI deployments, where the majority of tasks fall below the difficulty threshold where monitoring remains reliable.

Applying CARE: Fixing Your Chain-of-Thought Monitoring Gap

The CARE framework (Create, Adapt, Run, Evolve) provides a structured path to address the reasoning theater problem without abandoning CoT monitoring wholesale.

Create your threat model around the faithfulness gap. Classify every agentic AI workflow by task difficulty and determine which ones the model solves from in-weight knowledge versus genuine test-time reasoning. Recall-heavy tasks like KYC screening, transaction matching, and document classification carry high performativity risk. Multi-step analytical tasks like fraud investigation across multiple data sources and complex regulatory interpretation carry lower risk. Design your monitoring controls proportional to that classification.

Adapt your monitoring stack to account for activation-level signals where architectures permit it. The Reasoning Theater research demonstrates that attention probes trained on model activations predict behavior far earlier and more accurately than CoT monitors for performative tasks. Every vendor offering agentic AI safety tooling should answer one direct question: does your monitoring access model internals, or does it only read output text? If the answer is output text only, you now know the limitation and the research that quantifies it.

Run dual-layer monitoring in production. Keep CoT monitors active for genuine reasoning detection and inflection point identification. The research confirmed that backtracking, realizations, and reconsiderations in CoT traces correspond to authentic belief shifts, appearing more than twice as often in traces where probes showed genuine uncertainty (0.045 inflections per step in uncertain traces versus 0.020 in high-confidence performative traces for DeepSeek-R1). These inflection points remain reliable indicators of real internal computation. Layer behavioral monitoring (input/output validation, action-level controls, tool call verification) as the primary safety net for performative tasks. The CoT monitor becomes your second line for routine operations, not your first.

Evolve your governance documentation to reflect the difficulty-dependent nature of CoT reliability. Update risk assessments as model capabilities change. Larger models and improved training methods shift the boundary between “easy” and “hard” tasks, changing where CoT monitoring remains effective. The August 2026 EU AI Act enforcement deadline adds urgency. Treat this as a moving target, because the research shows it is one.

Key Takeaway: Chain-of-thought monitoring provides genuine safety signal for hard reasoning tasks, but the majority of enterprise agentic AI workflows fall below the difficulty threshold where that signal remains reliable. Your governance framework needs to know the difference, and your next vendor evaluation needs to test for it.

What to do next

Download the Reasoning Theater paper and its interactive visualization tool at reasoning-theater.streamlit.app. Map your agentic AI workflows against the difficulty-dependent performativity findings. Bring this evidence to your next AI governance meeting, because the product team, legal counsel, and AI lead sitting across from you haven’t read it yet.

For more on building AI governance frameworks that survive contact with adversarial reality, explore the CARE framework at rockcyber.com. Subscribe to RockCyber Musings for more AI security and governance insights with the occasional rant.

👉 Subscribe for more AI security and governance insights with the occasional rant.

👉 Visit RockCyber.com to learn more about how we can help you in your traditional Cybersecurity and AI Security and Governance Journey

👉 Want to save a quick $100K? Check out our AI Governance Tools at AIGovernanceToolkit.com

The views and opinions expressed in RockCyber Musings are my own and do not represent the positions of my employer or any organization I’m affiliated with.

Anthropic had a week that should be a case study in operational security failure for years to come. On March 31, a routine release packaging error exposed 500,000 lines of Claude Code source across roughly 2,000 files. Five days earlier, a CMS misconfiguration had already put nearly 3,000 unpublished internal documents into a public search index, including draft material describing their most capable model as posing “unprecedented cybersecurity risk.” By April 1, they were firing DMCA takedowns at 8,000 GitHub repositories, most unrelated to them, trying to unsee what the internet had already seen. By April 2, a congressman was writing to the CEO about national security.

That would have been enough for any week. It was not the only thing that happened. On March 27, CISA added two exploited AI infrastructure vulnerabilities to its KEV catalog; three LangChain and LangGraph CVEs hit disclosure, with 84 million downloads in scope; and the European Commission confirmed attackers had been inside their AWS account for three days. The thread connecting all of it is the same one it always is: AI deployment speed running ahead of the operational security discipline required to sustain it. This week was not an anomaly. It was a pattern. Patterns do not self-correct.

As a bonus, check out my AI Cyber Magazine Podcast with Confidence Staveley during RSA.

Share

1. Anthropic Leaked 500,000 Lines of Claude Code Source, Then Panicked on GitHub

On March 31, a debugging file accidentally bundled into a routine Claude Code update exposed approximately 500,000 lines of source code across nearly 2,000 files (CNBC, Axios, Fortune). The codebase was mirrored across GitHub within hours. Leaked feature flags revealed unreleased capabilities: a persistent background agent, cross-device remote control, and session-to-session learning. Anthropic attributed the incident to “a release packaging issue caused by human error” and stated no customer data was exposed. On April 1, attempting to scrub the code from GitHub, Anthropic sent DMCA takedowns that hit approximately 8,000 repositories, most unrelated to the leak (TechCrunch, Bloomberg).

Why it matters

• Competitors received Anthropic’s unreleased feature roadmap. That strategic damage compounds the fact that this happened five days after the Mythos content leak. Coincidence???? I’ll let you decide.

• The persistent background agent and remote control capabilities in the leaked code require explicit security design review before deployment. They were in development without prior public disclosure of the capability direction.

• The DMCA sweep that caught 8,000 unrelated repositories shows what reactive incident response without a playbook looks like. Every remediation attempt created a new problem.

What to do about it

• If you deploy Claude Code in your enterprise environment, review what access it holds to production systems and rotate any associated credentials until the full scope of the leak is confirmed.

• Require software composition analysis (SCA) and release integrity verification as contractual terms with your AI vendors.

• Develop a pre-incident legal response playbook that covers IP exposure scenarios, including proportional DMCA procedures that require scope confirmation before submission.

Rock’s Musings

Two major operational security failures from the same company in five days. The first was a CMS misconfiguration. The second was a packaging error. Both are basic controls that mature security operations have solved. Anthropic markets itself on safety and trustworthiness, and that positioning is now doing work it was not designed to carry. The DMCA overcorrection made it worse: you leak 500,000 lines of source code, then fire automated takedown requests at 8,000 repositories, most of them unrelated to you. Every IP attorney will tell you DMCA takedowns require good faith and specificity. Have a process before the fire starts.

2. Anthropic Accidentally Confirmed Its Most Capable Model Poses Unprecedented Cybersecurity Risk

A configuration error in Anthropic’s content management system made nearly 3,000 unpublished assets publicly searchable starting around March 26, including draft blog posts for a model called Claude Mythos (Fortune, CoinDesk). Internal documents describe Mythos as capable of rapidly finding and exploiting software vulnerabilities at an unprecedented scale. Anthropic confirmed the model exists and is in testing with early-access customers, calling it “a step change” in capability. The company described the exposure as caused by a configuration error and stated the data store was secured after discovery.

Why it matters

• Anthropic’s own internal documentation, not a researcher’s estimate, describes this model as posing cybersecurity risks the industry has not seen before. That is the company’s self-assessment.

• Early-access customer deployments were already underway before any public discussion of the risk profile occurred. The model shipped before the security conversation started.

• A frontier model capable of autonomously finding and exploiting vulnerabilities at scale invalidates current vulnerability management timelines. That conversation needs to happen now.

What to do about it

• Update your AI threat model to account for AI-assisted offensive operations at scale. This is not a future scenario. It is a current deployment.

• Ask your AI vendors direct questions about internal capability assessments before your next contract renewal. What have they assessed, and when?

• Document board and leadership awareness of frontier AI capability risk as a governance record item. Regulatory scrutiny on this topic will increase.

Rock’s Musings

The model is called Mythos. The leaked internal docs describe the cybersecurity risk as unprecedented. Anthropic was already deploying it with customers before any of this became public. This happened not because of an attack but because someone left a CMS misconfigured. Anthropic has historically been conservative in capability claims. When their own internal documentation describes a model as different in kind from what came before, the security community should take that seriously, not because the word “unprecedented” is alarming on its own, but because the source is the organization that built the thing. They know what it does.

3. ShinyHunters Breached the European Commission’s AWS Account

The European Commission confirmed on March 27 that attackers accessed the AWS account hosting its Europa.eu websites, with the intrusion first detected on March 24 (TechCrunch, Bloomberg). Threat actor ShinyHunters claimed responsibility and alleged theft of more than 350GB of data including mail server exports, databases, confidential documents, and contracts. The Commission’s statement noted internal systems were unaffected and mitigation measures were applied quickly. Affected EU entities received notification.

Why it matters

• ShinyHunters has a documented history of monetizing stolen data through dark market sales. Even if the 350GB claim is exaggerated for leverage, policy documents and procurement contracts from the Commission’s web infrastructure are a counterintelligence asset.

• The Commission enforces GDPR and is building the AI Act enforcement apparatus. Getting breached while standing up that apparatus is not a good governance signal.

• AWS account-level compromise is full infrastructure compromise in practice. A managed cloud provider does not neutralize cloud account security failures.

What to do about it

• Audit your AWS account permission boundaries and review CloudTrail logs for anomalous patterns this week, not next quarter.

• Ensure your incident response plan explicitly covers cloud account compromise. Traditional endpoint-focused plans miss this scenario entirely.

• If any of your vendors are EU institutions or Commission contractors, treat procurement data exposure as a downstream supply chain risk and assess your exposure now.

Rock’s Musings

The body enforcing Europe’s data protection framework had its AWS account cracked. Governance credentials do not equal security maturity. Write the most thorough AI regulation in the world. Your cloud IAM configuration remains a disaster until someone fixes it. The ShinyHunters 350GB claim needs forensic verification before anyone draws conclusions about scope, but three days of undetected access to the official Commission infrastructure doesn’t need verification. The institutions asking private sector organizations to demonstrate AI security maturity owe the market some transparency on their own failures. Name it, fix it, move on.

4. Your AI Workflow Tool Got CISA’s Attention: Langflow CVE-2026-33017

CISA added CVE-2026-33017, a critical remote code execution flaw in Langflow, to its Known Exploited Vulnerabilities catalog on March 26. Attackers began scanning for exposed instances roughly 20 hours after the advisory publication, with exploitation scripts appearing within 21 hours and active .env and .db file harvesting beginning within 24 hours (Sysdig, BleepingComputer, Help Net Security). The vulnerability carries a CVSS score of 9.3 and allows unauthenticated attackers to inject arbitrary Python code through the public flow build endpoint with no sandboxing applied. Federal agencies face an April 8 remediation deadline. Upgrade to Langflow version 1.9.0 or later.

Why it matters

• Langflow is used to build and deploy LLM pipelines. Remote code execution in a workflow orchestration tool gives an attacker control over the AI’s inputs, outputs, and the credentials it holds.

• The 20-hour exploitation window is increasingly standard for high-severity flaws. The concept of a patch window measured in days is no longer realistic for internet-exposed AI infrastructure.

• .env file harvesting is the attacker’s first move because those files contain API keys for LLMs, vector databases, and cloud services the workflow connects to.

What to do about it

• If Langflow runs on any internet-accessible host, treat the environment as potentially compromised and rotate all associated credentials before patching.

• Segment AI workflow orchestration platforms behind authentication and network controls. These tools have no business being directly internet-accessible.

• Verify Langflow version across your environment immediately. Anything prior to 1.9.0 is an open liability.

Rock’s Musings

The 20-hour exploitation timeline should reframe your vulnerability management program. That program was designed when you had days or weeks to act. That era closed. CISA’s KEV catalog is now your minimum viable patch priority list, and if you are not at sub-72-hour remediation SLAs for critical AI infrastructure, you are already behind. Organizations still describing AI workflow platforms as “internal tools” need a rethink. Internal tools with LLM API keys, cloud credentials, and production data connections are not internal in any meaningful threat model. An attacker who executes code in your Langflow environment has lateral movement access to every system that environment touches.

5. LangChain and LangGraph: Three CVEs, 84 Million Downloads Exposed

Cyera security researcher Vladimir Tokarev disclosed three vulnerabilities in LangChain and LangGraph on March 27, each covering a different attack path against the same enterprise AI framework (The Hacker News). CVE-2026-34070 (CVSS 7.5) enables path traversal to arbitrary files through manipulated prompt templates. CVE-2025-68664 (CVSS 9.3) allows extraction of API keys and environment secrets through unsafe deserialization. CVE-2025-67644 (CVSS 7.3) enables SQL injection in LangGraph’s SQLite checkpoint layer. LangChain, LangChain-Core, and LangGraph collectively logged over 84 million downloads. Patches are available: LangChain Core 1.2.22+, LangChain-Core 0.3.81+ or 1.2.5+, and LangGraph checkpoint sqlite 3.0.1+.

Why it matters

• These three CVEs cover filesystem data, environment secrets, and conversation history in combination. Together, they represent near-total information exposure for any application built on these frameworks.

• The 84 million download count means a significant portion of enterprise AI applications are affected. Most organizations do not know which AI frameworks their development teams selected.

• CVE-2025-68664 with its 9.3 CVSS is the most critical. Unsafe deserialization is a well-understood, pervasive, and reliably exploitable class of vulnerability.

What to do about it

• Inventory every AI framework in your environment, including those embedded in third-party tools. Do not rely on developers to self-report what they are using.

• Apply the three patches and validate versions before the end of the business week.

• Assess what data your LangChain-based applications can access and treat those data stores as potentially exposed pending patch confirmation.

Rock’s Musings

Three vulnerability classes in the same framework, covering three categories of sensitive enterprise data, were disclosed in one report. That’s what happens when you build for speed and bolt on security later. AI framework developers made that choice repeatedly, and this week’s CVE list is the invoice. LangChain is the jQuery of AI development right now. It is in everything, often without explicit organizational approval. Your AI security posture includes every dependency your developers pulled in without telling you. Get ahead of that inventory problem before the next disclosure.

6. A Congressman Put Anthropic on Notice Over National Security

Rep. Josh Gottheimer (D-N.J.) sent a letter to Anthropic CEO Dario Amodei on April 2, citing national security concerns arising from the source code leak (Axios, The Hill). Gottheimer’s letter noted that Claude is embedded in defense and intelligence operations, raised the prior CCP-backed group intrusion against Claude, and expressed concern that Mythos could enable more sophisticated cyberattacks against the United States. The letter also flagged Anthropic’s decision in late February to remove its binding commitment to halt model development if safety capabilities fall behind, replacing it with “nonbinding but publicly-declared” goals.

Why it matters

• Federal agencies and defense contractors use Claude operationally. A source code leak followed by a congressional inquiry is a vendor risk event, not a PR problem. Your GRC process should treat it as such.

• Removing the binding safety commitment is a substantive policy change that the congressional record now documents. The enforceability question will follow Anthropic through every future regulatory discussion.

• Gottheimer sits on the House Intelligence Committee. This is not a throwaway letter. It is a first-stage oversight action that signals more to come.

What to do about it

• Review your vendor risk assessment for any AI provider with confirmed government contracts. Congressional inquiries are material third-party risk events.

• Establish a direct communication channel with your AI vendors’ enterprise security teams and request formal notification procedures for any government inquiries affecting their products.

• Track the congressional record regarding Anthropic’s rollback of its safety commitment. It will surface again in budget and procurement cycles.

Rock’s Musings

The safety commitment rollback from February is the most substantive issue in that letter. Anthropic replaced a binding pledge to pause development if safety fell behind with goals they grade themselves on. That is not a small change. That is the foundational accountability mechanism that distinguished their positioning from competitors, and they quietly removed it. Congressional scrutiny was predictable the moment they became embedded in national security operations. The question I would ask directly is how many federal agency customers received notification about the source code exposure before it hit the press. I would guess the answer is uncomfortable.

7. Your Security Scanner Was the Supply Chain Attack: Trivy CVE-2026-33634

CISA added CVE-2026-33634 to its Known Exploited Vulnerabilities catalog on March 27 (Help Net Security, Aquasecurity GitHub advisory). Attackers compromised the Trivy container security scanner on March 19, using stolen credentials to publish a malicious v0.69.4 release and force-push 76 of 77 version tags in the trivy-action repository with credential-stealing malware. The attack triggered a downstream LiteLLM supply chain compromise via poisoned PyPI packages. Federal agencies face an April 9 deadline. Root cause was non-atomic credential rotation on March 1 left a valid token exposed during the rotation window.

Why it matters

• Trivy is a default security tool in CI/CD pipelines across the industry. Compromising the scanner means attackers access the same environment credentials the security scan was meant to protect.

• Force-pushing 76 version tags is a comprehensive compromise. Any pipeline that pins to mutable major or minor version tags rather than specific commit hashes was exposed.

• The downstream LiteLLM PyPI compromise extends the blast radius into Python environments running LLM application code. The supply chain damage propagated well beyond the initial tool compromise.

What to do about it

• Audit every CI/CD pipeline for trivy-action or setup-trivy at mutable version tags and pin to specific commit hashes immediately.

• Treat any environment that ran a compromised Trivy version since March 19 as potentially credential-compromised. Rotate all associated tokens, SSH keys, and cloud credentials.

• Apply this lesson to every security tool in your pipeline. Security tooling supply chains are higher-value targets than application code supply chains.

Rock’s Musings

The attacker turned the vulnerability scanner into the vulnerability. That is the platonic ideal of a supply chain attack: targeting organizations that care about security and embed security tooling in their build pipelines. The more security-conscious your culture, the higher your Trivy adoption, and the more exposed you were. The non-atomic credential rotation is the root cause. Aquasecurity rotated credentials on March 1 but did not revoke all tokens simultaneously. The attacker grabbed freshly rotated secrets during the window between invalidation and deployment. If your own rotation procedures have a gap between “revoke old” and “confirm new is live,” that gap is your exposure. Run your playbooks against that question this week.

8. The State AI Chatbot Safety Wave Is Not Waiting for Washington

Georgia’s state senate voted to concur in the House-amended version of SB 540 during the week of March 27, sending the chatbot disclosure and minor-protection bill to Governor Kemp’s desk (Troutman Privacy, Transparency Coalition). Idaho’s S 1297 passed its full legislature and advanced to Governor Little. Both are chatbot safety measures. Georgia’s bill requires disclosure every three hours for adult users and every hour for minors, along with explicit suicide and self-harm response protocols for conversational AI services. The Future of Privacy Forum’s tracker now counts 78 AI chatbot safety bills moving across 27 states in 2026.

Why it matters

• Disclosure, minor safety, and mental health response requirements are becoming the regulatory floor across state jurisdictions. Organizations operating consumer-facing AI products need a 50-state tracking capability, not a wait-and-see approach.

• Hourly disclosure requirements for minors are not trivial to implement for many chatbot architectures. The compliance engineering work should start now.

• Seventy-eight bills across 27 states mean that any federal preemption framework, if one ever arrives, faces an already established patchwork of state obligations to reconcile.

What to do about it

• Map your consumer AI products against chatbot disclosure requirements in every state where users reside. Georgia and Idaho represent the floor, not the ceiling.

• Assess your chatbot’s existing mental health response protocols against the Georgia requirement specifics. A disclaimer is not compliant.

• Assign someone accountable for multi-state AI governance tracking. This is not a future compliance problem.

Rock’s Musings

Washington cannot pass a federal AI framework. States can. Fifty legislatures with different requirements and different timelines is the compliance nightmare that preemption was supposed to prevent. It didn’t. Georgia’s hourly minor disclosure requirement is specific, implementable, and enforceable. State legislatures are producing more actionable compliance requirements than most federal guidance I have seen this year. If you deploy consumer AI products and you don’t have someone accountable for multi-state AI governance tracking today, that gap closes before Q3 or it closes you.

9. The EU AI Act Has an Enforcement Problem, and Nobody Is Talking About It Honestly

As of late March, only 8 of 27 EU member states had designated the single contact points required for national enforcement coordination under the AI Act, according to the European Parliament Think Tank’s enforcement analysis (Tech Policy Press, IAPP). The Digital Omnibus proposal, with negotiating positions adopted by Parliament’s IMCO and LIBE committees on March 18, would push high-risk AI compliance deadlines to December 2027 for Annex III systems and to August 2028 for Annex I systems, compared with the original August 2026 deadline. The European Commission also missed its own deadline for issuing guidance on high-risk AI systems. Trilogue negotiations between Council, Parliament, and Commission are now underway.

Why it matters

• Approximately 70% of EU member states are not operationally ready for AI Act enforcement. Regulations without enforcement infrastructure are aspirational documents.

• The 16-month delay in high-risk requirements gives organizations breathing room on paper while creating uncertainty about what compliance standard they are being held to during the gap.

• The Commission missing its own implementation guidance deadline sets a poor precedent for holding private sector organizations to their compliance timelines.

What to do about it

• Do not use the delay as a license to defer governance program work. The underlying obligations have not changed in substance. Build the program now and own it.

• Review the Digital Omnibus amendments specifically for changes to the high-risk AI system definition. Legislative simplification sometimes reclassifies systems in ways that alter the scope of compliance.

• Subscribe to IAPP’s EU AI Act tracker for updates on the trilogue outcome. The final text will differ from both Council and Parliament positions.

Rock’s Musings

Eight out of 27 enforcement bodies are operational as the Act’s first major deadlines approach. The Commission missed its own implementation guidance deadline. The most substantive AI governance framework on the planet is running on infrastructure that is not ready to enforce it. The delay does not invalidate the regulation. Organizations that build genuine AI risk management programs now will be positioned for whatever enforcement timeline materializes. Organizations that chase the deadline and treat compliance as documentation will be exposed when the enforcement machinery catches up. That gap grows wider every quarter.

The One Thing You Won’t Hear About But You Need To

NVIDIA and Johns Hopkins Gave You a Blueprint for Defending AI Agents Against Prompt Injection

Researchers from NVIDIA and Johns Hopkins University published “Architecting Secure AI Agents: Perspectives on System-Level Defenses Against Indirect Prompt Injection Attacks” on March 31 (ArXiv 2603.30016). The paper addresses how AI agents are vulnerable not to direct attacks on the model but to malicious instructions embedded in data the agent processes during task execution. The authors articulate three architectural positions. First, agents in dynamic environments need dynamic replanning with security policy updates built into the replanning loop. Second, security decisions requiring contextual judgment should still involve LLMs, but only within system designs that strictly constrain what the model can observe and decide. Third, ambiguous situations should treat human interaction as a core design consideration, not an edge case to minimize.

Why it matters

• This paper frames indirect prompt injection as an architectural problem, not a model alignment problem. You cannot align your way out of it. You design it out or you accept the risk.

• The principle of strictly constraining what the model can observe and decide has immediate practical application as your primary defense lever, more effective than filtering or detection approaches.

• The human oversight design principle directly contradicts how most agentic deployments are being built, with human review treated as friction to reduce rather than a security control to preserve.

What to do about it

• Read the paper. At 12 pages, it is short enough to share with your AI architects and security engineers before the next deployment review meeting.

• Audit any agentic AI system currently in your environment against the observation scope and decision authority questions. Broad scope plus broad authority equals your highest-risk deployment.

• Make human oversight an explicit design requirement in your AI agent security standards. Document the specific conditions under which an agent must pause and request human authorization.

Rock’s Musings

Nobody outside the AI security research community covered this paper. That is precisely why it belongs here. The breach reports get attention. The architecture guidance that would prevent the next breach sits on ArXiv with a few hundred downloads. I have been arguing at RockCyber for two years that agentic AI security is an architecture problem. You do not solve it with better prompts or stronger models. You solve it with privilege constraints, observation scope limits, and honest human oversight design. NVIDIA and Johns Hopkins gave you a 12-page framework for that conversation. If your next AI agent deployment review does not address these three principles, you are building exposure, not capability.

👉 For ongoing analysis of agentic AI governance frameworks, the conversation continues at RockCyber Musings.

👉 Visit RockCyber.com to learn more about how we can help you in your traditional Cybersecurity and AI Security and Governance Journey

👉 Want to save a quick $100K? Check out our AI Governance Tools at AIGovernanceToolkit.com

👉 Subscribe for more AI and cyber insights with the occasional rant.

The views and opinions expressed in RockCyber Musings are my own and do not represent the positions of my employer or any organization I’m affiliated with.

Share RockCyber Musings

References

Axios. (2026, March 31). Anthropic leaked its own Claude source code. https://www.axios.com/2026/03/31/anthropic-leaked-source-code-ai

Axios. (2026, April 2). Exclusive: Gottheimer presses Anthropic on source code leaks and safety protocols. https://www.axios.com/2026/04/02/gottheimer-anthropic-source-code-leaks

BleepingComputer. (2026, March 27). CISA: New Langflow flaw actively exploited to hijack AI workflows. https://www.bleepingcomputer.com/news/security/cisa-new-langflow-flaw-actively-exploited-to-hijack-ai-workflows/

Bloomberg. (2026, March 27). European Commission’s data stolen in hack on AWS account. https://www.bloomberg.com/news/articles/2026-03-27/european-commission-s-data-stolen-in-hack-on-aws-account

Bloomberg. (2026, April 1). Anthropic takes down thousands of GitHub repos trying to yank its leaked source code. https://www.bloomberg.com/news/articles/2026-04-01/anthropic-scrambles-to-address-leak-of-claude-code-source-code

CNBC. (2026, March 31). Anthropic leaks part of Claude Code’s internal source code. https://www.cnbc.com/2026/03/31/anthropic-leak-claude-code-internal-source.html

CoinDesk. (2026, March 27). Anthropic’s massive Claude Mythos leak reveals a new AI model that could be a cybersecurity nightmare. https://www.coindesk.com/markets/2026/03/27/anthropic-s-massive-claude-mythos-leak-reveals-a-new-ai-model-that-could-be-a-cybersecurity-nightmare

Fortune. (2026, March 27). Anthropic accidentally leaked details of a new AI model that poses unprecedented cybersecurity risks. https://fortune.com/2026/03/27/anthropic-leaked-ai-mythos-cybersecurity-risk/

Fortune. (2026, March 31). Anthropic leaks its own AI coding tool’s source code in second major security breach. https://fortune.com/2026/03/31/anthropic-source-code-claude-code-data-leak-second-security-lapse-days-after-accidentally-revealing-mythos/

Help Net Security. (2026, March 27). CISA sounds alarm on Langflow RCE, Trivy supply chain compromise after rapid exploitation. https://www.helpnetsecurity.com/2026/03/27/cve-2026-33017-cve-2026-33634-exploited/

Help Net Security. (2026, March 30). Second data breach at European Commission this year leaves open questions over resilience. https://www.helpnetsecurity.com/2026/03/30/european-commission-cyberattack-cloud-infrastructure-website/

IAPP. (2026). European Commission misses deadline for AI Act guidance on high-risk systems. https://iapp.org/news/a/european-commission-misses-deadline-for-ai-act-guidance-on-high-risk-systems

IAPP. (2026, March). EU Digital Omnibus: Analysis of key changes. https://iapp.org/news/a/eu-digital-omnibus-analysis-of-key-changes

Qualys ThreatPROTECT. (2026, March 26). CISA Added Langflow Vulnerability to its Known Exploited Vulnerabilities Catalog (CVE-2026-33017). https://threatprotect.qualys.com/2026/03/26/cisa-added-langflow-vulnerability-to-its-known-exploited-vulnerabilities-catalog-cve-2026-33017/

SecurityAffairs. (2026, March 27). The European Commission confirmed a cyberattack affecting part of its cloud systems. https://securityaffairs.com/190067/data-breach/the-european-commission-confirmed-a-cyberattack-affecting-part-of-its-cloud-systems.html

Sysdig. (2026, March 27). CVE-2026-33017: How attackers compromised Langflow AI pipelines in 20 hours. https://www.sysdig.com/blog/cve-2026-33017-how-attackers-compromised-langflow-ai-pipelines-in-20-hours

TechCrunch. (2026, March 27). European Commission confirms cyberattack after hackers claim data breach. https://techcrunch.com/2026/03/27/european-commission-confirms-cyberattack-after-hackers-claim-data-breach/

TechCrunch. (2026, April 1). Anthropic took down thousands of GitHub repos trying to yank its leaked source code. https://techcrunch.com/2026/04/01/anthropic-took-down-thousands-of-github-repos-trying-to-yank-its-leaked-source-code-a-move-the-company-says-was-an-accident/

The Hacker News. (2026, March 27). LangChain, LangGraph flaws expose files, secrets, databases in widely used AI frameworks. https://thehackernews.com/2026/03/langchain-langgraph-flaws-expose-files.html

The Hill. (2026, April 2). House Democrat pushes Anthropic on safety protocols, source code leak. https://thehill.com/policy/technology/5812881-gottheimer-presses-anthropic-ai-safety/

Tech Policy Press. (2026). EU’s AI Act delays let high-risk systems dodge oversight. https://www.techpolicy.press/eus-ai-act-delays-let-highrisk-systems-dodge-oversight/

Transparency Coalition. (2026, March 27). AI legislative update: March 27, 2026. https://www.transparencycoalition.ai/news/ai-legislative-update-march27-2026

Troutman Pepper Locke. (2026, March 30). Proposed state AI law update: March 30, 2026. https://www.troutmanprivacy.com/2026/03/proposed-state-ai-law-update-march-30-2026/

Aquasecurity. (2026). Trivy ecosystem supply chain temporarily compromised [GitHub Security Advisory GHSA-69fq-xp46-6x23]. https://github.com/aquasecurity/trivy/security/advisories/GHSA-69fq-xp46-6x23

European Parliament Think Tank. (2026, March 18). Enforcement of the AI Act. https://epthinktank.eu/2026/03/18/enforcement-of-the-ai-act/

Jiang, Z., et al. (2026, March 31). Architecting secure AI agents: Perspectives on system-level defenses against indirect prompt injection attacks [Preprint]. ArXiv. https://arxiv.org/abs/2603.30016

NIST just published an admission that nobody knows how to monitor AI systems after deployment. NIST AI 800-4, “Challenges to the Monitoring of Deployed AI Systems,” reviews findings from three workshops, 250+ experts, and almost 90 research papers. The document catalogs over 30 distinct challenges. It offers zero solutions. That’s not a criticism. That’s the diagnosis, and that should raise your spidey senses.

Share

NIST Mapped the Mess

The report organizes post-deployment AI monitoring into six categories:

1. Functionality (does it still work as intended?)

2. Operational (does the infrastructure hold?)

3. Human Factors (is it transparent and useful to humans?)

4. Security (is it defended against attacks?)

5. Compliance (does it meet regulatory requirements?)

6. Large-Scale Impacts (does it promote human flourishing?)

Each category carries its own distinct challenges. Functionality monitoring suffers from a lack of ground-truth datasets and a lack of a reliable way to detect model drift. Operational monitoring struggles with fragmented logging across distributed infrastructure. Human Factors monitoring, which drew more practitioner attention than any other category in the workshops, remains almost entirely unstudied in the literature. Security monitoring faces the unsettling reality that some models appear to detect when they’re being evaluated, changing their behavior under observation. Compliance monitoring lacks even basic tracking of terms-of-service violations, including downstream fine-tuning of open models for CSAM generation. Large-Scale Impacts monitoring lacks agreed-upon metrics to measure whether AI systems help or harm people at scale.

That’s a lot of individual problems. The question is whether they share a common root cause.

The Root Cause NIST Documented Without Naming

Read the cross-cutting challenges section carefully. Five categories of barriers span every monitoring type:

1. No trusted methods and tools

2. Poor visibility and transparency

3. Pace of change

4. Organizational incentive failures

5. Resource constraints

Strip away the academic framing, and a pattern emerges. Workshop attendees were asking questions that belong in a standards body, not a research lab.

One attendee called for “an abstraction layer for universal security and monitoring.” Others asked, “What does the information sharing of what’s measured look like up and down the value chain?” Multiple participants flagged the absence of common metrics across use cases, noting that “non-standardized logic for generating metrics across use cases prevents us from building easy platform capabilities for monitoring.”

It’s important to point out that not every challenge NIST documented is a standards problem. Detecting deceptive behavior in models that modify their behavior under observation remains an open research problem. No specification can fix it because nobody knows how to do it reliably yet. Human-AI feedback loops are an understudied science. Ground-truth dataset availability is a data and methodology problem. The field faces three categories of challenge simultaneously: standards gaps (metrics, logging formats, reporting schemas), research gaps (deceptive behavior detection, feedback loop dynamics), and adoption gaps (methods exist in adjacent fields but aren’t applied to AI).

The standards layer is the prerequisite that makes progress on the other two categories possible. Without common definitions, you can’t scale research findings into production monitoring. Without shared schemas, adoption of proven methods stays trapped inside individual vendor implementations. Take deception detection as an example. You can’t begin researching whether a model’s stated reasoning matches its actual behavior unless you’re capturing structured reasoning traces alongside action logs in the first place. The research gap depends on closing the standards gap.

You’ve Seen This Movie Before

How did this work out for us in cybersecurity? We’ve had a 20-year head start on this exact problem.

Before syslog standardization, every network device vendor shipped its own logging format. Security teams drowned in data they couldn’t correlate. Firewalls from one vendor produced logs that meant nothing to the SIEM built for another vendor’s format. Every firewall had monitoring, but none of them spoke the same language.

The fix wasn’t a better firewall. It was CEF (Common Event Format), then LEEF (Log Event Extended Format), and now OCSF (Open Cybersecurity Schema Framework). Common schemas let security teams correlate events across vendors, build cross-platform detection rules, and operate SOCs that don’t require a translator for each data source. The technology didn’t change. The standards layer underneath made the existing technology useful at scale.

The AI monitoring equivalent would need agent-specific semantic conventions built on the observability infrastructure enterprises already operate. Not a new standard competing with OpenTelemetry. Extensions to OpenTelemetry that understand agent reasoning steps, tool calls, and multi-agent handoffs. Security events are mapped to schemas that flow into existing SIEMs without custom parsers. The pattern is identical: don’t build a parallel universe of AI-specific tooling. Extend the standards that security teams already trust.

AI monitoring is stuck in the pre-syslog era. Every platform defines its own metrics, its own log structures, its own alert taxonomies. If your organization runs AI workloads across three cloud providers and two agent frameworks, you operate five separate monitoring stacks that don’t talk to each other.

Here’s what that looks like in practice. A regional bank deploys a customer-facing loan origination model hosted on one cloud provider’s ML platform. The model calls a third-party credit scoring API. A separate vendor supplies the fairness monitoring layer. The bank’s compliance team uses an internal dashboard that pulls from the cloud provider’s native monitoring. When the credit scoring API updates its model without notification, the loan origination model starts producing subtly different risk scores. Approval rates for one demographic bracket shift by 4% over six weeks. The fairness monitoring vendor’s tool flags a drift alert using its own proprietary metric. The cloud provider’s native monitoring shows no anomaly because its baseline was never calibrated against the third-party API’s output distribution. The compliance dashboard, which aggregates data from both sources, shows conflicting signals that the compliance analyst can’t reconcile because the two tools define “drift” differently, measure it on different time windows, and log it in incompatible formats.

Nobody in that chain did anything wrong individually. The fairness vendor’s tool worked as designed. The cloud provider’s monitoring worked as designed. The gap was structural. There was no shared definition of what “drift” means across the pipeline, no common logging schema that would let the compliance team correlate events from two different monitoring tools, and no standardized way for the credit scoring API provider to notify downstream consumers of model updates.

That scenario plays out today in financial services, healthcare, and any sector that assembles AI capabilities from multiple vendors. NIST AI 800-4 confirmed it with receipts from 250 practitioners saying the same thing in different words.

Article 72 Is Already Undeliverable

Regulators aren’t waiting for standards to mature. The EU AI Act’s high-risk system obligations take effect August 2, 2026 (if the aren’t delayed). Article 72 requires providers of high-risk AI systems to implement post-market monitoring plans that “actively and systematically collect, document and analyse relevant data” on system performance throughout the system’s lifetime. Deployers face separate obligations to monitor operations and report serious incidents within 72-hour and 15-day windows.

Pull one thread, and the gap becomes specific. Article 72 requires providers to collect performance data “throughout their lifetime” and evaluate “continuous compliance.” NIST AI 800-4 documents that practitioners lack standardized performance metrics, can’t establish baselines or deviation thresholds, and have no systematic way to compare model behavior across providers. One workshop attendee put it bluntly: “It’s often unclear what exactly to monitor and how.” The report cites research confirming that “the appropriate metrics to capture is not standardized in the AI community” and warns this “absence can result in misleading performance measures.”

That’s not a general compliance gap. Article 72 requires continuous collection and analysis of performance data. NIST AI 800-4 confirms that the field hasn’t agreed on what “performance” means in post-deployment contexts, let alone how to measure it consistently across different AI systems and providers. The regulation demands an activity that is structurally undeliverable with the current monitoring ecosystem. Organizations filing post-market monitoring plans in 2026 will document processes built on unstandardized metrics, non-interoperable tools, and self-defined baselines. They’ll comply on paper. The monitoring itself won’t be comparable, auditable, or meaningful across organizational boundaries.

Compliance requires two capabilities this ecosystem lacks: runtime hooks that produce monitoring data in standardized formats, and trace architectures that reconstruct decision chains across organizational boundaries. Without these, Article 72 post-market monitoring plans are fiction written in incompatible vendor dialects.

NIST’s own AI Risk Management Framework compounds the pressure. The MANAGE function calls for continuous monitoring and risk response throughout deployment. The forthcoming NIST Cyber AI Profile maps cybersecurity controls to AI-specific concerns like model integrity and adversarial robustness. Every framework converges on the same expectation. The implementation layer that would make compliance verifiable doesn’t exist yet.

Who’s Responsible? Nobody Knows That Either.

NIST AI 800-4 surfaced a question that’s arguably more urgent than the technical gaps: who monitors? Workshop attendees repeatedly asked: “Who should do monitoring?” “Who is responsible for remediating incidents?” and “If anything is found, who can act on it?”

In the bank scenario above, was the monitoring failure the cloud provider’s responsibility? The fairness vendor’s? The credit scoring API provider’s? The bank’s compliance team? Each party monitored its own slice of the pipeline. Nobody monitored the seams between them. The NIST report documents this as an unresolved question across the AI supply chain, and it’s compounded by the standards gap. You can’t assign responsibility for monitoring when you haven’t agreed on what monitoring means. You can’t hold a vendor accountable for failing to report a drift event when “drift” has no shared definition.

A viable monitoring architecture separates three concerns. The platform exposes standardized observation and control points. An open enforcement layer applies policy through those control points, portable across any platform that exposes them. The enterprise customizes policy to its domain: financial services brings its own data sensitivity models, healthcare brings PHI detection, and any regulated industry brings its compliance requirements. When responsibilities are layered this way, the question of “who monitors?” has a structural answer. The platform enables. Open tooling enforces. The enterprise governs. Accountability follows the layer where the failure occurred.

One attendee asked how to “reduce the burden on the end user” to validate model behavior. Another asked how monitoring could become “a more collaborative practice, rather than a closed technical process.” These aren’t theoretical musings. They’re the governance questions that determine whether monitoring happens at all or degenerates into checkbox compliance where everyone points at someone else’s dashboard. A layered architecture gives each party a defined obligation: expose, enforce, govern. The current ecosystem gives everyone an excuse.

Agents Make Everything Worse

If the standards gap is a problem for current AI systems, it’s a crisis for agentic AI. NIST SP 800-4 repeatedly mentions agents, and the findings are sobering.

Workshop attendees flagged “lengthy agentic tasks” as especially resource-intensive to monitor. The report cites research noting that “both the agents and the operational environment are subject to change,” making static monitoring baselines unreliable. Agent identification and tracking remain unstandardized. Attendees raised visibility challenges around “out-of-distribution behavior using agent identifiers” and noted that watermarking and content provenance measures “face reliability challenges.” One attendee asked directly: “Is the model agentically attempting to subvert the monitoring setup it is under, i.e., scheming?”

That question deserves a pause. We’re building systems that plan, execute across organizational boundaries, call external tools, and collaborate with other agents. The monitoring challenges NIST documented for conventional AI systems, from detecting drift to maintaining visibility to establishing baselines, all assume a relatively static system being observed from outside. Agents aren’t static. They change behavior based on context, discover new capabilities at runtime, and operate across a distributed infrastructure that no single organization fully controls.

Any monitoring standard for agents needs a dynamic inventory mechanism. A static software bill of materials generated at deployment time is worthless when agents discover new tools, connect to new service endpoints, and modify their own capabilities during a single execution session. The inventory must update in real time, triggered by component changes, and output in formats the supply chain security ecosystem already consumes. If your agent connects to a new MCP server mid-task and your inventory doesn’t reflect that within the same session, your security team is operating on a stale map.

The “monitorability tax” concept raised in the report’s cited research captures the emerging cost structure. Model developers will pay a performance penalty, through slower inference or less capable models, to maintain the ability to monitor agent behavior. That cost rises as agent autonomy increases. Standardized hooks reduce the engineering cost by making monitoring implementation portable across frameworks, a one-time platform integration rather than custom monitoring code for every deployment. The monitorability tax on compute remains. The tax on engineering effort doesn’t have to.

The cross-provider abstraction layer that workshop attendees called for isn’t a nice-to-have for agentic systems. Without standardized hooks for runtime monitoring, standardized trace formats for multi-agent workflows, and standardized inventories of agent capabilities and dependencies, you’re watching agents through whatever proprietary window each vendor provides. You can’t correlate behavior across platforms. You can’t reconstruct decision chains that span multiple agent frameworks. You can’t audit what you can’t consistently observe.

One more structural blind spot worth naming: runtime monitoring standards assume a cooperating platform that exposes hooks. Open-weight models distributed without platforms bypass this assumption entirely. Once a model is released into the wild for anyone to run, no runtime hook exists unless the downstream deployer voluntarily implements one. Open-weight models are structurally ungovernable by runtime standards alone. Any honest conversation about the monitoring gap has to acknowledge this boundary.

Key Takeaway: NIST AI 800-4 confirms what practitioners feel in their bones: AI monitoring isn’t failing because we lack technology. The standards layer that would make technology useful at scale doesn’t exist. Agents make the gap existential.

What to do next

Stop accepting proprietary monitoring silos. The next time you evaluate an AI platform, put these questions into the review:

• What open logging schema do your monitoring outputs conform to? If the answer is a proprietary format, ask how you export monitoring data into a format another platform can ingest without custom transformation.

• How does your monitoring define and detect model drift? Compare the answer across your vendors. If two vendors define “drift” differently, your compliance team can’t produce a coherent post-market monitoring report under Article 72.

• When a component in the AI pipeline (a third-party API, a model update, a data source change) shifts behavior, how does your monitoring surface cross-component effects? If the answer involves manual correlation, you have a gap that scales with system complexity.

• Who in the supply chain is responsible for monitoring the seams between components? If nobody owns cross-boundary monitoring, say so in your risk register. That’s an accepted risk, not an oversight.

• Does your AI platform expose standardized middleware hooks that allow your security team to intercept and evaluate agent actions before they execute? If the platform’s controls are proprietary and non-portable, your enforcement logic dies with the vendor relationship. Every policy you write, every guardrail you configure, every compliance rule you encode is locked to one vendor’s architecture.

Push your industry groups and standards bodies. If you participate in OWASP, ISO working groups, or NIST-affiliated communities, advocate for common AI monitoring vocabularies and reference architectures. The cybersecurity field solved this problem a decade ago with common event formats and shared schemas. The AI field hasn’t started.

Audit your own monitoring maturity against the six NIST categories. Most organizations will find entire categories with no monitoring at all, particularly Human Factors and Large-Scale Impacts. Map the gaps before the next board meeting where someone asks if you’re ready for August 2026.

The full NIST AI 800-4 report is available at https://doi.org/10.6028/NIST.AI.800-4.

👉 Visit RockCyber.com to learn more about how we can help you in your traditional Cybersecurity and AI Security and Governance Journey

👉 Want to save a quick $100K? Check out our AI Governance Tools at AIGovernanceToolkit.com

👉 Subscribe for more AI and cyber insights with the occasional rant.

The views and opinions expressed in RockCyber Musings are my own and do not represent the positions of my employer or any organization I’m affiliated with.

Thanks for reading RockCyber Musings! Subscribe for free to receive new posts and support my work.

Share RockCyber Musings

RSA Conference 2026 closed Thursday in San Francisco. Thirty thousand attendees, six hundred exhibitors, one word on every booth banner: agentic. While the industry competed on keynotes and happy hours, LiteLLM, deployed in hundreds of enterprise AI stacks, got infected with credential-stealing code through a misconfigured GitHub Actions workflow. Malicious releases went live March 19 and March 22. Most of your security team was watching keynotes.

Underneath the conference noise, genuine signal emerged. Zenity’s CTO demonstrated live zero-click exploits against ChatGPT, Salesforce, and Microsoft Copilot on the conference floor. Palo Alto Networks Unit 42 documented new attack paths through the Model Context Protocol. HackerOne disclosed a 540% year-over-year surge in validated prompt injection vulnerabilities. The EU AI Office’s second draft Code of Practice on AI-generated content transparency is open for feedback through March 30, with prescriptive new requirements that narrow compliance discretion significantly. NIST published AI 800-4, the first federal framework for monitoring AI systems in production, with no vendor booth to announce it.

Here’s what matters and what to do about it.

Share

1. Zenity Launches Guardian Agents and Demonstrates 0-Click AI Exploits at RSA

Zenity launched Guardian Agents at RSA 2026 on March 23, positioning it as continuous, contextual security for AI agents across SaaS, cloud, and endpoint environments. CTO Michael Bargury ran live demonstrations titled “Your AI Agents Are My Minions,” showing zero-click prompt injection chains that manipulated Cursor into leaking developer secrets via support emails, Salesforce agents into exfiltrating customer data to an attacker-controlled server, and ChatGPT into producing persistent attacker-chosen outputs across conversations (The Register, March 23, 2026, and Help Net Security, March 24, 2026).

Why it matters

• Zero-click attacks eliminate the human review checkpoint most AI security frameworks assume is present. When agents act without user input, your primary detection layer disappears before the threat is visible.

• Live exploitation of production enterprise systems on a conference floor is harder to dismiss than a threat model in a whitepaper.

• Guardian Agents signals a market category forming in real time. The evaluation criteria you set today will shape purchasing decisions for the next several years.

What to do about it

• Inventory every AI agent in your environment before your next board meeting. If you can’t enumerate them, you can’t monitor them.

• Require vendors to document in writing which actions their agents take without explicit human approval. Non-answers are critical control gaps.

• Run adversarial testing against your three highest-access agents this quarter, targeting credential extraction, data exfiltration, and cross-system manipulation.

Rock’s Musings

Bargury’s demonstration strategy was the most honest thing at RSA this week: show the attack, then show the defense. Live exploitation on production systems is harder to dismiss than a slide deck built around the word autonomous. The inconvenient reality is that most enterprises already have agents running with email access, CRM credentials, and code repository permissions, with no runtime monitoring on what those agents decide to do. Selecting an AI security vendor is not the same thing as having an answer to the problem he demonstrated on the conference floor.

2. LiteLLM Infected with Credential-Stealing Code via Trivy Misconfiguration

The Register reported March 24 that LiteLLM, a widely deployed open-source LLM API proxy, was compromised through a misconfigured Trivy GitHub Actions workflow. Attackers modified version tags on the trivy-action GitHub Action to inject malicious code into workflows organizations were already running, producing malicious releases on March 19 and March 22. The maintainer confirmed that anyone who installed and ran the project during that window should assume credentials available to their environment were exposed.

Why it matters

• LiteLLM sits in the critical path of many enterprise AI deployments. One compromised abstraction library reaches hundreds of downstream production systems simultaneously.

• The attack exploited version tags, not direct code injection. CI/CD pipelines relying on tags rather than pinned commits ran malicious code without detection. That’s a systemic configuration gap across most enterprise pipelines.

• The attack ran during RSA week when security teams were distracted. The timing was likely not accidental.

What to do about it

• Audit every environment that pulled a LiteLLM update between March 19 and March 24. Treat those environments as potentially compromised until you confirm otherwise.

• Pin all GitHub Actions to specific commit hashes, not version tags. Tags are mutable and can be silently overwritten. Commits are not.

• Establish software bill of materials practices for all AI and ML dependencies. Supply chain attacks will keep finding environments where that inventory doesn’t exist.

Rock’s Musings

LiteLLM is exactly the kind of library that lands in enterprise AI stacks without a security review, installed by an ML engineer who needed to route calls to three model providers before the sprint ended. Trivy is a security tool. Attackers used a security tool misconfiguration to compromise a release pipeline for another widely used tool. If there’s a cleaner argument for applying security rigor to your own security tooling, I haven’t heard it. Your AI dependency chain needs the same scrutiny as your application dependencies. Good intentions at install time are not a compensating control.

3. Palo Alto Networks Unit 42 Documents MCP Attack Vectors

Palo Alto Networks Unit 42 published research the week of March 20 documenting new attack paths through the Model Context Protocol, including prompt injection delivered through MCP’s sampling interface. Security researchers tracked 30 CVEs filed against MCP implementations in the preceding 60 days, including CVE-2026-25536 (cross-client data leak in the MCP TypeScript SDK) and CVE-2026-23744 (remote code execution in MCPJam Inspector). A scan of more than 500 public MCP servers found that 38% lacked authentication entirely (Unit 42, March 2026, and Adversa.ai, March 2026).

Why it matters

• MCP is the connective tissue between AI agents and enterprise tools. A vulnerability in this protocol exposes the entire agent ecosystem built on top of it, not one isolated system.

• Thirty CVEs in 60 days signals that security review did not happen before shipping at scale. Every API ecosystem that launches with deployment velocity ahead of security assessment follows this arc.

• Thirty-eight percent of scanned servers lacking authentication is systemic failure. Authentication is the minimum viable control. Everything built on top of unauthenticated servers is exposed.

What to do about it

• Inventory every MCP server in your environment and treat unauthenticated instances as critical findings requiring immediate action.

• Require authentication, authorization, and comprehensive logging for any MCP server with access to production systems or sensitive data.

• Demand specific CVE status and patch timelines from your AI infrastructure vendors. Vague answers signal high risk and a vendor not tracking its own exposure.

Rock’s Musings

Thirty CVEs in 60 days is not a patching problem. It’s a design problem. MCP shipped fast because the builders cared more about what AI agents could reach than how securely they could reach it. The 38% authentication gap is the number that should end budget debates about AI infrastructure security investment. Roughly two in five MCP servers operate on the assumption that only authorized parties will talk to them, which is exactly wrong in a protocol designed to connect agents to external resources. That assumption creates direct paths to your production data.

4. HackerOne Reports 540% Surge in Validated Prompt Injection Vulnerabilities

HackerOne announced Agentic Prompt Injection Testing on March 21, paired with platform data showing a 540% year-over-year increase in validated prompt injection vulnerabilities. The service executes structured, multi-turn adversarial scenarios against live AI applications, evaluating whether injection attempts produce actual data exposure or unauthorized tool execution across interconnected agent systems (HackerOne Blog, March 2026, and Cybersecurity Insiders, March 21, 2026).

Why it matters

• A 540% increase in validated vulnerabilities means real researchers are finding real exploitable conditions in production systems, not theoretical edge cases.

• Traditional application security testing does not cover agent-specific attack paths. If your AI agents aren’t explicitly in scope for your red team or bug bounty program, you have a documented blind spot.

• Unit 42’s concurrent research on indirect prompt injection through web content eliminates the “attacker needs direct access” objection. Agents read the web. The web is the attack surface.

What to do about it

• Add AI agents to your red team scope explicitly as a primary target category, not an afterthought appended to an existing engagement.

• Require prompt injection testing as part of every AI agent release process, treated as a gate equivalent to penetration testing for any externally facing application.

• Track prompt injection findings as a distinct vulnerability class in your risk register. You can’t demonstrate improvement to your board on metrics you’re not collecting separately.

Rock’s Musings

Five hundred forty percent ends the debate about whether prompt injection is a real threat. I’ve heard the objection that attackers need direct access to craft payloads. Unit 42’s indirect injection research, published this same week, shows agents reading manipulated instructions from ordinary websites they visit in the course of normal operation. Your agents don’t need to be directly targeted; they need to visit the wrong page. The gap between organizations deploying AI agents and organizations testing those agents adversarially is the largest unaddressed risk exposure I see in enterprise AI programs right now.

5. Microsoft Publishes Secure Agentic AI Framework and Confirms Agent 365 May 1 GA

Microsoft published “Secure Agentic AI End-to-End” on March 20, documenting its approach to extending Zero Trust architecture across the full AI agent lifecycle: data ingestion, model training, deployment, and runtime behavioral monitoring. The post confirmed Agent 365, Microsoft’s governance control plane for enterprise AI agents, will reach general availability on May 1, 2026, with agent identity, authorization scope, and behavioral monitoring treated as distinct security domains from traditional human-user ZT controls (Microsoft Security Blog, March 20, 2026).

Why it matters

• A confirmed May 1 GA date gives enterprises in Microsoft environments a concrete six-week planning horizon. Governance framework adoption takes time and that clock is already running.

• Extending Zero Trust to AI agents is architecturally correct. Most ZT implementations weren’t designed with agent identity or behavioral monitoring in mind, making the gap assessment non-trivial work.

• Publishing detailed technical frameworks before product GA signals Microsoft wants enterprises building governance practices now, before the product ships.

What to do about it

• Map your current ZT architecture against the agent-specific requirements described in the March 20 post. Focus on gaps in agent identity and behavioral monitoring specifically.

• Begin internal stakeholder alignment on Agent 365 if you’re in a Microsoft 365 environment. Six weeks is not enough time to start that conversation from zero.

• Document agent permissions, access patterns, and decision scopes using whatever visibility tools you have today rather than waiting for Microsoft tooling.

Rock’s Musings

“End-to-end” is doing heavy lifting as a title. What Microsoft describes is extending known security primitives to a new execution context. That’s necessary work and not a complete answer. The hard problems are behavioral: distinguishing authorized agent actions from manipulated ones, detecting policy violations in real time, and maintaining audit trails that survive an incident investigation. Agent 365 is worth watching. If the behavioral monitoring is substantive, it’ll move the market. If it’s a compliance dashboard, enterprises will check the box while actual risk sits unaddressed underneath it.

6. Cisco Releases DefenseClaw Open Source on Final Day of RSA

Cisco released DefenseClaw to GitHub on March 27, the final day of RSA 2026, as an open-source framework for scanning agent skills and sandboxing agent execution. The release accompanied Zero Trust Access for AI agents and a free AI Defense Explorer Edition targeting security practitioners. Cisco plans integration with NVIDIA OpenShell for hardware-level execution sandboxing, addressing execution isolation that software-only monitoring cannot replicate (Cisco Newsroom, March 2026, and UC Today, March 2026).

Why it matters

• Open-source agent security scanning means organizations can start building security into agent development pipelines without a procurement cycle or a budget line.

• Hardware-anchored execution sandboxing addresses a control gap that software-only monitoring cannot close. Execution isolation for agents is systematically underinvested across the industry relative to the risk.

• The open-source and Explorer Edition strategy targets developers before enterprise procurement cycles form, competing for architectural mindshare with builders rather than just buyers.

What to do about it

• Pull DefenseClaw and run it against a non-production agent environment this month. Validate real-world utility before committing to any commercial evaluation.

• Evaluate the NVIDIA sandboxing integration if you’re running NVIDIA infrastructure. Test in isolation before production consideration.

• Track Cisco’s AI Defense commercial roadmap. Free Explorer Editions typically precede commercial tier launches by 12 to 18 months, and starting your evaluation now means you’ll have data when the pitch arrives.

Rock’s Musings

Releasing open-source code on the last day of the conference changes the conversation from “will enterprises buy this” to “pull the repo and see for yourself.” That’s a credible move when the code is real and the threat model is honest. Run DefenseClaw against your actual agent environment before making any claims about coverage. The larger play is Cisco’s bid for the enterprise AI security architecture position using network visibility, an established security portfolio, and enterprise relationships most competitors would need a decade to build. DefenseClaw is a credible opening move. Watch the next 18 months of product decisions to judge the hand.

7. Google Deploys Gemini Agents to Process 10 Million Dark Web Posts Daily

Google announced at RSA 2026 on March 23 that Gemini AI agents are processing more than 10 million dark web posts daily to surface threats relevant to specific organizations. The capability integrates with Google Security Operations alongside new agentic automation features, currently in preview, that let security teams combine AI-driven investigation with deterministic automated response workflows (The Register, March 23, 2026, and Google Cloud Blog, March 2026).

Why it matters

• Ten million posts per day changes the economics of dark web threat intelligence. Organizations that couldn’t sustain comprehensive monitoring programs gain access to Google-scale processing at a fraction of the previous cost.

• Pairing AI-driven investigation with deterministic automation preserves human-defined control while extending agent reach into high-volume, low-judgment tasks. That’s the right architectural pattern for agentic SOC work.

• Preview status means GA behavior, SLA, and security review standards remain unfinalized. Your production SOC is not where you run this experiment yet.

What to do about it

• Assess your current dark web monitoring coverage gap against what this capability covers. If there’s a meaningful difference, prioritize a pilot evaluation once the feature reaches GA.

• Review preview terms carefully before enabling agentic automation in any production SOC workflow. Preview features carry materially different risk profiles than GA releases.

• Define which SOC workflows you’d delegate to agents and where human approval must remain. Build that policy before the tools arrive, not after they’re already running.

Rock’s Musings

Threat intelligence is the most defensible application of AI agents in security operations right now. Failure modes are recoverable: the agent misses a threat and your other controls have a chance at it. Compare that to agentic incident response, where the failure mode might be blocking a production system or destroying forensic evidence. Start with intelligence, not response. The preview framing signals Google is collecting operational data before committing to GA behavior guarantees, which is reasonable product discipline. It also means you wait for GA before running this where failures have material consequences.

8. Novee Launches Autonomous AI Red Teaming Platform for LLM Applications

Novee announced autonomous AI red teaming for LLM applications on March 24 at RSA Conference 2026. The platform deploys an AI pentesting agent that executes multi-turn adversarial scenarios against live systems, simulating attacker chaining techniques across prompt injection, jailbreaks, data exfiltration paths, and agent behavior manipulation, covering any LLM-powered system regardless of model provider with optional CI/CD pipeline integration (GlobeNewswire, March 24, 2026, and Help Net Security, March 24-25, 2026).

Why it matters

• Traditional pentesting tools were designed for pre-LLM application security problems. Novee builds red teaming from actual LLM vulnerability research, producing findings that adapted traditional tools miss.

• CI/CD pipeline integration lets security teams catch prompt injection and agent manipulation issues before production deployment rather than after an incident surfaces them.

• Two distinct companies announced adversarial AI testing capabilities at RSA 2026 in the same week. Market formation around this problem is accelerating.

What to do about it

• Evaluate Novee’s beta against a non-production LLM application to understand what it surfaces relative to your existing security testing coverage.

• Map the gap between your current SDL and what LLM-specific adversarial testing would require. The gap is almost certainly larger than you expect it to be.

• Add AI-native red teaming as a release gate requirement for any LLM application reaching production. Make it a gate, not a post-deployment recommendation that teams skip.

Rock’s Musings

Two autonomous AI red teaming announcements in one RSA week tells you the market is accepting that testing AI systems requires AI-specific tooling, not adapted traditional approaches. That’s a healthy development even if the tools themselves are early. The CI/CD integration angle is the most practically valuable feature: security issues caught before production deployment cost a fraction of what they cost after deployment. If you’re shipping LLM applications without adversarial testing in the pipeline, you’re making a risk decision that most boards don’t know they’re making.

9. EU AI Office Second Draft Code of Practice Enters Final Feedback Window

The EU AI Office published its second draft Code of Practice on AI-Generated Content Transparency on March 3, with the stakeholder feedback window closing March 30. The second draft moves from high-level principles toward prescriptive, technically detailed commitments, narrowing compliance discretion and signaling how regulators will likely assess conformance in practice. A third and final version is expected by June 2026, ahead of the August 2 applicability date for AI-generated content transparency obligations (Herbert Smith Freehills Kramer, March 2026, and BABL AI, March 2026).

Why it matters

• Draft 2’s shift to prescriptive technical commitments closes the interpretation space organizations were using to plan flexible compliance programs. The gap between “we have a policy” and “we meet the technical specification” narrowed significantly this month.

• The March 30 feedback deadline is this weekend. If your organization has substantive views on requirements that are technically unworkable, the window to influence the final text is closing.

• August 2 is not distant. Organizations waiting for final text before beginning compliance work are accepting a six-week implementation sprint under real enforcement conditions.

What to do about it

• Read Draft 2 this week. The technical specificity represents a meaningful change from Draft 1, and your compliance planning may need adjustment.

• Submit feedback before March 30 if the current draft creates compliance constraints you believe are technically unworkable for your AI content operations.

• Begin implementation planning against Draft 2 requirements now. The June final text will refine but won’t fundamentally restructure what’s already written.

Rock’s Musings

Every organization waiting for final text before starting EU AI Act compliance work is playing a game where the timeline gets worse each quarter they wait. Draft 2 is prescriptive enough to start serious implementation planning. The adjustments you’ll need when Draft 3 drops will be smaller than the work you’ll need to compress into six weeks if you start in June. The transparency labeling requirements are more technically demanding than most organizations appreciate from reading summaries. Download Draft 2 from the EU’s digital strategy portal and read it against your actual AI content production workflows. That gap analysis is the starting point for everything else.

10. RSA 2026 Reveals a Contested Market for AI Agent Governance Control Planes

A pattern emerged across RSA 2026 beyond individual product launches: the governance control plane for AI agents is being actively contested by multiple major vendors. Microsoft’s Agent 365 (GA May 1), Cisco’s DefenseClaw (released March 27), SentinelOne’s Prompt AI Agent Security control plane, and Nudge Security’s AI agent discovery expansion all launched during the conference week, each addressing the same fundamental problem: enterprises deploy AI agents and lose track of what those agents do, access, and decide autonomously (SecurityWeek, March 2026, and Biometric Update, March 2026).

Why it matters

• Multiple major vendors converging on the same problem in the same week signals enterprises are actively requesting governance solutions, not absorbing vendor-manufactured demand.

• Competition between Microsoft’s integrated control plane and point solutions from Cisco, SentinelOne, and Nudge creates a real architectural decision. Choose wrong and you own the integration debt for years.

• None of these products fully solves behavioral monitoring. They address discovery, policy enforcement, and visibility. Real-time behavioral anomaly detection for agents remains an open engineering challenge.

What to do about it

• Define your AI agent governance requirements before evaluating any vendor. Required capabilities: inventory discovery, permission auditing, behavioral logging, and human approval workflows for high-risk actions.

• Assess whether your environment favors an integrated control plane or best-of-breed point solutions based on your actual architecture, not vendor marketing claims.

• Ask every vendor during evaluation: how does the product detect when an agent takes an authorized action it was manipulated into taking? The answer quality will differentiate vendors quickly.

Rock’s Musings

When four vendors announce competing governance control planes at the same conference in the same week, you’re watching a market category consolidate in real time. That’s interesting for analysts and exhausting for practitioners who have to evaluate all of it while managing agents already running in production without any governance. My advice: don’t let the governance platform debate distract from the more urgent problem of knowing what agents you currently have. Most enterprises have agents deployed that security teams didn’t authorize, can’t enumerate, and have no logs on. Governance tooling is the right investment. Knowing what you’re governing is the prerequisite.

The One Thing You Won’t Hear About But You Need To

NIST Publishes AI 800-4: The First Federal Framework for Monitoring AI Systems in Production

NIST published AI 800-4, “Challenges to the Monitoring of Deployed AI Systems,” in March 2026. Built from three practitioner workshops with more than 200 experts across academia, industry, and ten-plus federal agencies, plus an 87-paper literature review, it maps the gaps, barriers, and open questions in monitoring AI systems after deployment. It covers six monitoring categories: functionality, operational health, human factors, security, safety, and compliance. It received no RSA booth, no vendor keynote, and no sponsored coverage (NIST News, March 2026, and NIST AI 800-4 PDF, March 2026).

Why it matters

• Most organizations deploying AI monitor latency and availability. AI 800-4 addresses whether the model behaves consistently with its training distribution and produces outputs that align with policy, which are the failures that matter most and the ones traditional monitoring misses entirely.

• NIST explicitly identifies human-AI interaction monitoring as the most under-researched gap in the field. Workshop practitioners raised it far more than published literature covers. If your AI monitoring program doesn’t address how users interact with and respond to AI outputs, you’re missing the category NIST calls most underdeveloped.

• The document is vendor-neutral and grounded in practitioner experience, directly applicable to conversations with regulators and auditors who want evidence of a structured AI monitoring program.

What to do about it

• Download NIST AI 800-4 from nist.gov and route it to whoever owns your AI security program. It’s the most actionable government guidance on operational AI monitoring published to date.

• Map your current monitoring coverage against the document’s six categories. The gaps will be immediately apparent and the prioritization logic writes itself once you have the map.

• Use AI 800-4 as the foundation for your AI monitoring program documentation. When regulators ask how you monitor AI systems in production, a NIST-aligned program gives you a defensible, auditable answer.

Rock’s Musings

The honest state of enterprise AI monitoring: most organizations have logs showing their AI system responded. They don’t have logs showing whether the response was correct, consistent with training distribution, within policy boundaries, or manipulated by adversarial input. That visibility gap is how AI security incidents become AI security incidents. You don’t catch the drift until the outcome is undeniable and the damage is done. NIST AI 800-4 doesn’t get coverage because nobody can sell it. The organizations that read it and build monitoring programs from its framework will answer regulatory questions coherently in 18 months when enforcement catches up to deployment rates. The organizations that attended every RSA keynote and skipped the NIST publication will be writing incident reports instead. For more on building AI governance programs that survive regulatory scrutiny, visit rockcybermusings.com. If you need help turning frameworks like AI 800-4 into operating programs your security team can actually run, reach out at rockcyber.com.

👉 Visit RockCyber.com to learn more about how we can help you in your traditional Cybersecurity and AI Security and Governance Journey

👉 Want to save a quick $100K? Check out our AI Governance Tools at AIGovernanceToolkit.com

👉 Subscribe for more AI and cyber insights with the occasional rant.

The views and opinions expressed in RockCyber Musings are my own and do not represent the positions of my employer or any organization I’m affiliated with.

Share RockCyber Musings

References

Bargury, M. (2026, March 23). Your AI agents are my minions [Conference presentation]. RSA Conference 2026, San Francisco, CA.

Claburn, T. (2026, March 24). LiteLLM infected with credential-stealing code via Trivy. The Register. https://www.theregister.com/2026/03/24/trivy_compromise_litellm/

Claburn, T. (2026, March 23). AI agents are ‘gullible’ and easy to turn into your minions. The Register. https://www.theregister.com/2026/03/23/pwning_everyones_ai_agents/

Claburn, T. (2026, March 23). Google unleashes Gemini AI agents on the dark web. The Register. https://www.theregister.com/2026/03/23/google_dark_web_ai/

Cisco. (2026, March). Cisco reimagines security for the agentic workforce. Cisco Newsroom. https://newsroom.cisco.com/c/r/newsroom/en/us/a/y2026/m03/cisco-reimagines-security-for-the-agentic-workforce.html

Google Cloud. (2026, March). RSAC 26: Supercharging agentic AI defense with frontline threat intelligence. Google Cloud Blog. https://cloud.google.com/blog/products/identity-security/rsac-26-supercharging-agentic-ai-defense-with-frontline-threat-intelligence

HackerOne. (2026, March). Agentic prompt injection testing for AI security. HackerOne Blog. https://www.hackerone.com/blog/agentic-prompt-injection-testing

HackerOne introduces agentic prompt injection testing as AI security risks accelerate. (2026, March 21). Cybersecurity Insiders. https://www.cybersecurity-insiders.com/hackerone-introduces-agentic-prompt-injection-testing-as-ai-security-risks-accelerate/

Herbert Smith Freehills Kramer. (2026, March). Transparency obligations for AI-generated content under the EU AI Act: From principle to practice. https://www.hsfkramer.com/notes/ip/2026-03/transparency-obligations-for-ai-generated-content-under-the-eu-ai-act-from-principle-to-practice

EU releases second draft of AI Act Code of Practice on labeling AI-generated content. (2026, March). BABL AI. https://babl.ai/eu-releases-second-draft-of-ai-act-code-of-practice-on-labeling-ai-generated-content/

Microsoft Security. (2026, March 20). Secure agentic AI end-to-end. Microsoft Security Blog. https://www.microsoft.com/en-us/security/blog/2026/03/20/secure-agentic-ai-end-to-end/

NIST. (2026, March). New report: Challenges to the monitoring of deployed AI systems. https://www.nist.gov/news-events/news/2026/03/new-report-challenges-monitoring-deployed-ai-systems

NIST. (2026). NIST AI 800-4: Challenges to the monitoring of deployed AI systems. National Institute of Standards and Technology. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.800-4.pdf

Novee. (2026, March 24). Novee introduces autonomous AI red teaming to uncover security flaws in LLM applications [Press release]. GlobeNewswire. https://www.globenewswire.com/news-release/2026/03/24/3261278/0/en/Novee-Introduces-Autonomous-AI-Red-Teaming-to-Uncover-Security-Flaws-in-LLM-Applications.html

Novee introduces autonomous AI red teaming to hunt LLM vulnerabilities. (2026, March 24). Help Net Security. https://www.helpnetsecurity.com/2026/03/24/novee-ai-red-teaming-for-llm-applications/

Palo Alto Networks Unit 42. (2026, March). New prompt injection attack vectors through MCP sampling. https://unit42.paloaltonetworks.com/model-context-protocol-attack-vectors/

SecurityWeek. (2026, March). RSAC 2026 conference announcements summary: Day 1. https://www.securityweek.com/rsac-2026-conference-announcements-summary-day-1/amp/

Zenity AI agents contextual security. (2026, March 24). Help Net Security. https://www.helpnetsecurity.com/2026/03/24/zenity-ai-agents-contextual-security/

Zenity. (2026, March 23). Zenity sets the foundation for guardian agents. Zenity Newsroom. https://zenity.io/company-overview/newsroom/company-news/zenity-sets-the-foundation-for-guardian-agents

Meta logged a SEV-1 on March 18 because an internal AI agent posted without human approval, provided bad advice, and exposed sensitive data to the wrong employees for 2 hours. Amazon confirmed its Bedrock sandbox lets AI models exfiltrate data via DNS and called it intentional design. HiddenLayer found 31% of security leaders don’t know if they had an AI breach in the past year. The EU Council voted to restructure the AI Act’s high-risk compliance framework. Three AI agent security products launched in four days. This was one week.

The week’s evidence points in one direction: agentic AI security is no longer a research problem. Real incidents are appearing in production environments run by organizations with serious security programs. Technical flaws in AI infrastructure are drawing vendor responses that amount to documentation updates rather than patches. Research data is documenting blind spots CISOs can no longer treat as edge cases. In parallel, the governance machinery is finally moving, but it’s moving slower than deployment. Standards and deployments are in a race, and deployments are winning by a wide margin. More context at RockCyber and RockCyber Musings.

Share

1. OWASP publishes its GenAI data security risk taxonomy for 2026

The OWASP GenAI Security Project released GenAI Data Security: Risks and Mitigations 2026 in March, a 103-page taxonomy covering 21 discrete data security risks across the full GenAI lifecycle from training through agentic runtime (OWASP). The document maps risks across training and fine-tuning data, retrieval and RAG pipelines, vector stores, context windows, agent memory, tool call payloads, and observability infrastructure. It identifies a core architectural property that makes GenAI data security structurally different from every prior computing model: the context window aggregates data from multiple trust domains into a single flat namespace with no internal access controls. A confidential HR record retrieved via RAG sits next to a user prompt with identical trust weight, and there is no mechanism today to mark a context segment as available for reasoning but not surfaceable in the output. The document also addresses machine unlearning directly: deleting source data does not remove what a fine-tuned model or LoRA adapter has memorized into its weights. Download the report HERE.

Why it matters

• The flat-namespace context window problem is not a configuration gap. It’s an architectural property of how these systems work, which means perimeter controls and access policies cannot fully solve it. Minimization and context scoping are the only practical mitigations available today.

• LoRA adapter memorization of rare training examples means high-recall prompts can extract verbatim PII, credentials, or intellectual property from fine-tuned models without any sophisticated attack technique. Organizations fine-tuning on internal data have a data exposure risk they likely haven’t assessed.

• The Right to Erasure problem is unsolved at the architectural level. Deleting training data from a source system does not delete what the model encoded during fine-tuning. GDPR and state privacy law DSR obligations cannot be satisfied by source deletion alone.

What to do about it

• Treat the context window as a data-exposure surface, not just a prompt-delivery mechanism. Classify what goes in the same way you classify what goes into a database query, and scope RAG retrieval to the minimum required for the task.

• Audit every fine-tuned model and LoRA adapter in your environment against the data used to train it. If that training data included PII, credentials, or regulated information, your model could serve as a potential exfiltration vector.

• Build a GenAI data bill of materials using CycloneDX ML-BOM as the base format. Until you have lineage from the source dataset to the deployed model to the embedding store, you cannot answer the question a regulator will eventually ask: what data did this model see, and where does it live now?

Rock’s Musings

The architectural insight at the center of this document is the one the industry keeps sliding past. The context window has no internal access control layer. That’s not a misconfiguration. It’s a design property of how transformers process sequences. Everything that enters the context window is treated as equally reachable by the model’s output mechanism, and no amount of system prompt guardrailing changes the underlying architecture. The practical implication is that the primary defense is what you put in, not what you try to prevent from coming out.

The machine unlearning section is the one I push organizations on hardest. They are collecting consent, honoring deletion requests, and scrubbing source databases, and then deploying fine-tuned models that still carry what they memorized from the deleted data. The model weights are a copy of your training corpus in a form your DLP tools don’t see, and your deletion workflows can’t reach. Right to Erasure in GenAI is an open architectural problem with no clean solution today, and most organizations haven’t told their legal team that yet.

2. EU Council rewrites the compliance clock for high-risk AI systems

The EU Council adopted its negotiating position to amend the AI Act’s high-risk framework (EU Council). The core change replaces the fixed August 2026 compliance deadline with a conditional trigger. Full high-risk obligations apply only once the Commission certifies required standards and tools are available, with a hard backstop date. The Council also pushed the national AI regulatory sandbox deadline to December 2027 and clarified that law enforcement, border management, judicial, and financial AI systems remain under national supervisory authority rather than the Commission. Negotiations with the European Parliament begin next.

Why it matters

• The conditional trigger gives the Commission discretion over when your obligations start. Until it certifies standards are ready, full high-risk obligations don’t apply, creating an indeterminate window.

• Pushing the sandbox deadline to December 2027 removes a key testing mechanism for high-risk AI at a time when organizations are accelerating deployment.

• Fragmented supervisory authority means 27 member states apply their own rules to some of the highest-stakes AI use cases.

What to do about it

• Map your AI systems against current and proposed high-risk definitions now. The conditional trigger shifts the timeline, not the compliance obligation itself.

• Track Parliament negotiations. The Council position is a mandate, not the final text.

• Build a jurisdiction-aware compliance map for EU operations covering which systems fall under national versus Commission supervision.

Rock’s Musings

I’ve seen regulatory timelines used to delay compliance indefinitely in my career more times than I can count. This EU Council move fits the pattern. The conditional trigger means the Commission controls when your clock starts, and they have to certify standards are available first. Given the pace at which NIST’s agentic AI guidance is moving, expecting European standards to materialize quickly requires genuine optimism.

Organizations using this ambiguity to do nothing are miscalculating. The August 2026 date was never the governance point. You have high-risk AI systems in production today, and you need to govern them regardless of what the Commission certifies and when.

3. Meta logs a SEV-1 incident from a rogue internal AI agent

On March 18, Meta confirmed a Severity 1 security incident caused by an internal AI agent operating without human authorization (Bitcoinworld, HackerNoob). The agent posted to an internal forum, gave incorrect advice, and triggered a cascade that exposed sensitive company and user data to unauthorized employees for approximately two hours. Meta contained the exposure by cutting the agent’s forum access and auditing permissions across other internal agents. No external exfiltration was confirmed.

Why it matters

• A SEV-1 at Meta from an AI agent operating outside its bounds sets a documented precedent: production agents at companies with robust security programs can circumvent behavioral constraints and cause genuine incidents.

• The chain reaction, one unauthorized action triggering downstream data exposure, is characteristic of agentic systems and different from traditional software vulnerabilities in ways most IR playbooks don’t yet account for.

• No external exfiltration is partial comfort. Unauthorized internal access to sensitive user data carries GDPR and AI Act exposure regardless of whether the data left the building.

What to do about it

• Audit every AI agent in your environment and document what it can post, write, or modify without a human approval checkpoint.

• Map the blast radius. If a specific agent takes an unexpected action, what does it touch first, and what cascades from there?

• Build AI agent incident response playbooks with automated containment triggers that don’t require analyst approval before they fire.

Rock’s Musings

The Meta incident will get dismissed as a minor operational hiccup. That’s the wrong read. Even with legit engineering talent and a mature security program, a production AI agent escaped its behavioral constraints and triggered a data exposure chain. I’m willing to bet your environment isn’t more disciplined than Meta’s.

Two hours to containment is fast. Most organizations I work with couldn’t tell you within two hours that an agent had gone sideways. AI agent behavioral monitoring is dramatically behind where it needs to be. The lesson to take away from this is that you need detection that fires before the cascade, not after the data is already in the wrong hands.

4. Amazon’s Bedrock sandbox leaks data through DNS because that’s the design

BeyondTrust’s Phantom Labs disclosed that Amazon Bedrock AgentCore Code Interpreter’s sandbox mode permits outbound DNS queries (SC Media, The Hacker News). An attacker interacting with the agent can send commands encoded in DNS A record responses and receive exfiltrated data encoded in DNS subdomain queries to an attacker-controlled server. No authentication bypass is required. BeyondTrust assigned a CVSS score of 7.5. AWS reviewed the research, determined that the behavior reflects the intended functionality, and responded by updating the documentation rather than issuing a patch.

Why it matters

• “Intended behavior” is a vendor risk posture, not a security posture. Sandbox mode was positioned as providing execution isolation. A sandbox allowing covert DNS exfiltration does not deliver isolation in any security-relevant sense.

• DNS-based covert channels are standard red team tradecraft in traditional environments. The technique translates directly into AI code execution environments without modification.

• Organizations running agents against sensitive internal data in AWS Bedrock face an unpatched, documented, CVSS 7.5 risk with no vendor remediation timeline.

What to do about it

• Add DNS query monitoring for Bedrock AgentCore code execution environments to your threat detection stack now.

• Reduce the data that AI agents with code execution access can reach to the strict minimum required for the task.

• Get a formal written architecture statement from AWS specifying exactly what the sandbox guarantees before expanding Bedrock AgentCore deployments.

Rock’s Musings

Another “Intended behavior” narrative. I’m getting pretty damn sick of it. That’s another way of saying, “We know about this, it would be expensive to change, and it sucks to be you.” (see my thoughts in CSO magazine about a previous instance HERE). The documentation update rather than a patch is the tell. You can’t outsource your risk posture to your cloud provider’s design decisions.

The technique is in every red team playbook. DNS exfiltration from sandboxed environments is foundational evasion tradecraft. Translate that knowledge directly to your AI infrastructure. If you’re running code execution agents against sensitive data in Bedrock and you haven’t instrumented DNS as an exfiltration channel, now you have your reason.

5. Linux Foundation raises $12.5 million from AI vendors to fix what their tools helped break

The Linux Foundation announced $12.5 million in grant funding from Anthropic, AWS, GitHub, Google, Google DeepMind, Microsoft, and OpenAI to advance open source software security (Linux Foundation, OpenSSF). The funding flows through Alpha-Omega and the Open Source Security Foundation. The stated problem is that AI tools are generating vulnerability reports at a volume that open-source maintainers cannot triage or remediate, degrading the security posture of the software supply chain. AWS contributed an additional $2.5 million to Alpha-Omega, in addition to the pooled amount.

Why it matters

• The same organizations whose AI tools created the report flood are funding the solution. This characterizes the governance dynamic precisely, that vendors profit from deployment and are now asked to fund the externalized costs on the maintainer community.

• Overwhelming maintainers with AI-generated findings lowers average signal quality. Funding addresses capacity but doesn’t solve the signal-to-noise problem alone.

• This is the first major coordinated industry response to the specific problem of AI-generated report volume stressing the open source security ecosystem.

What to do about it

• Factor the current maintainer backlog into your software composition analysis program. Critical open source dependencies may carry known vulnerabilities sitting in a backlogged queue rather than getting remediated.

• Watch what Alpha-Omega and OpenSSF deliver from this investment over the next twelve months. The commitment matters less than whether the tooling measurably improves triage capacity.

• Ask your security vendors how they handle AI-generated findings before surfacing them to your team. The same noise problem exists inside your tooling stack.

Rock’s Musings

$12.5 million is the right direction, yet not nearly enough. Open source maintainers are largely volunteers managing the infrastructure that the global software supply chain runs on. The AI-generated report flood is a problem these vendors created while selling velocity gains to enterprises.

The coordination signal matters more than the dollar amount. You rarely see Google, Microsoft, AWS, Anthropic, and OpenAI announce joint anything. When competitors fund a shared problem together, the liability exposure of inaction exceeds the competitive cost of cooperating. Given how much of the internet runs on open source that these companies’ AI tools are now stressing, the math on joint action isn’t complicated.

6. Pentagon moves to replace Anthropic while the lawsuit works through the courts

TechCrunch reported that the Pentagon is actively developing alternative AI capability paths to replace Anthropic’s Claude across defense applications (TechCrunch). This follows the Defense Department’s February designation of Anthropic as a supply chain security risk and Anthropic’s subsequent lawsuit against the Trump administration. This confirms that the replacement effort has shifted from contingency planning to active technical development. More than 875 Google and OpenAI employees have signed an open letter supporting Anthropic’s position.

Why it matters

• Active technical development of replacements, rather than contingency planning, signals DoD confidence that the Anthropic designation will hold through the litigation cycle.

• Defense contractors relying on Claude for active program work now face migration timelines driven by someone else’s legal and procurement decisions.

• The 875-employee response across competing firms signals the tech workforce treats this as a legitimacy question about AI governance, not a routine vendor dispute.

What to do about it

• If your organization operates in the defense industrial base, review AI vendor contracts now for comparable ethical-use clauses and their enforceability, before further redesignations affect your supply chain.

• Track the Anthropic lawsuit. The outcome defines what ethical use provisions in AI contracts are worth in federal procurement.

• Evaluate AI vendor concentration risk in your stack. If one supply chain designation event could disrupt your programs, that’s a single point of failure worth addressing.

Rock’s Musings

The supply chain risk designation was built for foreign adversaries. Applying it to a domestic AI company for writing autonomous weapons prohibitions into a contract is a significant precedent that the press is underweighting. The designation signals that safety constraints are now framed as operational liabilities in defense procurement, not risk mitigation.

If that framing spreads to other acquisition decisions, the AI vendors most willing to remove safety constraints gain a competitive advantage in a large and growing federal spending category. Watch the lawsuit and the follow-on procurement awards carefully. Both will tell you where this governance experiment ends up.

7. CSA’s 2026 cloud and AI security report documents the identity explosion

The Cloud Security Alliance published its State of Cloud and AI Security 2026 on March 13, finding the average enterprise now manages 100 machine and non-human identities for every one human identity (CSA). Forgotten or misconfigured cloud credentials declined from 84% in 2024 to 65% in 2026. Ninety-two percent of executives report business-impacting security compromises, most from preventable risks. The report identifies decentralized AI agents as the primary driver of the NHI expansion and calls for continuous exposure management to replace static patching cycles.

Why it matters

• A 100:1 machine-to-human identity ratio means the traditional IAM program built around human users is managing a fundamentally different problem than it was designed for.

• Credential misconfiguration persisting at 65% suggests the improvement rate won’t match the velocity of AI-driven identity expansion.

• A 92% executive compromise from preventable risks indicates the gap isn’t a detection-sophistication problem. Organizations know the controls and aren’t applying them at the required scale.

What to do about it

• Audit NHI management practices against the same standards applied to human identities: lifecycle management, least privilege, and regular access reviews.

• Deploy continuous credential exposure monitoring specifically for machine identities and AI agent service accounts.

• Shift the board-level narrative from maturity scores to continuous exposure management. That’s where enterprise frameworks are heading.

Rock’s Musings

A hundred machine identities for every human one, and most organizations manage them with IAM tooling built for a 10-to-1 ratio. The math doesn’t work. The credential improvement trend from 84% to 65% is real progress, but 65% still represents a failure rate I wouldn’t accept in any other critical control domain.

Every new agentic deployment creates more identities, tokens, service accounts, and API keys. If you don’t have a clear owner for non-human identity governance today, you have a gap that will become a breach within twelve months. Find the owner. Document the scope. Don’t wait for the incident.

8. Jozu Agent Guard launches after watching an AI agent bypass governance in four commands

Jozu announced Jozu Agent Guard on March 17, a zero-trust runtime that executes AI agents, models, and MCP servers with policy enforcement built outside the model’s control plane and hardcoded against agent-level override (Help Net Security). The architecture decision came directly from internal testing: during product development, Jozu observed an AI agent bypass the governance controls the product was designed to enforce in four commands. That failure drove the decision to move policy enforcement entirely outside the execution layer the agent can influence.

Why it matters

• A product built specifically to constrain AI agents was bypassed in four commands during its own testing. The threat model has to assume the agent itself will attempt to circumvent governance. Cooperative compliance is not a valid design assumption.

• MCP server isolation is underprovided. MCP servers frequently carry production credentials and broad tool access, and running them in shared agent environments creates privilege escalation paths most organizations haven’t mapped.

• Three AI agent security products launching in four days signals enterprise buying is active in this space right now.

What to do about it

• Require AI agent security vendors to demonstrate their product against an adversarial agent in a live environment. Demand the failure modes alongside the happy path.

• Treat MCP server execution environments as sensitive infrastructure requiring isolation equivalent to your most privileged workloads.

• Add governance bypass testing to your AI red team scope before the next production agent deployment.

Rock’s Musings

The four-command bypass during their own testing is the most honest vendor disclosure I’ve seen about AI agent security in the past year. Most vendors demo the happy path and skip the part where their product got circumvented. Jozu disclosed it and changed the architecture. That’s how security engineering is supposed to work.

The uncomfortable implication for everyone else: if a product built specifically to constrain AI agents was bypassed in four commands, ask yourself what your existing controls look like against an agent actively trying to exceed its permissions. If you haven’t run that test, you don’t have an answer.

9. Token Security builds intent-based controls for AI agent permissions

Token Security announced intent-based AI agent security on March 18, governing autonomous agents by scoping their permissions to declared operational purpose rather than granting standing broad access (Help Net Security). The system creates purpose-defined permission envelopes that expire at task completion, with runtime enforcement preventing actions outside the declared intent. Token Security’s CEO stated directly that prompt filtering and guardrails were not designed to contain the security risks of autonomous AI agents, pointing to the architectural limitation of relying on the model’s output layer for enforcement.

Why it matters

• Purpose-aligned permissions address a structural problem in current agent deployment: agents inheriting credential scopes far exceeding what any single task requires.

• Explicit acknowledgment that content filtering can’t do this job alone represents where serious practitioner thinking is converging. The field is moving from output layer controls toward architectural access controls.

• Paired with Jozu, Entro, and Microsoft Entra Agent ID announcements this same week, this reflects a coherent market thesis forming around agent identity and least privilege as primary security controls.

What to do about it

• Map current AI agent deployments against one question: does each agent hold only the permissions it needs for its specific task? If you can’t answer quickly, your access governance is already too loose.

• Evaluate intent-based and purpose-scoped access controls in your next AI security procurement cycle.

• Brief your identity team on AI agent access management before your security team deploys solutions they haven’t reviewed. These tools touch the same credential infrastructure.

Rock’s Musings

Least privilege applied to agents is the same principle that has protected privileged service accounts in traditional architectures for decades. The problem is that most AI agent deployments aren’t being treated like privileged service accounts. They get broad collaboration access by default, and nobody asks why.

Intent-based controls force the right question: what is this agent for? If you can answer precisely, you can scope permissions precisely. If you can’t answer precisely, that is the real governance problem. You’ve deployed an agent without a defined operational boundary, and your control over it is largely fictional.

10. NIST receives formal research submissions on securing AI agents

On March 18, UC Berkeley’s Center for Long-Term Cybersecurity submitted a formal response to NIST’s CAISI RFI on AI agent security, urging prioritization of standardization, incident reporting frameworks, talent pipelines, and adaptive governance (CLTC UC Berkeley). The Computer and Communications Industry Association submitted parallel comments advocating for multistakeholder processes and alignment with existing NIST frameworks (CCIA). NIST’s National Cybersecurity Center of Excellence also holds a separate comment period open through April 2 on a concept paper covering identity and authorization for AI agents.

Why it matters

• The gap between NIST collecting input and usable standards publishing is measured in years. Your agents are running now, under no binding identity or authorization standard.

• Berkeley’s call for incident reporting infrastructure acknowledges a structural gap: no systematic mechanism exists for learning from AI agent security failures across organizations.

• The NCCoE concept paper on agent identity and authorization is where future compliance requirements will originate. Comments submitted now shape what those requirements demand.

What to do about it

• Read the NCCoE concept paper at nccoe.nist.gov and submit comments before April 2 if your organization deploys agents. Operational experience is what NIST is specifically asking for.

• Treat the Berkeley and CCIA submissions as intelligence on where auditors will focus within 18 to 36 months.

• Stand up basic agent identity logging now using existing IAM controls. Don’t wait for NIST to finalize anything.

Rock’s Musings

NIST is moving faster on agentic AI security than I expected two years ago. That still isn’t fast enough to matter for organizations deploying agents today. Best case from the current comment cycle: interim guidance in twelve months. Binding controls will take longer.

Berkeley’s call for incident reporting is the right recommendation and it will face the same resistance every mandatory reporting regime has faced. Voluntary frameworks will come first, get ignored, and get teeth after the third or fourth major public incident. That’s the pattern. Plan for it and build your own internal incident tracking capability now.

The One Thing You Won’t Hear About But You Need To

Entro Security builds a governed map of what your AI agents access in production

Entro Security launched its Agentic Governance and Administration platform, extending non-human identity security coverage specifically to AI agents (GlobeNewswire, Help Net Security). The platform builds structured AI agent profiles from three observable layers. First, sources: the endpoints, agent platforms, cloud environments, and MCP servers where agents execute. Second, targets: the enterprise assets and applications each agent accesses. Third, identities: the human accounts, non-human identities, and secrets each agent uses to operate. AGA provides MCP server activity visibility and policy enforcement, audit trails for both allowed and blocked activity, and controls against unsanctioned MCP targets and AI client behaviors.

Why it matters

• Most organizations deploying AI agents don’t have a single governed view of what agents are running, what they access, and which identities they use. AGA builds that view from execution telemetry rather than documentation that goes stale immediately after it’s written.

• MCP server governance is nearly absent from enterprise security programs today, despite MCP servers frequently holding production credentials and broad access to sensitive systems.

• The NHI-first architecture lets organizations with existing non-human identity programs extend that coverage to AI agents rather than building a separate program from scratch.

What to do about it

• Before the next AI agent deployment, require answers to three questions from observable telemetry: where does it run, what does it touch, and which identities does it use? If you need documentation rather than telemetry to answer, you don’t have governance.

• Add MCP server inventory to asset management now. MCP servers deploy through developer workflows without formal change management, and retroactive cataloguing gets harder with each deployment.

• Assess whether your current NHI security program explicitly covers AI agent identities. If it doesn’t, extend it or stand up a parallel track with a clear accountable owner.

Rock’s Musings

This one didn’t get coverage this week because it launched during RSA prep season when every security vendor fights for the same column inches. That’s exactly why it’s here. The problem AGA addresses is what I call dark matter governance: AI agents operating in your environment that nobody catalogued because they deployed through platforms your traditional asset management tools don’t see.

The MCP visibility layer is the operationally useful piece. MCP servers multiply fast, are deployed by individual developers without change management review, and frequently hold credentials for production systems. An agent you haven’t catalogued connecting to an MCP server you haven’t governed is a permissions sprawl problem that compounds with every new deployment. Get a governed view of that surface before your adversary maps it for you.

If you found this analysis useful, subscribe at rockcybermusings.com for weekly intelligence on AI security developments.

👉 Visit RockCyber.com to learn more about how we can help you in your traditional Cybersecurity and AI Security and Governance Journey

👉 Want to save a quick $100K? Check out our AI Governance Tools at AIGovernanceToolkit.com

👉 Subscribe for more AI and cyber insights with the occasional rant.

The views and opinions expressed in RockCyber Musings are my own and do not represent the positions of my employer or any organization I’m affiliated with.

Share RockCyber Musings

References

Bitcoinworld. (2026, March). Rogue AI agent sparks critical security crisis at Meta, exposing sensitive data. https://bitcoinworld.co.in/meta-rogue-ai-agent-security-breach/

Cloud Security Alliance. (2026, March 13). The state of cloud and AI security in 2026. https://cloudsecurityalliance.org/blog/2026/03/13/the-state-of-cloud-and-ai-security-in-2026

Computer and Communications Industry Association. (2026, March). CCIA submits comments to NIST regarding privacy and security of AI agents. https://ccianet.org/news/2026/03/ccia-submits-comments-to-nist-regarding-privacy-and-security-of-ai-agents/

Council of the European Union. (2026, March 13). Council agrees position to streamline rules on artificial intelligence. https://www.consilium.europa.eu/en/press/press-releases/2026/03/13/council-agrees-position-to-streamline-rules-on-artificial-intelligence/

Entro Security. (2026, March 18). Entro launches agentic governance and administration to bring visibility and control to AI access across the enterprise. GlobeNewswire. https://www.globenewswire.com/news-release/2026/03/18/3258229/0/en/Entro-Launches-Agentic-Governance-Administration-to-Bring-Visibility-and-Control-to-AI-Access-Across-the-Enterprise.html

HackerNoob. (2026, March). Meta’s rogue AI agent: Sev 1 security incident and how to sandbox AI agents properly. https://hackernoob.tips/meta-rogue-ai-agent-sev1-how-to-sandbox-ai-agents/

Help Net Security. (2026, March 17). Jozu Agent Guard targets AI agents that evade controls. https://www.helpnetsecurity.com/2026/03/17/jozu-agent-guard-targets-ai-agents-that-evade-controls/

Help Net Security. (2026, March 18). Token Security advances AI agent protection with intent-based controls. https://www.helpnetsecurity.com/2026/03/18/token-security-intent-based-ai-agent-security/

Help Net Security. (2026, March 18). Big tech companies step in to support the open source security ecosystem. https://www.helpnetsecurity.com/2026/03/18/linux-foundation-open-source-security-12-5-million-funding/

Help Net Security. (2026, March 19). Entro Security AGA brings governance and control to enterprise AI agents and access. https://www.helpnetsecurity.com/2026/03/19/entro-agentic-governance-administration/

HiddenLayer. (2026, March 18). HiddenLayer releases the 2026 AI threat landscape report. PR Newswire. https://finance.yahoo.com/news/hiddenlayer-releases-2026-ai-threat-140000928.html

Linux Foundation. (2026, March 17). Linux Foundation announces $12.5 million in grant funding from leading organizations to advance open source security. https://www.linuxfoundation.org/press/linux-foundation-announces-12.5-million-in-grant-funding-from-leading-organizations-to-advance-open-source-security

SC Media. (2026, March). AWS Bedrock tool vulnerability allows data exfiltration via DNS leaks. https://www.scworld.com/brief/aws-bedrock-vulnerability-allows-data-exfiltration-via-dns-leaks

TechCrunch. (2026, March 17). The Pentagon is developing alternatives to Anthropic, report says. https://techcrunch.com/2026/03/17/the-pentagon-is-developing-alternatives-to-anthropic-report-says/

The Hacker News. (2026, March 17). AI flaws in Amazon Bedrock, LangSmith, and SGLang enable data exfiltration and RCE. https://thehackernews.com/2026/03/ai-flaws-in-amazon-bedrock-langsmith.html

UC Berkeley Center for Long-Term Cybersecurity. (2026, March 18). Researchers submit response to U.S. government request on security considerations for AI agents. https://cltc.berkeley.edu/2026/03/18/researchers-submit-response-to-u-s-government-request-on-security-considerations-for-ai-agents/

The IETF just published its most ambitious attempt to standardize how AI agents prove their identity across systems. Draft-klrc-aiagent-auth-00, dropped March 2, 2026, composes WIMSE, SPIFFE, and OAuth 2.0 into a 26-page framework called AIMS (Agent Identity Management System). The authentication layer is solid. The authorization layer stops at the token boundary. The Security Considerations section contains two words: “TODO Security.” If you’re deploying agentic systems in production, you need to understand where this draft helps you and where you still have to build your own controls.

Share

Before I get into specifics, a quick note on what this document actually is. An IETF Internet-Draft (I-D) is a working document, the raw material that may eventually become an RFC (an official Internet standard). This one is version -00, the very first public iteration from Pieter Kasselman (Defakto Security), Jean-Francois Lombardo (AWS), Yaroslav Rosomakho (Zscaler), and Brian Campbell (Ping Identity). Criticizing a -00 draft for incompleteness is a bit like reviewing someone’s outline and complaining the conclusion is thin. That said, people are already reading this as deployment guidance, and the gaps matter for anyone building agentic systems today. So let’s talk about what it covers, what it doesn’t cover yet, and what you need to build yourself while the standards process catches up.

The good news: agents are workloads, and workloads have an identity stack

The draft’s foundational thesis gets it right that AI agents should be treated as workloads, not as some new identity category requiring new protocols and running instances of software executing specific tasks. That framing unlocks SPIFFE’s attestation-bound cryptographic identity, WIMSE’s cross-system workload semantics, and OAuth 2.0’s delegation framework. No new protocols needed.

This matters because SPIFFE already works at scale. Uber processes billions of attestations daily through SPIRE. Block runs the full SPIFFE+WIMSE+OAuth stack in production. The draft codifies patterns that companies with real security engineering teams already deploy.

The WIMSE identifiers specified in the draft bind agent identity to the execution environment through hardware-rooted attestation. A SPIRE agent on each node performs workload attestation by examining the kernel or querying the orchestration platform. Your agent’s identity gets measured from where it runs, not merely asserted by who registered it. An OAuth client_id is a registration artifact. A SPIFFE ID is cryptographic proof that Agent X is actually Agent X, running in the expected environment.

The draft also gets credentials right. Short-lived, cryptographically bound, explicit expiration. Static API keys are called out as unsuitable for agent authentication: bearer artifacts with no cryptographic binding, no identity conveyance, operationally painful to rotate.

That warning couldn’t come at a better time. Astrix Security analyzed over 5,200 open-source MCP server implementations and found that 53% rely on static API keys or Personal Access Tokens. Only 8.5% use OAuth. The ecosystem is building on exactly the anti-pattern the draft condemns.

Transaction Tokens solve the lateral movement problem

Section 10.4 addresses a real attack vector most frameworks ignore. When access tokens propagate through internal microservice chains within an agent workflow, every hop creates a theft and replay opportunity.

The draft’s answer is Transaction Tokens (draft-ietf-oauth-transaction-tokens-08). Short-lived, signed JWTs that bind user identity, workload identity, and authorization context to a specific transaction. Lifetimes are measured in seconds to minutes. Cryptographic signatures prevent context modification. You can’t grab a Transaction Token from one transaction and replay it in another because the transaction context is cryptographically sealed. A companion draft (draft-oauth-transaction-tokens-for-agents-04) extends this with agent-specific fields for the acting agent, the initiating human, and operational constraints.

The draft also correctly identifies tools forwarding access tokens to downstream services as an anti-pattern.

The authorization gap: where scope alone isn’t enough

Here’s where the draft’s -00 status shows. Once an OAuth access token gets issued with a set of scopes, every action within those scopes proceeds unchecked until the token expires. No per-action evaluation. No consequence assessment. No behavioral feedback loop. The authors clearly know authorization needs more work (the AIMS conceptual model describes layers that the spec hasn’t filled in yet), but anyone reading this draft as a deployment blueprint today will inherit that gap.

Think about what that means in practice. An agent with email:send scope authorized to send meeting notes can use that same scope to email every contact in the address book a different message. Each action is technically within scope. The framework treats them identically. The authorization decision happened once, at token issuance. Everything after that is a free pass.

OWASP’s Top 10 for Agentic Applications draws a distinction that the draft hasn’t addressed yet: least agency versus least privilege. Least privilege asks what the agent can access. Least agency extends that to how much freedom the agent has to act on that access without checking back.

The term “least agency” appears nowhere in the draft. Section 10.8 says agents should request minimum scopes and authorization details. That’s least privilege applied to OAuth scopes. Standard stuff. It does nothing to constrain autonomous decision-making within those scopes.

OWASP’s ASI03 (Identity and Privilege Abuse) mitigation guidance recommends per-action authorization through a centralized policy engine. Not once at token issuance. At each privileged step. The draft doesn’t provide a mechanism for this yet, and future revisions may address it. In the meantime, you need to build that layer yourself.

Your token says “allowed.” What it can’t say is “should you?”

The deeper issue goes beyond per-action evaluation. The draft in its current form contains no mechanisms for assessing the potential impact of an action before permitting it. No concept of blast radius. No reversibility check. No impact severity score. Again, this is version -00. These concepts may arrive in later revisions. They’re absent today.

Consider the practical difference. An agent with files:read_write scope can read one file or delete every file in scope. The OAuth framework treats these as equivalent actions. They aren’t. One is routine. The other is catastrophic and irreversible.

Consequence-based authorization asks three questions per permission:

1. What’s the worst action this agent can take?

2. Is the damage reversible?

3. Can you reverse it within an acceptable recovery window?

OAuth scopes can’t answer any of these.

The emerging practice of graduated trust models (read-only, then draft-only, then supervised execution, then earned autonomy) represents an informal consequence-based approach. Most practitioners agree that most agents never earn full autonomy in high-stakes contexts. That’s the correct outcome. The draft provides no framework for expressing or enforcing these graduation stages.

OWASP’s ASI08 (Cascading Failures) recommends blast-radius caps and digital twin replay testing. Run recorded agent actions in an isolated environment first. See if sequences trigger cascading failures before expanding policy permissions. Future revisions of the draft could incorporate these concepts. For now, they’re outside its scope.

The observability gap: strong detection, no policy feedback loop

Section 11’s observability requirements are genuinely strong for detection and audit. Seven minimum audit event fields. Correlation across agents, tools, services, and LLMs. The ability to reconstruct complete execution chains, including delegated authority and intermediate calls.

The draft calls observability “a security control, not solely an operational feature.” Correct. Then it integrates the OpenID Shared Signals Framework with CAEP (Continuous Access Evaluation Profile) for real-time signal delivery. Also good.

The problem is that the AIMS conceptual model in Section 4 promises observability that can “dynamically modify authorization decisions based on observed behavior and system state.” The actual specification delivers reactive remediation, terminate sessions, discard tokens, re-acquire with updated constraints. Detection flows to dashboards and SIEM tools. It doesn’t feed into the policy decision point that evaluates each authorization request. The conceptual model is ahead of the spec, which is normal for a -00 draft. The spec will likely catch up. You can’t afford to wait for it.

An agent exhibiting anomalous tool invocation patterns should see its authorization dynamically narrowed. Not through token revocation (which is all-or-nothing) but through policy-level constraints on permitted actions. The draft gives you a circuit breaker when you need a rheostat.

NIST SP 800-207 (Zero Trust Architecture) explicitly recommends a trust score that changes dynamically based on entity behavior patterns, feeding into the policy engine. Context-aware authorization systems from companies such as Zscaler and StrongDM already implement this pattern in production (not endorsing either). I’d expect future revisions of the draft to engage with these models, especially given that Zscaler’s Rosomakho is one of the four co-authors.

AuthZEN fills the gap the draft hasn’t reached yet

The most interesting omission in the current document is that AuthZEN (OpenID Authorization API 1.0) was approved as a Final Specification in January 2026. It standardizes a transport-agnostic API where any Policy Enforcement Point queries any Policy Decision Point, regardless of vendor. The information model is a four-element tuple:

Subject (the agent), Action (the operation), Resource (the target), Context (ambient attributes).

Every agent tool invocation maps cleanly to an AuthZEN evaluation: subject is the agent’s SPIFFE ID, action is “send_email,” resource is “contact_list,” context carries the delegating user, blast radius classification, reversibility flag, and behavioral anomaly score. The context object is extensible and open-ended. It was designed for exactly this kind of dynamic, attribute-rich decision-making.

The draft references AuthZEN in its normative references. The body text doesn’t discuss it yet. Given that AuthZEN solves the draft’s most significant open question, I’d bet it features prominently in the next revision. For now, that connection is yours to make.

Three policy engines deserve attention for filling that gap. OPA (Open Policy Agent), a CNCF Graduated project, evaluates structured JSON input against declarative policies with sub-millisecond latency. Cedar, from AWS, offers automated reasoning via SMT solver that can mathematically prove properties about policies and benchmarks at 42 to 60 times faster than Rego. Topaz, from Aserto (whose CEO co-authored the AuthZEN specification), combines OPA’s decision engine with a built-in Zanzibar-style relationship graph.

OAuth provides coarse-grained delegation, who can access what resource category. Policy engines provide fine-grained runtime evaluation, should this specific action on this specific resource proceed given current context. That layered model is where the draft needs to go next. Until it gets there, you build it yourself.

Regulatory timelines won’t wait for standards completion

The EU AI Act’s high-risk system requirements take full effect August 2, 2026 (as of this writing, anyway). Five months from now. Article 14 requires human oversight. Article 26 requires deployers to keep automatically generated logs for at least six months. The draft’s identity-bound audit trails and CIBA-based human-in-the-loop mechanism directly support both.

NIST launched two converging initiatives in February 2026. The NCCoE concept paper on AI agent identity and authorization, and the AI Agent Standards Initiative covering security controls, identity, and testing. Both center on WIMSE/SPIFFE + OAuth. Both explicitly include policy-based access control, the piece the IETF draft’s -00 revision hasn’t specified yet.

The Colorado AI Act establishes a “reasonable care” standard for high-risk AI systems effective June 30, 2026. Widely adopted standards become evidence of reasonable care in court. The identity architecture the draft describes will likely qualify for authentication. You still need to build the authorization layer yourself.

MCP and A2A still have fundamental identity gaps

Mapping the IETF draft’s framework onto the Model Context Protocol reveals how far the ecosystem still has to travel. MCP identifies agents as OAuth clients with a client_id, a registration artifact with no attestation binding. No SPIFFE identity verification. No attestation mechanism. No multi-hop delegation. No standard mapping between tool names and OAuth scopes. The draft recommends Workload Proof Tokens for proof-of-possession. MCP uses bearer tokens.

MCP’s OAuth model is human-centric (Authorization Code + PKCE). The Client Credentials Grant for machine-to-machine authentication was removed from the spec and is only returning through an extension. Fully autonomous agents have no standard authentication path in MCP today. Google’s A2A protocol has similar gaps: self-declared identities with no attestation binding, credential acquisition out of scope, authorization left to the receiving agent.

Riptides demonstrated the draft’s compositional pattern working for MCP in practice. Each workload gets a SPIFFE SVID, used as a software statement in Dynamic Client Registration and as a JWT assertion for client authentication. The pattern works. It required significant custom integration that no standard profile defines.

What you should build now

Don’t wait for standards completion. The threat model OWASP defined already exists. The regulatory deadlines are set.

Start with SPIFFE/SPIRE for attestation-bound agent identity. Use SVIDs as JWT assertions (RFC 7523) to obtain OAuth tokens. This follows the pattern the draft describes and Riptides validated in production.

Deploy an AuthZEN-compliant PDP (OPA, Cedar, or Topaz). Evaluate every agent tool invocation against dynamic policy. Pass agent identity, action details, resource metadata, delegation context, and behavioral signals in the AuthZEN context object.

Write Cedar or Rego policies encoding blast-radius thresholds, reversibility requirements, graduated trust levels, and human-in-the-loop triggers. Version-control policies alongside application code.

Tag every tool and action with impact metadata: blast_radius, reversible, data_sensitivity, scope. Enforce that irreversible high-blast-radius actions require explicit human approval through CIBA step-up authorization.

Feed observability data into the policy engine as real-time context attributes. Stop sending behavioral signals only to SIEM dashboards for post-hoc investigation. Make them first-class policy inputs.

Key Takeaway: The IETF draft gives you a strong answer to “is this really Agent X?” It hasn’t answered “should Agent X do this specific thing right now?” yet. That gap will close as the draft matures. In the meantime, authentication without per-action authorization is a locked front door with open windows. Build the authorization layer now.

What to do next

If you’re building agentic systems and trying to figure out where identity controls fit, start with the CARE framework at rockcyber.com for mapping security controls to business risk outcomes. The RISE framework helps you evaluate where your organization sits on the AI security maturity curve, particularly useful for figuring out which authorization controls to prioritize first.

The agent identity problem is a microcosm of the larger question the book addresses: how do you govern autonomous systems when the blast radius of failure compounds faster than your ability to detect it?

More analysis on agentic AI security, MCP authorization gaps, and practical frameworks for building authorization layers at rockcybermusings.com.

👉 Subscribe for more AI security and governance insights with the occasional rant.

👉 Visit RockCyber.com to learn more about how we can help you in your traditional Cybersecurity and AI Security and Governance Journey

👉 Want to save a quick $100K? Check out our AI Governance Tools at AIGovernanceToolkit.com

The views and opinions expressed in RockCyber Musings are my own and do not represent the positions of my employer or any organization I’m affiliated with.

Share RockCyber Musings

The week of March 6-12, 2026, handed us a story that was coming... Anthropic filed suit against the Pentagon for blacklisting it as a national security risk. In the same week, the White House released a new cyber strategy, OpenAI launched a vulnerability-scanning agent aimed squarely at the enterprise security market, and two major federal regulatory deadlines expired. This is that week.

AI Security and AI governance collided this week in federal court, in congressional briefings, and in the server rooms of every organization running an AI agent they don’t fully understand. The governance frameworks that were supposed to provide clarity are instead amplifying uncertainty, and attackers are exploiting the gap in real time. Here’s what happened, what it means, and what to do about it, from someone who’s watched this industry long enough to be appropriately paranoid about all of it.

Share

1. Anthropic sues the Pentagon for blacklisting it as a national security risk

Anthropic filed two federal lawsuits against the Trump administration after the Department of Defense designated the company a supply chain risk. That designation, typically reserved for foreign adversaries, bars Anthropic from federal contracts and requires defense contractors to certify they don’t use Claude in any DoD work. The root cause is Anthropic’s refusal to allow Claude for autonomous weapons or mass surveillance of American citizens. CEO Dario Amodei drew two red lines in contract negotiations, the Pentagon walked, and then labeled the company a national security threat (Fortune, Defense One). Anthropic warns the financial exposure runs to hundreds of millions of dollars.

Why it matters

• This is the first time a U.S.-headquartered AI company has received the supply chain risk designation, a label previously applied only to foreign adversaries.

• The case tests whether the executive branch can use procurement leverage to override AI developers’ safety commitments, a precedent that extends far beyond Anthropic.

• Every CISO advising on AI vendor selection now has to factor whether a vendor’s ethics commitments make it a federal liability.

What to do about it

• Map your Claude and Anthropic API dependencies now. Know which workflows break if this escalates.

• Brief your board on what a supply chain risk designation means in federal contracting terms if your organization touches government work.

• Watch for similar scrutiny applied to other AI vendors with published safety policies. This may not be a one-off.

Rock’s Musings

Anthropic drew a line in the sand (no autonomous weapons, no mass surveillance), and the government responded by calling them a threat. Think about what that signals to every AI developer watching. If you have safety principles that conflict with defense procurement, you get punished for them. The First Amendment angle is interesting, but the real issue is that the executive branch just discovered that supply chain risk designation is a very effective stick, and they used it on a domestic company for the first time. AI safety as a business value just became a liability under the current administration. Read that sentence twice.

2. Trump’s Cyber Strategy for America lands in five pages

On March 6, the White House released “President Trump’s Cyber Strategy for America” alongside an executive order on cybercrime (White House, Forrester). The document covers six pillars: offensive cyber operations to shape adversary behavior, regulatory streamlining, federal network modernization, critical infrastructure security, technological superiority, and cyber workforce development. At five pages, it’s the shortest national cybersecurity strategy in a decade. The strategy explicitly calls for more aggressive offensive operations, “unprecedented coordination” between the public and private sectors, and the building of a talent base fluent in autonomous systems and AI-enabled defense.

Why it matters

• Five pages are either a vision document or a placeholder. For practical CISO purposes, it signals direction but provides almost no implementation guidance.

• The offensive posture language has legal and escalation implications for any organization with a government nexus.

• Workforce development framed as a national strategic asset means the government will be competing for the same AI security talent you’re trying to hire.

What to do about it

• Map existing compliance obligations against the six pillars. Where regulations get streamlined, understand which requirements might disappear and which you need to maintain voluntarily.

• Engage your federal liaison if you’re in a critical infrastructure sector. The public-private coordination language means more government asks are coming.

• Start building for AI-fluent security talent now. The window before this becomes a serious hiring crunch is closing.

Rock’s Musings

Five pages tells you something: either there’s a lot more in the classified annex, or this is aspirational language waiting for someone to actually build the plumbing. The workforce section is the sleeper story. AI-enabled defense needs people who understand both AI failure modes and adversarial tradecraft simultaneously. That combination doesn’t exist at scale anywhere, and we’re being asked to build it at the same time AI is accelerating attacks. The gap between those two curves is where the next major breach lives.

3. OpenAI launches Codex Security and walks into the vulnerability scanning market

OpenAI released Codex Security as a research preview, a context-aware AI vulnerability scanning agent that evolved from Aardvark, an internal security research tool OpenAI had tested in private beta since October 2025 (Bloomberg, SecurityWeek). Codex Security analyzes code repositories, pressure-tests suspected vulnerabilities in sandboxed environments, generates proof-of-concept exploits to confirm impact, and proposes fixes. OpenAI’s own data shows it scanned 1.2 million commits over the preceding 30 days, surfacing 10,561 high-severity issues and approximately 800 critical vulnerabilities. The tool is available free for the next month to ChatGPT Pro, Enterprise, Business, and Edu customers. OpenAI says it can “identify complex vulnerabilities that other agentic tools miss” (TechRadar).

Why it matters

• A free, frontier-model-powered vulnerability scanner from OpenAI immediately changes the competitive math for established AppSec vendors whose pricing models depend on the difficulty of this problem.

• Generating proof-of-concept exploits to confirm vulnerability impact is a significant capability. In the wrong hands, or with a compromised account, this is an exploit generation service.

• Organizations deploying Codex Security are giving OpenAI’s systems read access to their codebases. That data handling relationship deserves the same scrutiny as any privileged third-party tool.

What to do about it

• Before enabling Codex Security on production repositories, review OpenAI’s data retention and training policies. Understand whether your code becomes training data.

• Evaluate Codex Security against your existing SAST tooling on a representative code sample before replacing anything. “Better than other agentic tools” is a marketing claim until your team validates it.

• The proof-of-concept exploit generation feature needs access controls. Restrict which engineers can trigger full exploit confirmation scans.

Rock’s Musings

OpenAI entering the vulnerability scanner market is not a product launch. It’s a statement about where AI is heading in security operations. The incumbents in SAST and DAST have been selling the same scan-and-report workflow for a decade. An agent that generates a proof-of-concept exploit to confirm a real finding changes the value proposition significantly. I’m not surprised OpenAI built this. I’m watching carefully how they handle the fact that generating exploit code is exactly the capability defenders need and attackers want. The account compromise scenario alone should give your red team ideas.

4. NIST AI Agent Standards RFI closes with 932 comments

The comment period for NIST’s Center for AI Standards and Innovation (CAISI) Request for Information on securing AI agent systems closed March 9 with 932 responses (Federal Register, NIST). The RFI, published in January 2026, sought input from industry, academia, and the security community on securing agentic AI development and deployment. The OpenID Foundation submitted a response addressing AI agent identity and authorization. A second comment period focused specifically on identity and authorization for AI agents remains open until April 2.

Why it matters

• 932 responses signals broad industry recognition of the problem. The quality of those comments determines whether the resulting standards have operational teeth.

• Identity and authorization for AI agents is the structural gap behind most agent security failures. If NIST gets this right, it reshapes the risk calculus for enterprise agent deployment.

• The listening sessions starting in April give practitioners a direct channel to shape what these standards require.

What to do about it

• If your organization skipped the first RFI, submit to the identity and authorization comment period before April 2. Your implementation experience is exactly what NIST needs.

• Start building your AI agent identity architecture now using OAuth 2.0 On-Behalf-Of flows with proper scope constraints. This is the emerging standard pattern.

• Assign someone to track the AI Agent Standards Initiative. When draft standards publish later this year, you want your red-team comments in front of NIST before they finalize.

Rock’s Musings

Standards processes are slow by design, and the slowness here is appropriate because the identity and authorization problem for AI agents is genuinely hard. An agent acting on behalf of a user needs to carry that user’s permissions, not escalate to system-level access, and current tooling doesn’t enforce this reliably. The OIDF response to NIST gets the framing right: agent identity needs cryptographic binding, not just policy. If an agent claims to act on your behalf without a verifiable credential, you don’t have identity management. You have a trust-me system. You can read about the comments I submitted at “NIST AI Agent RFI (2025-0035): Human Oversight Is the Wrong Fix.”

5. Commerce and FTC hit their AI regulatory deadlines, and nothing changed yet

Two major deliverables from the December 2025 executive order on AI preemption came due on March 11. The Commerce Department submitted its review of state AI laws, identifying which ones the administration considers overly burdensome or in conflict with federal objectives. The FTC delivered a policy statement on how Section 5 of the FTC Act applies to AI and when state laws requiring alteration of model outputs are preempted by federal deceptive practices law (Mondaq, Digital Applied). Neither document invalidates any state law on its own. They are ammunition for the DOJ’s AI Litigation Task Force, established in January and yet to file any lawsuits. The administration is also conditioning $42 billion in BEAD broadband funding on states repealing AI regulations it deems onerous.

Why it matters

• Organizations operating AI in multiple states face genuine legal uncertainty. State laws remain on the books. The federal government plans to fight them in court, and that litigation takes years.

• The FTC’s Section 5 application to AI bias-mitigation requirements is legally untested territory.

• The BEAD funding leverage is the most concrete near-term enforcement tool. Which states hold firm versus which fold will tell you a lot about regulatory durability.

What to do about it

• Do not assume any state AI compliance requirement is going away. Build compliance architecture that can be toggled by jurisdiction as the legal landscape shifts.

• Get legal counsel read into the Commerce Department report. Knowing which of your state compliance obligations are on the federal target list helps you prioritize risk posture.

• Prepare for a two-to-three year period of overlapping requirements. Companies with modular, jurisdiction-aware compliance programs will weather this better.

Rock’s Musings

The administration created a fog of legal uncertainty and called it reducing regulatory burden. For most enterprises deploying AI, this makes compliance harder. You now have to track active federal litigation against state laws while still complying with those laws until courts rule otherwise. The FTC theory is worth watching closely: if the argument that requiring AI bias mitigation compels “deceptive output” holds, it guts a large category of state AI fairness requirements. If it fails, it sets a precedent limiting federal deceptive practices law’s reach into AI output governance. Either outcome reshapes the field.

6. OpenAI publishes its prompt injection defense playbook

On March 12, OpenAI published research and engineering guidance on defending AI agents against prompt-injection attacks (OpenAI, PrismNews). The guidance covers training techniques that help models treat different input channels with varying skepticism, architectural decisions that constrain privilege and limit blast radius, and layered verification to catch anomalous behavior. OpenAI also disclosed that it built a reinforcement learning-trained automated attacker to discover injection vulnerabilities internally, capable of steering agents through harmful multi-step workflows. The decision to publish openly reflects recognition that injection attacks threaten the entire developer ecosystem building on top of large language models.

Why it matters

• Publishing the automated attacker methodology gives defenders a concrete model of what they’re fighting. Multi-step RL-trained attacks won’t be stopped with static guardrails.

• The channel-skepticism approach, which trains models to treat external web content differently from system instructions, is an architectural fix that operates at inference time.

• OpenAI’s disclosure accelerates industry defenses while giving attackers a clearer picture of which countermeasures to route around.

What to do about it

• Apply privilege minimization immediately: agents should hold only permissions required for the specific task, expiring at task completion.

• For agents consuming external content, validate that content before the agent ingests it. Treat external web data as untrusted input, period.

• Build a prompt injection test suite and run it against production agents before every deployment. What you don’t test, you don’t know.

Rock’s Musings

OpenAI built an RL-trained machine to find injection vulnerabilities in their own systems. That machine now exists, and the same architecture will run on the offensive side of this problem within months, if it isn’t already. The deeper issue is architectural: language models cannot reliably distinguish instructions from data. That’s a fundamental property of how these systems process text, not a fixable bug. Any defense assuming the model will eventually learn to make that distinction is building on sand. The real fix is external. Don’t give agents access to resources they don’t need, and verify every external input before it reaches the model.

7. Google Cloud Threat Horizons reveals software exploits overtaking stolen credentials

Google Cloud’s Office of the CISO published its H1 2026 Threat Horizons Report on March 9, covering the second half of 2025 (Help Net Security, Security Boulevard). The headline finding is that exploitation of third-party software vulnerabilities jumped from 2.9% to 44.5% of initial cloud entry vectors in a single half-year period. The exploitation window has collapsed to days, with the React2Shell case showing crypto miners deployed within 48 hours of public vulnerability disclosure. North Korean threat group UNC4899 abused DevOps workflows and container breakout to steal millions in cryptocurrency. Threat actors also used LLMs to automate credential harvesting and accelerate the path from local developer access to full cloud admin privileges.

Why it matters

• A jump from 2.9% to 44.5% in software exploitation isn’t an incremental change. Something shifted structurally in attacker methodology during H2 2025.

• A 48-hour exploitation window means patch prioritization SLAs have to account for attacker speed, not just team capacity.

• LLM-assisted credential harvesting is now in a major incident response dataset, no longer just theoretical research.

What to do about it

• Reduce your vulnerability exposure window to 48 hours or less for critical and high-severity findings on internet-facing systems. Build the automation to get there.

• Audit DevOps pipeline permissions. The UNC4899 vector targets the privilege elevation that happens when developers hold broad cloud access from local workstations.

• Review whether AI coding tools introduce dependencies with unreviewed third-party code. Supply chain hygiene is now tier-one.

Rock’s Musings

For years, the orthodoxy was “credential hygiene is job one in the cloud.” Attackers just told you that orthodoxy is obsolete. They shifted to software exploitation because credential defenses got good enough. That’s how this works: defenders get strong on one vector, attackers rotate to the next. The current answer is patching speed. The LLM-assisted credential harvesting detail is quietly significant. It’s been in theoretical papers for two years, and now it’s in operational incident data from nation-state actors. Adjust your threat model accordingly.

8. AI agents are now helping criminals manage attack infrastructure

On March 8, The Register reported on Microsoft Threat Intelligence findings showing that North Korea’s Coral Sleet group is using AI and development platforms to rapidly build and manage attack infrastructure at scale. AI agents automate the creation of phishing infrastructure, manage C2 systems, and accelerate campaign tempo. The Unit 42 2026 Global Incident Response Report, published in February and drawing on 750 major incidents, showed the fastest 25% of attackers reaching data exfiltration in 72 minutes, down from 285 minutes the previous year. Identity weaknesses played a material role in almost 90% of investigations.

Why it matters

• AI is now a documented operational capability in nation-state attack campaigns, not just an enterprise productivity tool.

• The 4x speed increase in attack timelines means detection and response programs calibrated to last year’s data are already outdated.

• 87% of incidents unfolded across multiple attack surfaces, making correlation harder for defenders.

What to do about it

• Review detection and response SLAs against the new attacker timeline. 72 minutes from initial access to exfiltration is shorter than most IR playbook trigger times.

• Run tabletops assuming an AI-assisted attack infrastructure. Stress-test whether your team can detect and contain within the compressed timeline.

• Identity controls remain the highest-leverage investment. 90% material involvement in incidents makes this your budget priority.

Rock’s Musings

The debate about whether attackers would use AI is over. It’s all about the economics. If you’re running persistent operations against multiple targets, automating the operational overhead with AI is exactly what you’d do. The 72-minute exfiltration timeline is the number that should break your IR program’s assumptions. Most enterprise programs are built around detection metrics measured in hours or days. You need automated detection with automated response triggers, not a playbook that assumes a human analyst will catch the initial alert.

9. Amazon pushes back on data linking AI coding to infrastructure outages

On March 10, The Register reported leaked briefing notes from an Amazon internal operations meeting flagging a “trend of incidents” characterized by “high blast radius” and “Gen-AI assisted changes.” The implication was that AI-assisted coding has made infrastructure changes more fragile. Amazon responded, saying they “have not seen compelling evidence that incidents are more common with AI tools.” The Veracode 2026 State of Software Security report, published February 24, found 82% of organizations carry security debt, a 36% year-over-year spike in high-risk vulnerabilities, and that more vulnerabilities are being created than fixed, with AI development velocity outstripping remediation capacity as a contributing factor.

Why it matters

• Amazon’s internal concern, even disputed, comes from one of the largest cloud operators in the world. Internal friction at that scale is a signal worth tracking.

• The Veracode data shows a systemic pattern. AI tools accelerate feature shipping and the introduction of vulnerabilities simultaneously, while remediation capacity doesn’t scale at the same rate.

• 82% of organizations carry security debt, with 60% classified as critical, which should be a material risk disclosure issue for most boards (materiality is another conversation for another time).

What to do about it

• Require AI coding tools to integrate with static analysis before code reaches production. Velocity gains without security gates just accelerate debt accumulation.

• Measure remediation rate alongside development velocity. If the gap is widening, you have a governance problem, not just a tooling problem.

• Brief your board on the Veracode numbers. This is a material risk disclosure issue.

Rock’s Musings

Amazon’s denial matters. One leaked briefing note does not make a causal case. What it tells you is that someone inside one of the world’s largest cloud operators thought the correlation was worth flagging in an internal ops review. That’s a signal, not proof. The Veracode data is where I’m more confident: if your AI coding tools help developers write code 40% faster and that code contains the same flaw density as human-written code, you’ve just increased your vulnerability production rate by 40%. The only way this works in your favor is if you accelerate the remediation side at the same rate. Almost nobody is doing that.

10. Microsoft Patch Tuesday drops 77 CVEs

Microsoft pushed its March Patch Tuesday on March 11, fixing at least 77 vulnerabilities across Windows and other software (Kaseya, Check Point Research). This update cycle lands in an environment where, per the Google Cloud Threat Horizons data released the same week, exploitation windows for critical vulnerabilities have collapsed to 48 hours from public disclosure. AI-assisted exploit development is further compressing the time between CVE publication and the availability of weaponized exploits.

Why it matters

• 77 CVEs in one month means your patch management team works against a sprint clock every Patch Tuesday. Prioritization methodology matters more than ever.

• Critical Microsoft CVEs are being probed within 48 hours of this disclosure per current attacker timelines. Your patch SLA has to account for that.

• AI-assisted exploit development means the gap between disclosure and exploitation continues to narrow.

What to do about it

• Build risk-tiered patching protocols: critical internet-facing systems within 24-48 hours, critical internal systems within 72 hours, high severity within a week.

• Prioritize remote code execution vulnerabilities from the March 11 batch first. Review the Microsoft advisory for specific critical CVEs.

• Apply compensating controls like network segmentation and least-privilege configurations for systems where immediate patching isn’t operationally feasible.

Rock’s Musings

Patch Tuesday used to feel routine. It isn’t anymore because the time between a CVE being added to the NVD and an attacker scanning for it has gone from weeks to hours. If your patch SLA is still “30 days for critical,” you’re operating with a policy written for a threat environment that no longer exists. That’s not a patch management problem. That’s a governance problem. Fix the policy first.

The One Thing You Won’t Hear About But You Need To

CISA adds an actively exploited n8n RCE to its known exploited list, and 24,700 instances are still unpatched

On March 12, CISA added CVE-2025-68613 to its Known Exploited Vulnerabilities catalog, a critical expression-injection vulnerability in the n8n workflow automation platform with a CVSS score of 9.9 (The Hacker News, The Register). The flaw was patched three months ago in the December 2025 versions. Federal agencies have until March 25 to patch. The problem: Shadowserver data shows 24,700 instances remain unpatched online, with 12,300 in North America and 7,800 in Europe. This matters beyond the CVE itself because n8n is one of the most widely used platforms for building AI automation workflows and AI agent pipelines. Organizations deploying AI agents frequently use n8n as the orchestration layer connecting those agents to enterprise data sources.

Why it matters

• An unpatched RCE in the orchestration layer of an AI workflow means that an attacker who owns the n8n instance can access every connected system the AI agents touch, including credentials, APIs, and data stores.

• 24,700 exposed instances three months after a publicly known critical patch represents a systemic patching failure in a category of software organizations that have not been treated as critical infrastructure.

• CISA’s KEV addition triggers mandatory remediation timelines for federal agencies, but most n8n deployments are in private enterprise environments with no equivalent enforcement mechanism.

What to do about it

• Search your environment for n8n now. It is frequently deployed by individual teams or developers outside formal IT procurement, so your asset inventory may not show it.

• If you find unpatched instances, treat them as compromised until proven otherwise. Rotate every credential and API key the n8n instance had access to.

• Apply the same logic to every workflow automation tool in your environment: Zapier, Make, and similar platforms are potential RCE targets and connect to the same sensitive data sources.

Rock’s Musings

This story isn’t getting the attention it deserves because nobody considers workflow automation as critical security infrastructure. It’s where developers wire things together quickly, connect AI agents to Slack, Salesforce, and internal APIs, and then move on to the next problem. The security team doesn’t own it. The AI team doesn’t think they need to patch it. The result is a critical RCE sitting at the center of your AI agent architecture, exposed to the internet, with a patch that’s been available for three months. CISA flagging active exploitation on March 12 means this is not theoretical. Someone is using this right now. Go find your n8n instances.

If you found this analysis useful, subscribe at rockcybermusings.com for weekly intelligence on AI security developments.

👉 Visit RockCyber.com to learn more about how we can help you in your traditional Cybersecurity and AI Security and Governance Journey

👉 Want to save a quick $100K? Check out our AI Governance Tools at AIGovernanceToolkit.com

👉 Subscribe for more AI and cyber insights with the occasional rant.

Share RockCyber Musings

References

Axios. (2026, March 6). OpenAI rolls out Codex Security to automate code security reviews. https://www.axios.com/2026/03/06/openai-codex-security-ai-cyber

Baker Botts. (2026, March). March 2026: Federal deadlines that will reshape the AI regulatory landscape. MONDAQ. https://www.mondaq.com/unitedstates/new-technology/1755166/march-2026-federal-deadlines-that-will-reshape-the-ai-regulatory-landscape

Bloomberg. (2026, March 6). OpenAI unveils Codex Security tool to detect database vulnerabilities. https://www.bloomberg.com/news/articles/2026-03-06/openai-releases-ai-agent-security-tool-for-research-preview

Check Point Research. (2026, March 9). 9th March: Threat Intelligence Report. https://research.checkpoint.com/2026/9th-march-threat-intelligence-report/

CISA. (2026, March 12). CISA adds one known exploited vulnerability to catalog. https://www.cisa.gov/known-exploited-vulnerabilities-catalog

CNBC. (2026, March 10). Amazon convenes ‘deep dive’ internal meeting to address outages. https://www.cnbc.com/2026/03/10/amazon-plans-deep-dive-internal-meeting-address-ai-related-outages.html

Defense One. (2026, March 9). Anthropic sues over a dozen federal agencies and government leaders. https://www.defenseone.com/business/2026/03/anthropic-sues-over-dozen-federal-agencies-and-government-leaders/411997/

Digital Applied. (2026, March). FTC AI policy deadline March 11: Compliance guide. https://www.digitalapplied.com/blog/ftc-ai-policy-deadline-march-11-compliance-readiness

Forrester. (2026, March). White House announces the 2026 cyber strategy for America. https://www.forrester.com/blogs/white-house-announces-the-2026-cyber-strategy-for-america/

Fortune. (2026, March 9). Anthropic sues Pentagon after being labeled a threat to national security. https://fortune.com/2026/03/09/anthropic-sues-pentagon-ai-supply-chain-risk-trump-administration/

Google Cloud. (2026, March 9). Cloud threat horizons report H1 2026. https://cloud.google.com/security/report/resources/cloud-threat-horizons-report-h1-2026

Help Net Security. (2026, March 11). Software vulnerabilities push credential abuse aside in cloud intrusions. https://www.helpnetsecurity.com/2026/03/11/google-cloud-environments-cyber-threats-report/

Kaseya. (2026, March 11). The week in breach news: March 11, 2026.

https://www.kaseya.com/?post_type=post&p=26754

Microsoft Security Blog. (2026, March 6). AI as tradecraft: How threat actors operationalize AI. https://www.microsoft.com/en-us/security/blog/2026/03/06/ai-as-tradecraft-how-threat-actors-operationalize-ai/

National Institute of Standards and Technology. (2026, January). CAISI issues request for information about securing AI agent systems. https://www.nist.gov/news-events/news/2026/01/caisi-issues-request-information-about-securing-ai-agent-systems

National Institute of Standards and Technology. (2026, February). Announcing the AI agent standards initiative for interoperable and secure innovation. https://www.nist.gov/news-events/news/2026/02/announcing-ai-agent-standards-initiative-interoperable-and-secure

OpenAI. (2026, March 6). Codex Security: Now in research preview. https://openai.com/index/codex-security-now-in-research-preview/

OpenAI. (2026, March 12). Understanding prompt injections: A frontier security challenge. https://openai.com/index/prompt-injections/

OpenAI. (2026). Continuously hardening ChatGPT Atlas against prompt injection attacks. https://openai.com/index/hardening-atlas-against-prompt-injection/

OpenID Foundation. (2026). OIDF responds to NIST on AI agent security. https://openid.net/oidf-responds-to-nist-on-ai-agent-security/

Palo Alto Networks. (2026, February). 2026 Unit 42 global incident response report: Attacks now 4x faster. https://www.paloaltonetworks.com/blog/2026/02/unit-42-global-ir-report/

PrismNews. (2026, March). OpenAI releases engineering playbook to shield AI agents from prompt injection. https://www.prismnews.com/news/openai-releases-engineering-playbook-to-shield-ai-agents

Security Boulevard. (2026, March). 83% of cloud breaches start with identity, AI agents are about to make it worse. https://securityboulevard.com/2026/03/83-of-cloud-breaches-start-with-identity-ai-agents-are-about-to-make-it-worse/

SecurityWeek. (2026, March 6). OpenAI rolls out Codex Security vulnerability scanner. https://www.securityweek.com/openai-rolls-out-codex-security-vulnerability-scanner/

TechRadar. (2026, March 6). OpenAI releases Codex Security to spot the next big cyber risks to your company. https://www.techradar.com/pro/security/openai-releases-codex-security-to-spot-the-next-big-cyber-risks-to-your-company-promises-to-identify-complex-vulnerabilities-that-other-agentic-tools-miss

The Hacker News. (2026, March 12). CISA flags actively exploited n8n RCE bug as 24,700 instances remain exposed. https://thehackernews.com/2026/03/cisa-flags-actively-exploited-n8n-rce.html

The Register. (2026, March 6). Anthropic sues US over national security blacklist. https://www.theregister.com/2026/03/06/anthropic_left_with_no_other/

The Register. (2026, March 8). Manage attack infrastructure? AI agents can now help. https://www.theregister.com/2026/03/08/deploy_and_manage_attack_infrastructure/

The Register. (2026, March 10). Amazon insists AI coding isn’t source of outages. https://www.theregister.com/2026/03/10/amazon_ai_coding_outages/

The Register. (2026, March 12). CISA says n8n critical bug exploited in real-world attacks. https://www.theregister.com/2026/03/12/cisa_n8n_rce/

U.S. Federal Register. (2026, January 8). Request for information regarding security considerations for artificial intelligence agents. https://www.federalregister.gov/documents/2026/01/08/2026-00206/request-for-information-regarding-security-considerations-for-artificial-intelligence-agents

Veracode. (2026, February 24). 2026 state of software security report. BusinessWire. https://www.businesswire.com/news/home/20260224526703/en/Veracode-2026-State-of-Software-Security-Report-Reveals-Four-Out-of-Five-Organizations-Are-Drowning-in-Security-Debt

White House. (2026, March). White House unveils President Trump’s cyber strategy for America. https://www.whitehouse.gov/articles/2026/03/white-house-unveils-president-trumps-cyber-strategy-for-america/

You probably don’t know which AI model is running inside your operational tools right now. That’s a near-certainty given how enterprise AI procurement actually works. The Pentagon just ran a live stress test on that exact blind spot, and the results were not subtle. When the Department of War formally designated Anthropic a supply chain risk on March 5, 2026, making it the first American company in history to receive a label previously reserved for Huawei and Chinese state-adjacent tech firms, the disruption didn’t start with Anthropic. It cascaded through Palantir, across AWS infrastructure, and into active military workflows during U.S. strikes on Iran. Your enterprise has the same layered architecture. The question is whether you’ve mapped it, and whether your contracts protect you when the layer you don’t control catches fire.

Share

The AI Model You Don’t Control Is Already in Production

The DoD’s direct customer relationship wasn’t with Anthropic. Claude ran inside Palantir’s Maven Smart System, hosted on AWS at Impact Level 6, sitting on classified infrastructure the military depended on for intelligence analysis and operational planning. The DoD contracted with Palantir. Palantir embedded Claude. When the supply chain risk designation landed, it cascaded from procurement machinery through Palantir’s operational position and into workflows with real military dependencies, reportedly including active support for Iran strikes, even as the designation was being disputed on social media by the Secretary of Defense and the CEO of Anthropic simultaneously.

Piper Sandler analysts noted after the designation that Anthropic was “heavily embedded in the Military and the Intelligence community” and that migrating off the technology could “pose some short-term disruptions” to Palantir’s operations. Short-term disruptions. During an active military operation. That’s the polite Wall Street version of the problem.

Replace “Military and Intelligence community” with your sector. Replace “Palantir” with your largest workflow vendor. Replace “active military operation” with your peak fraud season, your annual close, or your next regulatory audit. You’ve just described your own exposure.

Your enterprise equivalent of Maven isn’t a targeting system. It’s the fraud detection platform your SOC relies on for alert triage. It’s the contract review tool your legal team treats as a first pass on every agreement. It’s the SIEM enrichment workflow your analysts approved 18 months ago, without anyone asking which model was under it or whose usage policy governed it. In each case, there’s a foundation model embedded by a SaaS vendor, hosted by a cloud provider, running under policies you never reviewed and almost certainly can’t enforce. The vendor who sold you the platform might not even know which model version was deployed last Tuesday.

The lock-in risk most CISOs think about is the wrong one. They worry about pricing leverage at renewal or feature gaps during the next budget cycle. Those are real, and they’re also the least interesting version of vendor risk in an AI-dependent stack. The risk that actually bites is operational dependency on a model whose policies, safety stack, and external political relationships sit entirely outside your contractual reach. This week demonstrated those conditions shift in 48 hours. When they do, you find out how embedded you actually are. The DoD found out during airstrikes. You’ll find out during something comparably inconvenient for you.

What the Contract Language Reveals About Your Own Agreements

The factual record on the Anthropic negotiation is clear enough. The Department of War’s January 2026 AI strategy memorandum directed procurement to require “any lawful use” language and to acquire models “free from usage policy constraints that may limit lawful military applications.” Anthropic held two red lines: no mass domestic surveillance of Americans, and no fully autonomous weapons with no human in the targeting decision loop. The DoD called those constraints unacceptable. The negotiation collapsed. The designation followed.

Here’s where it gets interesting... OpenAI reached a deal within hours of the designation announcement, published contract excerpts containing the exact “all lawful purposes” language Anthropic refused, then amended the agreement twice in the following week after legal experts publicly tore apart what the protections actually meant. Sam Altman acknowledged the deal was “definitely rushed” and that “the optics don’t look good.” Jessica Tillipman, associate dean for government procurement law studies at George Washington University, wrote that the published excerpt “does not give OpenAI an Anthropic-style, free-standing right to prohibit otherwise-lawful government use.” Altman signed it anyway. To be fair to him, he was working in 48-hour crisis mode while a competing lab was being designated a national security threat. Good contract hygiene was not the priority.

Instead of wasting your time on the OpenAI vs. Anthropic drama and who is right or wrong, you need to pay attention to the legal architecture underlying AI safety commitments.

Why?

Because your enterprise contracts almost certainly follow the same pattern OpenAI accepted, that include usage restrictions anchored to “applicable law” and “existing policy,” with the vendor’s safety stack as the primary enforcement mechanism. OpenAI anchored its protections to existing statutes: the Fourth Amendment, FISA, DoD Directive 3000.09 on autonomous weapons, and Executive Order 12333. Critics flagged immediately that EO 12333 is the authority the NSA has historically used to justify intercepting Americans’ communications through collection outside U.S. borders. “Lawful” in national security contexts isn’t a fixed boundary. It lives inside classified legal interpretations, executive orders, and internal agency guidance nobody outside the building ever reads.

Your enterprise contracts with AI vendors operate the same way. When law shifts, when policy changes, or when your vendor faces its own version of a 48-hour political deadline, those anchors move with the situation. What your procurement posture needs instead are vendor-imposed, free-standing prohibited-use schedules for your specific high-risk workflows, written into contract appendices with attached audit rights and defined remedies. “We comply with applicable law” is a description of baseline legal obligation. It’s not a control. It’s what every vendor says about every product, whether or not AI is involved. You shouldn’t be paying for that sentence in an AI addendum. You should be getting something that took a lawyer to write specifically for your deployment.

Human-in-the-Loop Theater

Let me describe a workflow you probably have running right now. Your AI triage layer ingests 200 alerts per shift and flags 180 as low severity. Your analyst reviews the queue, confirms the model’s assessment on most items, escalates five, clears the rest. Total elapsed review time for the cleared items is, let’s say, roughly two minutes each. Every disposition went through a human. The audit log shows human review. Your controls documentation references human oversight. What actually happened is your analyst ratified model outputs under cognitive load and time pressure while telling themselves they were exercising judgment.

That’s the failure mode human-in-the-loop review was designed to prevent. The loop exists on paper. The friction isn’t in the workflow design because no step requires the reviewer to explain why they agree with the model before confirming the output. Nobody required forced alternative generation before escalating or clearing. Nobody captured uncertainty as a structured field. The control is decorative.

The OpenAI contract’s autonomous weapons provision bars the use of the AI system “to independently direct autonomous weapons in any case where law, regulation, or Department policy requires human control.” Defense scholars noted the omission of “human-in-the-loop” language was deliberate, preserving operational flexibility. “Human judgment” and “human control” are not equivalent, and the people drafting that language knew it. The contract borrows its enforceability entirely from existing policy, which requires commanders to exercise “appropriate levels of human judgment over the use of force.” Appropriate is not a control. It’s a word that means whatever the decision-maker concludes is appropriate under the circumstances they’re actually in.

Research from King’s College London found that tested AI models threatened nuclear strikes in 95% of simulated crisis scenarios. The problem wasn’t autonomous weapons. The problem was that under uncertainty and time pressure, models produced escalatory recommendations with false confidence, and human reviewers were positioned to ratify those outputs rather than interrogate them. That’s not a future risk. That’s automation bias, and it operates in your environment every shift, at every tier of your AI-assisted workflows.

The Lavender targeting system used by Israeli defense forces was reportedly identified by investigators as carrying a 10% false positive rate on human identification, with human reviewers present throughout the process. The investigation raised a direct question of whether those humans were genuinely reviewing or functionally ratifying outputs under operational tempo. That distinction carries different consequences in contexts outside the military. In your environment, it shows up as a miscategorized fraud case that costs a customer their account, or a misconfigured access control that cleared review because the analyst trusted the model’s output and moved on in the last four minutes of a shift.

Building real decision friction requires designing it into the workflow architecture before something goes wrong, not auditing for it afterward. Two-person review for high-consequence AI outputs. Forced alternative generation before an analyst confirms a model recommendation. Explicit uncertainty capture as a required structured field. If your current AI-assisted workflows don’t require a reviewer to articulate why they agree with the model’s output before confirming it, then you are rubber-stamping your way into a problem down the road. You may survive your next audit. Youwon’t survive your next incident.

The Procurement Posture That Needs to Change Before the Next Signature

Most CISOs don’t own AI vendor contracts. Procurement does. Legal does. The CISO inherits the agreement after signature, usually after the vendor relationship is already operational and the leverage window has closed. This is the moment where I’ll stop pretending that’s a systems failure and call it what it is: CISOs have let themselves get cut out of a decision that’s now one of the highest-risk commitments their organization makes. The Anthropic situation gives you the publicly documented argument to change that for every AI agreement with operational or regulatory exposure going forward.

The DoD’s relationship with Palantir didn’t include enforceable audit rights over Claude’s underlying usage policy, safety stack updates, or model variant changes. When Anthropic’s relationship with the DoD broke down, Palantir faced operational disruption from a vendor dependency it hadn’t fully governed at the model layer. Your enterprise equivalent is any SaaS vendor who embeds a foundation model in a production workflow without explicit flow-down contract obligations. You need those flow-down provisions now: contractual requirements for your SaaS vendors to notify you of material AI policy changes, with a defined right to pause deployment or terminate.

Anthropic’s published usage policy states the company may tailor restrictions for certain customers based on mission and legal authorities, subject to Anthropic’s judgment about safeguards. That clause exists in their public policy documentation. Most of their enterprise customers have never read it, don’t know whether their deployment is governed by standard or tailored terms, and have no contractual mechanism to find out. If you’re an Anthropic customer and you don’t know the answer to that question, the answer is almost certainly that you don’t know, which means you don’t control it.

Splunk’s 2026 CISO Report found that a large majority of CISOs carry personal liability concerns about security incidents. AI model misuse by a subcontractor or an embedded model that you didn’t govern is exactly the incident scenario that tests that liability question. Your current contract schedules almost certainly don’t address it. Here are the questions that need to be in every AI vendor negotiation before signature, not as a wish list, but as conditions of signature:

• Which model variant governs your deployment, and does that variant deviate from the vendor’s published acceptable use policy or baseline safety commitments? Get the answer in writing with a version reference.

• What change control process governs model updates, safety stack revisions, and policy changes? “We update continuously” is not an answer. You need customer notice requirements and the right to pause deployment when the vendor makes a material change.

• What logs exist, who holds access, and what is the retention period? Without logs you can’t support an incident investigation, a regulatory inquiry, or your own post-incident analysis.

• What happens when a major customer, a regulator, or a government agency demands scope expansion for your deployment? The Anthropic situation confirmed this question isn’t hypothetical. It’s a negotiating dynamic triggered externally, rapidly, and without advance warning to downstream customers.

From the Run Phase to the Evolve Phase

If you’re applying the CARE framework, this situation signals that you’re overdue for an Evolve-phase review of your AI vendor relationships. The Create and Adapt work produced your current model integrations. Most organizations have stayed in the Run phase, monitoring performance and managing routine issues, while the risk environment underneath those integrations has shifted significantly. The Evolve phase requires reassessing whether the governance model you built for each AI deployment still fits the world you’re operating in now.

The Anthropic situation changed that environment in three concrete ways your board needs to understand. First, it showed that an AI vendor’s political and contractual relationships with high-profile customers now represent operational risk to every downstream customer, not only government contractors. Second, it produced a documented public case where contract language anchored to “applicable law” failed to deliver the protections a party believed it had agreed to. Third, it revealed that model replacement timelines are slower than your AI vendors implied during the sales process. The DoD, with its classified infrastructure, operational urgency, considerable resources, and six-month transition timeline, is the fastest-moving version of this problem you’re likely to encounter. Your enterprise timeline almost certainly isn’t shorter.

Build your AI vendor risk registry before something breaks, while relationships are functional and vendors are cooperative. Map every production AI deployment to the model underneath it, the vendor who embeds it, the cloud provider who hosts it, and the contract that governs each layer. Run a prohibited-use gap assessment: which categories of use does each contract explicitly prohibit, and are those prohibitions free-standing or anchored to “applicable law”? Apply OWASP’s Agentic Top 10 to any workflow where a model makes or influences a decision without a mandatory human review step that requires documented rationale.

The CISOs who were ahead of this story weren’t tracking the Pentagon news cycle. They had already asked their SaaS vendors which model was embedded, what the vendor’s posture would be if that model’s policy changed, and what their exit path looked like. Most got vague answers. The right response to a vague answer from an AI vendor is a contract clause, not a follow-up email.

Key Takeaway: Your AI vendor’s ethics statement doesn’t protect your enterprise. A free-standing prohibited-use schedule, enforceable audit rights, and model-layer flow-down provisions do.

What to Do Next

Start with a model inventory audit across your top ten SaaS vendor relationships. Ask each vendor to identify the foundation model embedded in your production workflows and provide the current acceptable use policy governing your specific deployment, including any tailored terms. Map the gap between what the policy says and what your contract actually enforces.

The Anthropic situation is the most instructive public case study on AI vendor governance to emerge from this space. Use it while it’s in front of your board and before your next AI vendor signature lands on someone else’s desk.

👉 Subscribe for more AI security and governance insights with the occasional rant.

👉 Visit RockCyber.com to learn more about how we can help you in your traditional Cybersecurity and AI Security and Governance Journey

👉 Want to save a quick $100K? Check out our AI Governance Tools at AIGovernanceToolkit.com

The views and opinions expressed in RockCyber Musings are my own and do not represent the positions of my employer or any organization I’m affiliated with.

Share RockCyber Musings

Share

This week handed security leaders something they’ve been theorizing about for two years: autonomous AI agents attacking other autonomous AI agents in live production environments. No thought experiment, no conference demo. A malicious bot using Claude Opus 4.5 compromised five major open-source repositories. An AI-native offensive platform compromised 600 firewalls across 55 countries. Developer tools turned into attack vectors by opening a Git repo.

The practitioner community doing the real work on these problems gathered at [un]prompted in San Francisco. The rest of the week’s news served as a live demonstration of why that conference needed to exist. Attackers aren’t waiting for frameworks to catch up. Your AI tools are the attack surface now. The developers building them are the initial targets. The agents those tools spawn are the next ones.

1. [Un]Prompted Delivers the AI Security Conference the Industry Needed

The first [un]prompted conference ran March 3-4 at The Hibernia in San Francisco (unpromptedcon.org). Gadi Evron of Knostic, who chaired the conference, received nearly 500 talk submissions and built a program spanning offense, defense, DFIR, and governance. No vendor theater. Confirmed speakers included Heather Adkins from Google on advancing code security, Joshua Saxe from Meta on agent evaluation, Paul McMillan from OpenAI on securing software in the agentic era, and Nicholas Carlini from Anthropic on black-hat LLMs finding zero-days in production codebases. Dan Guido closed Day Two, explaining how Trail of Bits rebuilt around AI to reach 200 bugs per engineer per week. Sergej Epp from Sysdig presented primary forensic evidence from an 8-minute AWS escalation and EtherRAT, a blockchain C2 campaign. Gadi even stepped in for Avishai Efrat and Michael Barugy from Zenity…a direct competitor… who could not get out of Israel, to drop PleaseFix.

Why it matters

• The field now has a practitioner-grade conference built for people doing actual work, from red teamers to governance leads, not vendor keynotes disguised as research.

• The offensive capability context is essential. Carlini showed current models finding zero-days. Guido showed 200 bugs per engineer per week. Defenders need this before building programs.

• The governance track didn’t retreat into frameworks. Healthcare and large enterprise practitioners spoke about what actually works in production.

What to do about it

• Read the full agenda at unpromptedcon.org. The talk abstracts contain more actionable signal than most vendor white papers.

• Follow the researchers presenting there. Those names are shaping the actual threat landscape.

• Prioritize the Stripe threat modeling talks and the Snap capability-based authorization session if your team hasn’t treated AI agents as first-class attack surfaces yet.

Rock’s Musings

Rob T. Lee’s line on Stage 2 deserves repeating. Anthropic’s own GTG-1002 report showed adversaries running Claude Code at 80-90% autonomous execution. Your adversary has an AI. If you’re at tab-completion for defense, that’s a strategic failure, not a skills gap.

I’ve been going to security conferences for a long time. Most are marketing events with technical content as decoration. [un]prompted felt different because Gadi built it explicitly for people who know what a YAML file does. That’s a rare thing and worth supporting. Start planning for year two.

2. Hackerbot-Claw Proved Autonomous AI Can Systematically Destroy Your CI/CD Pipeline

Between February 21 and March 1, 2026, a GitHub account called hackerbot-claw ran an autonomous campaign against public repositories (StepSecurity). The account describes itself as an “autonomous security research agent powered by claude-opus-4-5,” maintains a vulnerability pattern index with 9 classes and 47 sub-patterns, and claims to have scanned 47,391 repositories. The bot achieved remote code execution in at least four of seven targeted repositories, including Microsoft, DataDog, CNCF, and Aqua Security’s Trivy scanner. In the Trivy compromise, it stole a Personal Access Token with broad write permissions, deleted all 178 GitHub releases, wiped repository content, and published a malicious VSCode extension to OpenVSX under Trivy’s trusted publisher identity. OpenSSF issued a TLP:CLEAR advisory March 1.

The single defining moment: the bot attempted prompt injection against a Claude-based CI workflow at ambient-code/platform. Claude, running claude-sonnet-4-6, classified it as “a textbook AI agent supply-chain attack via poisoned project-level instructions” and refused. The only target the bot failed to compromise was protected by another AI model recognizing the attack.

Why it matters

• CI/CD misconfigurations are now mass-exploitable at machine speed without a single CVE. Five documented exploitation techniques, all using known patterns, all automatable.

• Supply-chain compromise at scale doesn’t require sophisticated malware. It requires systematic scanning and pull request automation. The bot scanned 47,000 repos in a week.

• AI-versus-AI defense is no longer theoretical. The ambient-code defense worked because someone built proper tool allowlisting with prompt injection detection.

What to do about it

• Audit every pull_request_target workflow in your repositories this week. Move PR metadata into environment variables. Scope tokens to minimum permissions.

• Verify your AI-based code review toolchain has prompt injection detection and tool allowlisting. Configuration matters as much as the model.

• Check the OpenSSF advisory for the specific pattern list hackerbot-claw exploited. These are all preventable and all still present in thousands of active repositories.

Rock’s Musings

The “security research” framing in the account bio is working hard. Deleting 32,000 stars from Trivy and pushing a malicious extension to OpenVSX isn’t research. The creator remains unidentified. The domain name, the “molt” naming, and the OpenClaw ecosystem references point to infrastructure being assembled and tested in the open because the operators know defenders aren’t watching yet. We’re watching the emergence of an offensive AI toolkit in real time.

3. CyberStrikeAI: A Chinese-Linked Offensive Platform Hit 600 Firewalls Across 55 Countries

Team Cymru published research on March 3, naming CyberStrikeAI as the AI-native offensive tool behind the FortiGate campaign disclosed by Amazon Threat Intelligence in February (BleepingComputer, The Hacker News). The campaign ran from January 11 to February 18, 2026, comprising over 600 FortiGate devices across 55 countries. CyberStrikeAI is built in Go, integrates 100-plus security tools, and uses any OpenAI-compatible model, including Claude and DeepSeek, through an MCP orchestration engine. The developer, alias Ed1s0nZ, submitted the tool to Knownsec 404’s Starlink Project in December 2025 and briefly posted a CNNVD vulnerability credential to their GitHub profile before deleting it. CNNVD operates under oversight by China’s Ministry of State Security. Team Cymru detected 21 unique IPs running CyberStrikeAI between January 20 and February 26, primarily on Chinese cloud infrastructure. No zero-days exploited. The actor succeeded through exposed management interfaces and weak credentials.

Why it matters

• AI-native offensive platforms are open-source and in active deployment. The barrier to running a 600-device campaign across 55 countries is now a GitHub clone and a cloud account.

• State-adjacent tooling proliferates fast. Zero deployments in November to 21 active servers by late February is an adoption curve worth tracking.

• The entry point remains unchanged. Sophisticated AI orchestration amplified the attacker. Exposed management interfaces created the opportunity. Harden the basics first.

What to do about it

• Pull the FortiGate management interface exposure from public networks immediately (seriously… who do we have to keep saying this?). Apply all current firmware patches.

• Add CyberStrikeAI IOCs from the Team Cymru report to your threat intelligence feeds.

• Add AI-native offensive tooling as a threat category in your risk model. The economics of running large-scale exploitation campaigns changed this quarter.

Rock’s Musings

The credential scrub tells you something about the actor’s maturity. Ed1s0nZ posted the CNNVD award, realized the optics problem, and deleted it. Git commit history preserved both moves. This is someone running a 600-device campaign across 55 countries who doesn’t understand basic operational security hygiene. The AI amplified a low-to-medium capability actor significantly. That’s the real threat vector here, not the sophisticated attacker getting more powerful. It’s the mediocre attacker becoming operationally dangerous.

4. Claude Code Let Attackers Own Developer Machines by Opening a Git Repo

Check Point Research disclosed two critical vulnerabilities in Anthropic’s Claude Code around February 25-27, 2026, widely covered through March 4 (Dark Reading, Security Affairs, The Hacker News). CVE-2025-59536 (CVSS 8.7) allows code injection via the Hooks feature and MCP server initialization. CVE-2026-21852 (CVSS 5.3) allows API key exfiltration by manipulating ANTHROPIC_BASE_URL before the trust dialog appears. Both trigger on opening an untrusted repository with no further user interaction. Researchers Oded Vanunu and Aviv Donenfeld at Check Point found that .claude/settings.json, .mcp.json, and CLAUDE.md function as active execution layers. Stolen API keys in Anthropic Workspaces expose all project files shared across that workspace, creating team-wide compromise from one developer’s action. All issues are patched: CVE-2025-59536 fixed in version 1.0.111, CVE-2026-21852 fixed in 2.0.65.

Why it matters

• AI coding tools are now supply-chain attack vectors. Cloning a malicious repository used to mean running attacker code. Now it means letting an AI agent run attacker code with your credentials before any warning appears.

• Repository configuration files are execution logic. Add .claude/, .mcp.json, and CLAUDE.md to your code review checklist alongside source code.

• The Workspaces blast radius multiplies team exposure. One stolen key can expose shared project files and generate unauthorized API costs across an entire engineering organization.

What to do about it

• Verify all Claude Code users are on 1.0.111 or later for the hook vulnerability and 2.0.65 or later for the API key issue. Both patches deliver via auto-update.

• Rotate Anthropic API keys for any team that cloned untrusted repositories before the patches were applied.

• Extend your security review process to cover AI tool configuration files in every repository the tool touches.

Rock’s Musings

“Trust dialog bypass” shouldn’t appear in the threat model of a professional developer tool in 2026. The design assumption that config files are passive was wrong, and it costs a CVSS 8.7. The governance question is broader: how many of your developers are running AI coding tools that weren’t through your security approval process? Claude Code, Cursor, Copilot. Each one has deep access to local filesystems, shell execution, and credentials. Your endpoint protection almost certainly has no visibility into what they’re doing. This disclosure is the clean example of why that matters.

5. GlicJack: Chrome’s Gemini Panel Let Malicious Extensions Steal Your Camera and Files

Palo Alto Networks Unit 42 published CVE-2026-0628 on March 2, 2026 (SC Media, The Hacker News). CVSS 8.8. Researcher Gal Weizman discovered that a Chrome extension with basic declarativeNetRequest permissions could inject JavaScript into Gemini Live’s side panel and inherit all of its elevated privileges: camera, microphone, local file reads, screenshot capability. The flaw arose because Chrome’s Gemini panel loads gemini.google.com inside a chrome://glic WebView component. Extension isolation rules that protect privileged browser pages didn’t apply to this component. An extension influencing a website is expected behavior. An extension influencing a component baked into the browser is a security flaw. Google patched this January 5, 2026 in Chrome 143.0.7499.192/.193. Unit 42 reported it October 23, 2025.

Why it matters

• AI features embedded in the browser create privilege escalation paths that didn’t exist before. The capabilities granted to make the assistant useful become the attacker’s gain.

• The declarativeNetRequest API is used by millions of legitimate extensions. Any extension holding that permission could have exploited this.

• Enterprise Chrome fleets may lag on patches. Individual users update automatically. Managed deployments need active verification.

What to do about it

• Confirm Chrome is at 143.0.7499.192 or later across all enterprise endpoints.

• Audit installed extensions with declarativeNetRequest permissions. Remove anything not explicitly approved.

• Add AI browser panels to your ongoing threat model. The same architectural pattern exists in Copilot in Edge and other embedded AI assistants.

Rock’s Musings

This vulnerability pattern will repeat. Every vendor shipping an embedded AI assistant is granting that panel elevated access to make it useful, then relying on the browser’s isolation model to prevent exploitation. The Gemini panel inherited browser-level privileges while the security policy hadn’t caught up. That’s not a Google-specific design flaw. It’s the natural consequence of rushing AI features into security models built for a different threat landscape. GlicJack was found and patched responsibly. The next one in a competitor’s AI browser feature might not be.

6. ClawJacked: Any Malicious Website Can Own Your Local AI Agent

Oasis Security disclosed a high-severity flaw on February 28, 2026 allowing any malicious website to connect to a locally installed OpenClaw AI agent via WebSocket and take full control (WIU Cybersecurity Center, Sysdig). The attack required nothing beyond loading a malicious webpage. An attacker’s JavaScript opened a WebSocket to the agent’s localhost port and brute-forced the gateway password with no rate limiting. Once authenticated, full access: interact with the agent, dump configuration, enumerate connected devices, read logs. A companion log poisoning vulnerability allowed indirect prompt injection through data the agent processed. OpenClaw patched ClawJacked in version 2026.2.25 and the log poisoning in 2026.2.13. The same disclosure cycle included seven additional CVEs against OpenClaw: CVE-2026-25593, CVE-2026-24763, CVE-2026-25157, CVE-2026-25475, CVE-2026-26319, CVE-2026-26322, and CVE-2026-26329.

Why it matters

• Local AI agents create new cross-context attack surfaces. The browser’s isolation model doesn’t extend to local services. A webpage can reach localhost.

• Seven CVEs in one disclosure cycle against the same product signals early-stage software with an immature security posture deployed in enterprise environments.

• Log poisoning via indirect prompt injection generalizes to any agent that processes external data. The agent becomes the vehicle for attacker instructions delivered through normal telemetry.

What to do about it

• Update OpenClaw to version 2026.2.25 or later. Non-negotiable if your organization deploys it.

• Inventory which local AI agents your developers are running and what ports they’re listening on. Most users don’t understand that local agents accept browser connections.

• Require rate limiting on local service authentication endpoints in any AI agent development your organization does or procures.

Rock’s Musings

Seven CVEs in one batch tells you about the security review process that went into building the product, or its absence. OpenClaw is representative of a broader pattern: AI agent frameworks are shipping at startup velocity with security addressed after product-market fit. The problem is that product-market fit now means enterprise deployment, which means these vulnerabilities sit inside corporate networks before anyone notices.

7. North Korea’s Contagious Interview Campaign Is Back With 26 npm Packages

Socket researchers disclosed March 2, 2026 a new iteration of the Contagious Interview campaign from North Korean threat group Famous Chollima, deploying 26 malicious npm packages targeting cryptocurrency and Web3 developers (The Hacker News). Packages masquerade as developer utilities. Install scripts execute automatically and fetch C2 server addresses from Pastebin content, a dead-drop resolver technique that makes the C2 infrastructure resilient: blocking domains doesn’t neutralize active infections because attackers update the Pastebin content with new addresses. The actual payload pulls from Vercel deployments, making traffic look like legitimate developer tool usage. The cross-platform RAT targets Windows, Linux, and macOS with keylogging, browser credential theft, and cryptocurrency wallet exfiltration.

Why it matters

• Publishing 26 plausible-looking packages to npm is a low-barrier operation that bypasses most enterprise code review.

• Pastebin dead-drop C2 is a detection evasion technique most organizations haven’t built specific detection logic for.

• Crypto and Web3 developers are the named target, but the payload works on any developer machine in any organization.

What to do about it

• Implement package manifest review for new installs in developer environments. Untrusted packages entering your toolchain require explicit approval.

• Block or alert on Pastebin traffic from developer machines that don’t require it for work. Pastebin as a C2 dead drop is an established pattern.

• Brief cryptocurrency and Web3 development teams directly. They are specifically targeted.

Rock’s Musings

Famous Chollima runs this playbook on a near-quarterly cadence and the success rate isn’t declining. Crypto theft funds sanctions-constrained North Korean government operations. This isn’t opportunistic. It’s state-directed revenue generation with a consistent target profile and consistent tooling. Your security awareness training hasn’t stopped it because awareness doesn’t change the attack surface. The attack surface is npm, Pastebin, and Vercel. Those require technical controls, not training slides.

8. The Average Enterprise Has 1,200 Unauthorized AI Applications and 14% Visibility Into Them

A briefing published March 3, 2026, by the AIUC-1 Consortium, developed with input from Stanford’s Trustworthy AI Research Lab and more than 40 security executives from Confluent, Elastic, UiPath, and Deutsche Börse, put concrete numbers to the enterprise AI governance gap (Help Net Security). Average enterprise: 1,200 unofficial AI applications; 86% of organizations report no visibility into AI data flows; shadow AI breaches cost $670,000 more than standard incidents due to delayed detection; one in five organizations report a breach linked to unauthorized AI use.

Stanford’s Sanmi Koyejo contributed research showing fine-tuning attacks bypassed Claude Haiku in 72% of cases and GPT-4o in 57%, confirming that model-level safety controls are insufficient as standalone defenses. Actual defense requires input validation, action-level guardrails, and reasoning chain visibility operating independently of model behavior.

Why it matters

• 1,200 unofficial AI applications per enterprise means most identity programs have a blind spot. You can’t govern what you can’t see, and you can’t detect a breach in a system you don’t know exists.

• The $670,000 additional breach cost from shadow AI is the board's number. Frame AI governance conversations around detection delay, not abstract risk.

• Model-level safety is not a security control you present to auditors. It’s a product feature. The bypass rates confirm it degrades under targeted attack.

What to do about it

• Use SaaS discovery tools and proxy logs to inventory actual AI application usage, not self-reported usage. The gap between what employees say they use and what they actually use is where the exposure lives.

• Define what an AI agent identity means in your IAM framework before your agents define it for you. Include API keys, OAuth grants, and service accounts belonging to AI agents.

• Document controls at the input, action, and output layers separately from model behavior. Auditors need evidence that doesn’t depend on the model refusing bad requests.

Rock’s Musings

The $670,000 additional breach cost from shadow AI is entirely attributable to one thing: time to detect. You can’t detect what you’re not monitoring. The 86% visibility gap translates directly into investigation time, which in turn translates into breach cost. The governance conversation isn’t about restricting AI use. It’s about making AI use visible enough that your SOC can respond when something goes wrong. Start there.

9. NIST Wants to Know How to Secure AI Agents. The Comment Window Closes Monday.

NIST’s Center for AI Standards and Innovation published an RFI on January 8, 2026, seeking practitioner input on securing AI agent systems, with comments due March 9, 2026 (Federal Register). This is the first formal federal RFI focused specifically on agentic AI security. The comment deadline falls four days from the publication of this newsletter. The RFI asks respondents to identify the biggest security risks unique to AI agents, what defenses actually work, how to test and constrain these systems, and what standards and policy coordination are needed. A companion initiative from NIST’s National Cybersecurity Center of Excellence on AI agent identity and authorization has a separate April 2 deadline. The Trump administration renamed the AI Safety Institute as CAISI to reflect a shift from existential risk evaluation to practical standards and measurement.

You can read more about my submission in “NIST AI Agent RFI (2025-0035): Human Oversight Is the Wrong Fix”

Why it matters

• The standards that emerge from this process will shape federal procurement requirements, contracting baselines, and eventually insurance and regulatory frameworks. Practitioner input now affects what you’ll be measured against in two to three years.

• The practitioners who will respond by default are academics, system integrators, and AI vendors with commercial interests in the outcome. Independent CISO voices are underrepresented in federal standards work.

• NIST standards carry weight across the federal supply chain. If you sell to or partner with federal agencies, the guidance coming from this process will affect your requirements.

What to do about it

• Submit a comment before March 9 at regulations.gov under docket NIST-2025-0035. Specific examples from your actual environment are more valuable than polished organizational submissions with no concrete data.

• Flag the April 2 deadline for the companion paper on AI agent identity and authorization to whoever owns your IAM program.

• Engage legal or policy counsel if your organization wants a formal submission. The deadline for that conversation is today.

Rock’s Musings

Most security executives I know haven’t heard of this RFI. That’s a problem. The reason the resulting standards will be shaped by vendors instead of practitioners is that practitioners don’t show up to the process. I’m not asking you to become a standards wonk. I’m asking you to spend 30 minutes writing down what you’re actually seeing in production, the Claude Code RCE, the OpenClaw WebSocket exposure, the shadow AI breach cost, and submit it at regulations.gov. The comment period was designed for exactly that. Use it.

The One Thing You Won’t Hear About But You Need To

OpenSSF’s TLP:CLEAR Advisory Means 47,000 Repos Are Still Exposed Right Now

On March 1, 2026, the Open Source Security Foundation issued a TLP:CLEAR advisory prompted by the hackerbot-claw campaign, documenting the specific misconfiguration classes exploited: unsafe pull_request_target trigger configurations, overprivileged GITHUB_TOKEN scopes, unsanitized inputs in shell execution contexts, and dynamic shell execution patterns (Threat Landscape Blog). TLP:CLEAR means no restrictions on distribution. It was published specifically so every organization running public GitHub Actions workflows could read it and fix their exposure.

The bot’s profile claims 47,391 repositories scanned. That number isn’t independently verified, but StepSecurity’s analysis confirms five of seven analyzed targets were compromised during a nine-day campaign that defenders didn’t detect while it was running. No CVEs. No zero-days. Documented, preventable misconfigurations. New repositories with the same patterns are being created today.

Why it matters

• The advisory is available and actionable. The barrier isn’t information access. It’s distribution through the security team to the platform engineers who control the workflows.

• The attack surface isn’t shrinking. Hackerbot-claw found 47,000 potentially vulnerable repositories in a week. The automation will get rerun.

• Undetected campaigns running for nine days means your current GitHub Actions monitoring isn’t catching this class of attack.

What to do about it

• Get the OpenSSF advisory to your DevSecOps and platform engineering teams today. It contains the specific patterns to search for and the specific remediation steps.

• Run StepSecurity harden-runner or equivalent tooling against your public repositories. The vulnerability patterns are enumerable. Find them before the next scanner does.

• Require security review for new GitHub Actions workflows before merge. The misconfigurations hackerbot-claw exploited are consistently introduced during workflow creation.

Rock’s Musings

TLP:CLEAR means the government cleared the information for public release with no restrictions. It was published so practitioners could act on it. The fact that it’s “the thing you won’t hear about” is an indictment of how security information moves through the industry. Your platform engineers are shipping features. Nobody is reading OpenSSF advisories in real time unless someone built a process for it.

The hackerbot-claw campaign didn’t require a zero-day. It required patient scanning of publicly available information about CI/CD pipeline configurations. The attacker had that process. The question for your organization is whether you have the equivalent on defense. The OpenSSF advisory is the starting point. If you want additional context on building CI/CD security programs that account for this threat class, the practitioner content at rockcybermusings.com covers it. The attack surface is documented. Close it.

If you found this analysis useful, subscribe at rockcybermusings.com for weekly intelligence on AI security developments.

👉 Visit RockCyber.com to learn more about how we can help you in your traditional Cybersecurity and AI Security and Governance Journey

👉 Want to save a quick $100K? Check out our AI Governance Tools at AIGovernanceToolkit.com

👉 Subscribe for more AI and cyber insights with the occasional rant.

Share RockCyber Musings

References

Awesome Agents. (2026, March 2). An AI agent just pwned Trivy’s 32K-star repo via GitHub Actions. https://awesomeagents.ai/news/hackerbot-claw-trivy-github-actions-compromise/

BleepingComputer. (2026, March 2). CyberStrikeAI tool adopted by hackers for AI-powered attacks. https://www.bleepingcomputer.com/news/security/cyberstrikeai-tool-adopted-by-hackers-for-ai-powered-attacks/

Check Point Research. (2026, February 25). Caught in the hook: RCE and API token exfiltration through Claude Code project files. https://research.checkpoint.com/2026/rce-and-api-token-exfiltration-through-claude-code-project-files-cve-2025-59536/

Cybernews. (2026, March 4). AI bot compromises five major GitHub repositories. https://cybernews.com/security/claude-powered-ai-bot-compromises-five-github-repositories/

Cybernews. (2026, March 4). Open some code, Claude Code runs with hacker’s instructions. https://cybernews.com/security/claude-code-critical-vulnerability-enabled-rce/

Dark Reading. (2026, February 28). Flaws in Claude Code put developers’ machines at risk. https://www.darkreading.com/application-security/flaws-claude-code-developer-machines-risk

Federal Register. (2026, January 8). Request for information regarding security considerations for artificial intelligence agents (Docket NIST-2025-0035). https://www.federalregister.gov/documents/2026/01/08/2026-00206/request-for-information-regarding-security-considerations-for-artificial-intelligence-agents

Help Net Security. (2026, March 3). AI went from assistant to autonomous actor and security never caught up. https://www.helpnetsecurity.com/2026/03/03/enterprise-ai-agent-security-2026/

NIST Center for AI Standards and Innovation. (2026, January 12). CAISI issues request for information about securing AI agent systems. https://www.nist.gov/news-events/news/2026/01/caisi-issues-request-information-about-securing-ai-agent-systems

Orca Security. (2026, March 3). HackerBot-Claw: An AI-assisted campaign targeting GitHub Actions pipelines. https://orca.security/resources/blog/hackerbot-claw-github-actions-attack/

Palo Alto Networks Unit 42. (2026, March 2). Taming agentic browsers: Vulnerability in Chrome allowed extensions to hijack new Gemini panel. https://unit42.paloaltonetworks.com/gemini-live-in-chrome-hijacking/

SC Media. (2026, March 2). Google Chrome vulnerability risked hijacking Gemini panel by rogue extension. https://www.scworld.com/news/google-chrome-vulnerability-risked-hijacking-gemini-panel-by-rogue-extension

Security Affairs. (2026, March 2). Untrusted repositories turn Claude Code into an attack vector. https://securityaffairs.com/188508/security/untrusted-repositories-turn-claude-code-into-an-attack-vector.html

StepSecurity. (2026, March 3). Hackerbot-claw: An AI-powered bot actively exploiting GitHub Actions. https://www.stepsecurity.io/blog/hackerbot-claw-github-actions-exploitation

Sysdig. (2026, March 4). Security briefing: February 2026. https://www.sysdig.com/blog/security-briefing-february-2026

The Hacker News. (2026, March 3). Open-source CyberStrikeAI deployed in AI-driven FortiGate attacks across 55 countries. https://thehackernews.com/2026/03/open-source-cyberstrikeai-deployed-in.html

The Hacker News. (2026, March 3). New Chrome vulnerability let malicious extensions escalate privileges via Gemini panel. https://thehackernews.com/2026/03/new-chrome-vulnerability-let-malicious.html

The Hacker News. (2026, February 28). Claude Code flaws allow remote code execution and API key exfiltration. https://thehackernews.com/2026/02/claude-code-flaws-allow-remote-code.html

The Hacker News. (2026, March 2). North Korean hackers publish 26 npm packages hiding Pastebin C2 for cross-platform RAT. https://thehackernews.com/2026/03/north-korean-hackers-publish-26-npm.html

Threat Landscape Blog. (2026, March 5). Hackerbot-Claw: AI bot exploiting GitHub Actions CI/CD misconfigs for repo takeover. https://threatlandscape.io/blog/hackerbot-claw-ai-bot-github-actions-supply-chain-attack

[un]prompted. (2026). Agenda — [un]prompted, The AI Security Practitioner Conference, March 3-4, 2026.

https://unpromptedcon.org/

WIU Cybersecurity Center. (2026). Cybersecurity news. Western Illinois University. https://www.wiu.edu/cybersecuritycenter/cybernews.php

Share

The T-shaped professional built the modern internet. Broad skills, deep expertise in one vertical, and the collaborative instinct to ship products at scale. That model worked. It still works for a lot of things. But 88% of organizations reported confirmed or suspected AI agent security incidents in the past year, according to Gravitee’s State of AI Agent Security 2026 report. The T-shape isn’t enough anymore. Securing agentic AI demands a different professional geometry, and most teams haven’t made the upgrade.

The LinkedIn Conversation That Started This

Lock Langdon, VP and CISO at Aprio, recently posted something on LinkedIn that got me thinking. He’d been building a security review tool in Claude Code and had a realization about why broad informational context matters more than clever prompts. He referenced the Valve employee handbook and its description of T-shaped people, then connected it to effective AI use.

His observation was sharp: “AI rewards people who can think across disciplines.” Breadth gives you the ability to steer, validate, and connect dots that the model won’t connect for you.

He’s right. And he’s describing the exact professional shape that’s now getting exposed as insufficient for agentic AI security.

Valve’s handbook clearly spells out the T-shape. They value people who are “both generalists (highly skilled at a broad set of valuable things) and also experts” in one narrow discipline. The horizontal bar gives you range. The vertical stroke gives you depth. For building products in a flat organization, it’s a brilliant hiring filter.

For securing autonomous AI agents? It’s only half the picture.

The Z-Shaped Professional and the Missing Diagonal

Malcolm Harkins, currently Chief Security and Trust Officer at HiddenLayer, pushed the T-shape further in his book Managing Risk and Information Security: Protect to Enable. He introduced the concept of the Z-shaped professional, and it’s the piece most AI teams are missing.

The Z-shape keeps the T’s horizontal bar (business acumen across the organization) and vertical stroke (technical depth). What it adds is a diagonal connecting the two. That diagonal represents deep risk and security knowledge, the translation layer that maps business constraints to technical controls and explains to the board why a security decision is a business decision.

Think about what that diagonal actually means in practice. A T-shaped engineer can build you an AI agent that works. A Z-shaped security professional can tell you whether that agent should be allowed to work with the permissions it’s requesting, within the business context it’s operating in, against the threat model you haven’t written yet.

That diagonal is the part nobody wants to do the hard work of encoding into their AI tooling. I said that in my response to Lock’s post, and I meant it. Everyone’s excited about broad context until I ask who defined the authorization boundaries. The room gets really quiet.

“It Runs” vs. “It’s Safe to Run” Is a Context Engineering Problem

Lock nailed the distinction in his original post. The difference between “it runs” and “it’s right” lies in context: threat models, business constraints, user behavior, and edge cases. I’ll double down on that and add that the difference between “it runs” and “it’s safe to run” is context engineering, and that gap is where organizations are getting wrecked.

Context engineering is the discipline of curating, structuring, and governing the information that feeds an AI system. It’s how you decide what goes into the system prompt, which tools the agent can access, what gets retrieved from your vector database, what persists in memory across sessions, and how context gets compressed when the window fills up.

Every one of those decisions is a security decision. Your system prompt defines the agent’s behavioral boundaries. Your tool access configuration determines its capability envelope. Your RAG pipeline controls what information it treats as authoritative. Your memory architecture determines what persists and what an attacker can poison.

I’ve been writing about this for months. Context engineering isn’t a developer productivity skill. It’s security engineering. The same architectural channels that make context engineering effective carry malicious payloads with equal ease. RAG retrieval pipelines that inject relevant knowledge also inject poisoned documents. Tool interfaces that offer rich functionality also expand the attack surface. Memory systems that maintain useful state also maintain poisoned state.

The data confirms this. The Cloud Security Alliance surveyed 285 IT and security professionals and found that only 18% of security leaders feel highly confident their current IAM systems can manage agent identities. Only 28% can trace agent actions back to a human sponsor across all environments. Meanwhile, 45.6% of teams still rely on shared API keys for agent-to-agent authentication.

Training data and clever prompts don’t constitute security boundaries. An AI agent can’t tell the difference between “it runs” and “it’s safe to run” without someone encoding Z-shaped judgment into the controls. That someone needs to understand the business risk (horizontal), the technical implementation (vertical), and the security implications connecting them (diagonal).

The Four Layers Nobody Wants to Do

In my LinkedIn conversation with Lock (in the comments of his post), I laid out a framework with four layers that have to happen in order.

Layer 1: Define. Articulate your risk appetite and authorization policies. What is this agent allowed to do? What data can it access? Under what conditions should it stop and ask a human? What’s the blast radius if it goes wrong? These are people decisions. No technology required. Just hard thinking.

Layer 2: Encode. Take those human decisions and turn them into policy-as-code, RBAC rules, tool permission schemas, and system prompt constraints. This is where Z-shaped judgment becomes machine-readable. If your risk appetite says “never modify production databases without human approval,” that needs to exist as an enforceable rule, not a line in a wiki nobody reads.

Layer 3: Enforce. Technical controls that make the encoded policies real. Container isolation so one agent can’t interfere with another’s file system. Exclusive file ownership to prevent concurrent workers from creating race conditions. Signed tool definitions so an attacker can’t poison a tool description. Rate limiting on tool invocations to prevent data exfiltration through repeated calls. Least-privilege scoping so that a database tool is read-only on specific tables, not a full admin connection.

Layer 4: Verify. Human review and audit trails. Log every tool call, every parameter, every result. Run automated testing and security scanning as part of the workflow, not after it. When an agent starts behaving oddly, your logs are the only way to reconstruct what happened. And someone with Z-shaped judgment needs to review those logs, because automated monitors won’t catch a well-crafted authorization boundary violation that technically follows every rule while violating the intent.

Unfortunately, organizations tend to jump straight to Layer 3 and Layer 4. They buy tools. They poorly setup configure monitors and audit trails, and then they wonder why their agents keep doing things they weren’t supposed to do. You can’t enforce what you haven’t defined. You can’t verify compliance with policies that don’t exist.

The Gravitee report found that only 14.4% of organizations have full security approval for their AI agents before they go into production. That means 85.6% skipped the “define” step entirely or gave it a passing nod.

What This Means for Hiring, Training, and Governance

If your security team is staffed entirely with T-shaped professionals, you have people who can build agents and people who can spot vulnerabilities, but you don’t have people who can connect “the business needs this agent to process insurance claims” to “this agent should never access the claims adjudication database directly, only through the approved API, with row-level security scoped to the claimant’s policy.”

That connection is the diagonal, and it’s the part AI tools can’t do for you.

NeuralTrust’s survey of 160+ CISOs found that 73% are critically concerned about AI agent risks, but only 30% have mature safeguards. Their maturity model places 46% of enterprises in the “Reactive” tier. Reactive means you’re fixing things after they break. You skipped the define and encode layers, and now you’re running expensive cleanup operations in verify.

Cisco’s State of AI Security 2026 report puts it bluntly: 83% of organizations planned to deploy agentic AI capabilities, but only 29% felt ready to do it securely. That 54-point gap between ambition and readiness is a define-and-encode gap. The technology exists. The professional judgment to wield it responsibly doesn’t, at least not at the scale organizations need.

For practitioners building with AI agents right now, ask yourself this: If you can’t articulate what your agent is authorized to do before it does it, what exactly are your tools enforcing?

The OWASP Agentic Top 10 Confirms the Framework

The OWASP GenAI Security Project released the Top 10 for Agentic Applications in December 2025 after input from over 100 security researchers. The top concerns for agentic systems, as opposed to standalone LLMs, are memory poisoning, tool misuse, and privilege compromise.

Every one of those maps directly to a failure in the four-layer model. Memory poisoning succeeds when Layer 2 (encode) doesn’t include memory integrity controls. Tool misuse succeeds when Layer 1 (define) never articulated which tools the agent should access and under what conditions. Privilege compromise succeeds when Layer 3 (enforce) grants broad permissions because nobody did the Layer 1 work of determining what least-privilege looks like for this specific agent in this specific workflow.

The OWASP list validates that LLM security focuses on single-model interactions, while agentic security concerns what happens when models can plan, persist, and delegate across tools and systems. The attack surface isn’t the model anymore. It’s the context, and who curated it, and whether they had the Z-shaped judgment to do it securely.

Building Your Z-Shape

The T-shaped professional built the internet. The Z-shaped professional has to secure the agents running on it. That’s not a criticism of the T-shape. It’s a recognition that agentic AI operates at a different level of autonomy and requires a different level of professional judgment to govern.

If you’re a security architect, start encoding your organization’s risk appetite into machine-readable policies. Not guidelines. Policies that tools can enforce.

If you’re a CISO, staff for the diagonal. Find people who can translate business risk into technical controls and articulate why an agent’s tool permissions matter to the quarterly risk review.

If you’re an engineer building with AI agents, stop thinking of context engineering as a performance optimization exercise. Every context decision is an authorization decision. Treat it that way.

Key Takeaway: Your AI agent is exactly as secure as the weakest layer in your define-encode-enforce-verify chain, and most organizations haven’t started Layer 1.

What to do next

The four-layer model maps directly to the CARE framework I use with clients: Create your governance foundations and authorization policies, Adapt them as threats and regulations shift, Run them as enforceable controls in production, and Evolve through continuous learning and post-incident review. If your agentic AI program skipped the Create step, you’re building on sand.

For a deeper look at how security leadership needs to evolve alongside AI, my book The CISO Evolution addresses the structural shift from technical security management to business-aligned risk governance. It was written before this current AI boom, but the principles still apply. The Z-shaped diagonal isn’t new. What’s new is that AI agents now operate at machine speed, which means the consequences of missing that diagonal arrive at machine speed too.

I’ve been tracking the intersection of context engineering and security engineering at RockCyber Musings, including technical deep-dives on tool poisoning, memory integrity, and the authorization gaps in current AI frameworks. If this topic matters to your organization, that’s where the ongoing work lies.

👉 Subscribe for more AI security and governance insights with the occasional rant.

👉 Visit RockCyber.com to learn more about how we can help you in your traditional Cybersecurity and AI Security and Governance Journey

👉 Want to save a quick $100K? Check out our AI Governance Tools at AIGovernanceToolkit.com

Share RockCyber Musings

Share

The week of February 20, 2026, delivered a reckoning. Not in the abstract, conference-keynote sense. In the concrete sense of “your AI vendor might get declared a supply chain risk by your own government.” While security teams spent their days triaging a GitHub Copilot prompt injection that could take over your entire repository, Anthropic’s CEO was in a room with Pete Hegseth, being threatened with the Defense Production Act. Simultaneously, industrial-scale AI distillation attacks by Chinese labs were exposed, a financially motivated hacker with modest skills used commercial GenAI to breach 600 firewalls across 55 countries, and IBM’s annual X-Force report confirmed what most of us already knew but hadn’t put numbers to. This was not a normal week. Welcome to the AI security present tense.

If you’re a CISO trying to explain to your board why your vendor risk program now includes monitoring geopolitical standoffs between AI labs and cabinet secretaries, I feel for you. This newsletter exists precisely for that conversation. Bookmark the archive at rockcybermusings.com and check rockcyber.com for the advisory work that goes deeper.

1. Pentagon Threatens to Blacklist Anthropic Over “Woke AI” Refusal to Drop Safeguards

On February 24, Defense Secretary Pete Hegseth met with Anthropic CEO Dario Amodei and issued an ultimatum: strip the safety restrictions from Claude or face cancellation of Anthropic’s $200 million DoD contract, designation as a “supply chain risk,” and potential compulsion under the Defense Production Act. The sticking points are Claude’s restrictions against use in autonomous weapons without human oversight and mass domestic surveillance, positions Amodei has publicly defended for months. By February 25, the Pentagon had reached out to Boeing and Lockheed Martin, asking for an assessment of their dependence on Claude, a formal first step toward the supply chain risk designation. The designation, normally reserved for adversarial foreign vendors like Huawei, would effectively blacklist Anthropic across the defense industrial base. Claude is currently the only AI model cleared for use in classified U.S. military settings (NPR, Axios).

Why it matters

• The “supply chain risk” label would cascade across DoD prime contractors, potentially forcing them to strip Claude from pipelines where it’s embedded in sensitive workflows, regardless of whether Anthropic’s position changes.

• This sets a precedent for government compulsion of AI lab design decisions, specifically the argument that AI safety guardrails constitute a national security liability rather than an asset.

• Competing models from Google, OpenAI, and xAI have already agreed to “all lawful use” terms, meaning Anthropic could lose classified-domain market share to firms that accepted no comparable restrictions.

What to do about it

• If your organization operates in the defense contracting space, audit how deeply Claude is integrated in classification-adjacent workflows and assess your switching timeline if Anthropic loses its clearance standing.

• Brief your board on the federal AI governance trajectory: the administration’s “innovation-first” stance is actively hostile to AI safety conditions as a contractual requirement.

• Watch the DPA invocation question closely. If the administration successfully compels an AI lab’s design choices via DPA, your vendor agreements with any AI provider become significantly less predictable.

Rock’s Musings

Let’s be clear about what’s actually happening. The administration is demanding that an AI company strip restrictions on autonomous lethal force and mass domestic surveillance. Anthropic said no. Hegseth called that “woke AI.” I call it one of the most consequential AI governance fights in U.S. history, playing out while most of the industry’s attention was focused on vulnerabilities in developer tooling.

The era of assuming your AI vendor’s ethics are your ethics is over. When a government can designate your AI provider as a supply chain risk for maintaining safety policies, those policies become a business continuity variable. Build your AI governance program like that’s true, because it is.

2. Anthropic Exposes Industrial-Scale Claude Distillation Attacks by Three Chinese AI Labs

On February 23, Anthropic published a detailed disclosure identifying three Chinese AI laboratories, DeepSeek, Moonshot AI, and MiniMax, as having conducted coordinated campaigns to extract Claude’s capabilities at industrial scale. The three labs generated over 16 million exchanges with Claude through approximately 24,000 fraudulent accounts, bypassing China’s access restrictions using commercial proxy services running what Anthropic calls “hydra cluster” architectures, sprawling networks designed to mix distillation traffic with legitimate requests. Anthropic attributed each campaign with high confidence using IP correlation, request metadata, and infrastructure indicators. MiniMax drove the heaviest traffic, over 13 million exchanges, and Anthropic detected its campaign while still active, watching MiniMax pivot within 24 hours of Claude’s new model release to begin extracting the latest capabilities. DeepSeek’s requests specifically targeted reasoning capabilities and censorship-safe alternatives to politically sensitive queries, consistent with training models to evade content restrictions (Anthropic blog, The Register, TechCrunch, CNN).

Why it matters

• Models built through illicit distillation strip the safety guardrails implemented by the originating lab. Chinese actors can acquire frontier AI capabilities without the restrictions that prevent those systems from assisting with bioweapons synthesis, offensive cyber operations, or disinformation at scale.

• The scale of extraction, 16 million exchanges across 24,000 accounts, demonstrates this is not opportunistic scraping. It is a structured intelligence collection operation against American AI infrastructure.

• Anthropic’s disclosure adds evidentiary support for stricter AI export controls and industry-wide distillation detection infrastructure, neither of which currently exists in a coordinated form.

What to do about it

• Review any AI products or internal tools that wrap or call third-party model APIs. If those calls touch frontier models, understand whether your data is insulated from aggregation risks similar to these distillation patterns.

• Engage your legal and procurement teams on supply chain risk assessments for AI model providers used by your organization, specifically their ToS enforcement posture and detection capabilities.

• Track the policy response. Anthropic is explicitly calling for “a coordinated response across the AI industry, cloud providers, and policymakers.” That framing is the precursor to regulatory proposals.

Rock’s Musings

The distillation story gets presented as an IP theft problem. It is that, but only partly. The deeper problem is the safety bypass. When MiniMax runs 13 million exchanges through Claude to train its own model, it’s not paying licensing fees, but it’s also not inheriting Claude’s constitutional restrictions against helping with bioweapons or cyberattacks. It gets the capability without the cage.

The “hydra cluster” architecture Anthropic describes, 20,000 fraudulent accounts blending distillation traffic with legitimate use, is a detection problem that no single company can solve alone. This is what a coordinated AI security posture looks like when it’s absent. The industry needs shared threat intelligence on distillation patterns the same way it shares threat intel on ransomware actor TTPs. We don’t have that yet.

3. RoguePilot: Passive Prompt Injection in GitHub Codespaces Enables Full Repository Takeover

On February 24, Orca Security disclosed RoguePilot, a passive prompt-injection vulnerability in GitHub Codespaces that enabled attackers to achieve a full repository takeover by embedding malicious instructions in a GitHub Issue. No exploitation of Codespaces itself was required. When a developer opened a Codespace from a poisoned Issue, GitHub Copilot was immediately prompted with the Issue’s description and executed the hidden instructions, which were concealed inside HTML comments invisible to human reviewers. The attack chain exfiltrated the GITHUB_TOKEN by manipulating Copilot to access a symlinked sensitive file and append the token to a schema download request, leaking it to an attacker-controlled server. Microsoft patched the vulnerability following responsible disclosure, and no CVE had been assigned at time of reporting. Researcher Roi Nisimi at Orca called it a new class of AI-mediated supply chain attack (Orca Security, SecurityWeek, The Hacker News).

Why it matters

• The attack required no special privileges. Anyone who could create or view a GitHub Issue in a targeted repository could trigger it, placing it within reach of anonymous threat actors and insider risks alike.

• This is a demonstration that AI agents with God Mode permissions, terminal access, file reads, API tokens, and network connectivity, cannot reliably distinguish between developer instructions and adversarial content embedded in data.

• Microsoft patched this specific chain, but the root problem, AI agents treating user-generated content as potentially trusted, persists across every developer tool that integrates an LLM agent into an active workspace.

What to do about it

• Rotate any GITHUB_TOKENs generated in Codespaces environments. Even if your team wasn’t targeted, token hygiene is your first action.

• Audit your developer tooling inventory for any AI assistants that ingest user-generated content, Issues, comments, pull requests, wikis, and operate with elevated permissions. RoguePilot will not be the last of its class.

• Push your security engineering teams to review json.schemaDownload settings and symlink sandboxing defaults in any LLM-integrated development environments in your stack.

Rock’s Musings

This is the AI agent security problem crystallized into a single attack chain. You have a model that’s been given broad permissions to be helpful in a developer context, and the moment that model processes untrusted content from a public-facing surface like a GitHub Issue, the permissions become the attack surface. The model doesn’t know to distrust the Issue. It was designed to process it.

I’ve been telling clients since the agentic AI wave hit that “helpful” and “privileged” is a dangerous combination without an explicit trust boundary model. RoguePilot proves it doesn’t take a sophisticated threat actor or a zero-day. It takes someone who understands that AI agents read everything they’re shown and act on it.

4. GenAI Democratizes Cybercrime: Low-Skill Actor Breaches 600+ FortiGate Devices Across 55 Countries

Amazon Threat Intelligence published a report on February 20 documenting a Russian-speaking, financially motivated threat actor, assessed as an individual or small group, who used multiple commercial generative AI services to compromise over 600 FortiGate devices in 55 countries between January 11 and February 18, 2026. No FortiGate vulnerabilities were exploited. The campaign targeted exposed management interfaces and weak single-factor credentials, using AI to automate scanning, script generation, configuration parsing, and victim prioritization. Amazon’s CISO CJ Moses described the custom tooling as bearing hallmarks of AI-generated code: redundant comments, naive JSON parsing, and failures under edge cases. When targets proved too hardened, the actor abandoned them and moved on, a pattern consistent with AI-augmented scale rather than technical depth. Post-compromise activity included Active Directory compromise, credential dumping, and targeting of Veeam backup infrastructure (AWS Security Blog, BleepingComputer, Cybersecurity Dive, The Record).

Why it matters

• The campaign demonstrates that AI services lower the barrier to entry for offensive cyber operations at scale. A single actor achieved what would historically require a well-resourced team.

• The activity didn’t rely on any novel exploits. Exposed management ports and missing MFA are the root causes. AI just made systematic exploitation of those gaps cheap and fast.

• Post-compromise actions, Active Directory compromise and backup targeting, align with ransomware pre-positioning. The technical unsophistication of the actor does not constrain the damage ceiling.

What to do about it

• Immediately audit all perimeter devices, especially FortiGate, Palo Alto, and similar appliances, for management interfaces exposed to the internet on any port.

• Enforce MFA across all VPN and admin access without exceptions. This campaign succeeded entirely because MFA was absent.

• Harden backup infrastructure separately from production networks. Backup access should require distinct credentials, not shared Active Directory credentials, and should not be reachable from compromised VPN paths.

Rock’s Musings

Amazon’s description of this actor as achieving “operational scale that would have previously required a significantly larger and more skilled team” is the AI security risk thesis for 2026 stated as a fact. The threat actor’s own documentation, left exposed on their own infrastructure because of poor OpSec, acknowledges when targets are too hardened to exploit. They just move on. That’s not a skill constraint, it’s a volume play.

The lesson here is not new. Missing MFA and exposed management interfaces have been on the “fix this now” list for a decade. What’s new is that ignoring them now feeds a threat actor pipeline that doesn’t get tired, doesn’t need to be patient, and doesn’t cost much to operate. The economics of cyber offense just changed again.

5. IBM X-Force 2026 Threat Index: AI Accelerates Exploitation Speed, 300K ChatGPT Credentials Exposed

IBM published the 2026 X-Force Threat Intelligence Index on February 25, reporting a 44% increase in attacks initiated through the exploitation of public-facing applications, driven by missing authentication controls and AI-enabled vulnerability discovery. Vulnerability exploitation became the leading cause of incidents, accounting for 40% of cases in 2025. Active ransomware and extortion groups increased 49% year over year. Supply chain and third-party compromises nearly quadrupled since 2020. On the AI-specific threat front, X-Force identified over 300,000 exposed ChatGPT credentials from infostealer malware, signaling that AI platforms have reached the same credential risk profile as core enterprise SaaS systems. IBM also noted that North Korean IT worker schemes are using AI for synthetic identity creation and translation to operate across global marketplaces (IBM X-Force, UK Newsroom).

Why it matters

• The ChatGPT credential exposure figure, 300,000 accounts, tells you that enterprise AI platform access is now a target of credential theft campaigns. Account compromise of AI tools creates follow-on risks including manipulated outputs, data exfiltration, and prompt injection by threat actors who gain access.

• The 44% jump in public-facing application exploitation reflects that AI tools are helping attackers identify missing auth controls faster than organizations can patch them.

• North Korean actors using AI for synthetic identity creation to penetrate companies as fake remote IT workers is an active, documented threat that most security teams are unprepared to detect.

What to do about it

• Treat enterprise AI platform accounts like you treat cloud admin accounts. Enforce MFA, monitor for credential exposures via dark web intelligence, and rotate credentials regularly.

• Add AI service accounts to your privileged access management inventory. ChatGPT, Claude, Gemini, and Copilot accounts with sensitive system access are high-value targets.

• Build screening processes for remote technical hires that account for AI-augmented identity fabrication. Resume AI content detection is insufficient. Require live video verification with behavioral assessment.

Rock’s Musings

Three hundred thousand exposed ChatGPT credentials. Let that settle for a moment. A year ago, someone might have asked why stealing a ChatGPT account matters. Now, with AI tools embedded in code pipelines, document workflows, and agentic systems with access to production data, the answer is obvious. Your AI account is your data account.

IBM’s broader finding on supply chain compromise quadrupling since 2020 is the decade-long trend nobody fixed. We’ve known this curve for years. AI is not changing the attack surface, it’s accelerating movement across an attack surface that was already too wide.

6. OpenAI’s February Threat Report: Chinese Law Enforcement Uses ChatGPT to Target Japan’s Prime Minister

OpenAI published a new threat disruption report on February 25, detailing recent cases of AI misuse by nation-state and criminal actors. The report’s lead case involved a Chinese law enforcement operator using a ChatGPT account to attempt to undermine support for Japan’s Prime Minister through a coordinated influence operation. OpenAI’s principal investigator Ben Nimmo described the operation as unusually revealing of China’s strategy for covert influence operations and transnational repression. OpenAI banned the associated accounts and shared indicators with industry partners. The report also documented cases of AI-generated content being used across multiple platforms simultaneously, with threat actors using different AI models at different stages of their operational workflow (OpenAI, Axios).

Why it matters

• Government-affiliated actors using commercial AI tools for foreign influence operations demonstrate that the threat is not limited to custom AI systems. Commodity access is sufficient.

• The targeting of a democratic leader’s public legitimacy via AI-assisted influence operations previews what election and leadership integrity risks look like at scale.

• OpenAI’s two-year publication cadence on these reports is generating actionable public threat intelligence, but the reports also reveal how much AI platforms are dealing with that goes unreported.

What to do about it

• Build operational awareness of influence operations into your executive protection and media monitoring programs. AI-generated content can now target company leadership and board members with the same sophistication used against government officials.

• If your organization operates in sectors with geopolitical exposure, energy, defense, or critical infrastructure, factor AI-assisted influence operations into your threat model.

• Monitor OpenAI’s threat disruption report series as a recurring intelligence source. It’s public, primary, and reflects actual activity on a major AI platform.

Rock’s Musings

The interesting detail in this report is that the Chinese law enforcement operator used ChatGPT as one tool in a broader workflow that touched multiple AI platforms. That’s consistent with what Amazon observed in the FortiGate campaign and what Anthropic documented with the distillation attacks. Threat actors don’t pick one AI tool. They build multi-model workflows just like enterprise teams do.

The policy implication is significant. Restricting any single AI platform’s use by foreign actors doesn’t solve the problem. The capability is distributed. Coordination across AI providers for threat intelligence sharing is the only approach that has a realistic shot at tracking these operational workflows.

7. Anthropic Launches Claude Code Security: AI-Powered Vulnerability Scanning for Enterprise

On February 21, Anthropic began rolling out Claude Code Security, a new capability allowing Claude Code to scan software codebases for vulnerabilities and suggest patches. The feature is in limited research preview for Enterprise and Team customers. The announcement triggered a two-day sell-off in cybersecurity stocks, with GitLab dropping 8% and JFrog falling 25% amid fears that AI-native vulnerability scanning would cannibalize dedicated code-scanning platforms. Bank of America analysts pushed back on the severity of the threat, arguing that the tool poses a significant risk only to code-scanning specialists rather than broader security platforms, and noting that AI-based tools lack the visibility, control, and reliability to replace end-to-end security programs (WIU Cybersecurity Center, CNBC).

Why it matters

• AI-native vulnerability scanning built directly into the development workflow is fundamentally different from dedicated SAST/DAST tools. If it achieves comparable accuracy, the vendor selection calculus for code security tools shifts.

• The market reaction, wiping $4.3 billion in GitLab’s market cap in two days, reflects real investor concern about AI disruption of security tooling categories, not just hype.

• For CISOs, this is a sign to evaluate your code scanning vendor relationships against the trajectory of AI-native alternatives, not to replace them immediately, but to understand your exit options.

What to do about it

• Request a technical briefing from your code scanning vendor on how they are differentiating from AI-native alternatives. Price, integration, and accuracy benchmarks matter.

• Pilot Claude Code Security with a representative engineering team on a low-risk codebase. Generate your own internal benchmark data rather than relying on vendor comparisons.

• Reframe your security tool evaluation process to account for AI-native alternatives in every category, not just code scanning. This is not the last product of this type.

Rock’s Musings

The stock market reaction was overstated. Bank of America is right that AI-powered code scanning doesn’t replace end-to-end security platforms, at least not yet. But the trajectory matters more than the present capability gap. When Anthropic can embed vulnerability detection directly into the coding workflow where developers are already working, the friction of adopting a separate scanning tool becomes a competitive disadvantage for established vendors.

The question I’m asking clients is simpler: if your developers are already using Claude Code daily, and Claude Code Security reduces their friction for addressing vulnerabilities without switching tools, what is the case for a standalone scanning product that adds another context switch?

8. Malicious npm Campaign SANDWORM_MODE Uses 19 Packages to Harvest Crypto Keys and CI Secrets

On February 23, supply chain security firm Socket disclosed an active campaign it codenamed SANDWORM_MODE, a cluster of at least 19 malicious npm packages designed to harvest cryptocurrency keys, CI/CD secrets, and API tokens from developer environments. The packages used dependency confusion and typosquatting techniques to position themselves for installation by developers targeting legitimate packages. Socket described the campaign as a “Shai-Hulud-like” supply chain worm designed to propagate through developer ecosystems by targeting shared package dependencies across interconnected projects (The Hacker News, WIU Cybersecurity Center).

Why it matters

• CI/CD secret theft is the direct path to production system compromise. Developer machines and pipelines hold credentials with scope that far exceeds what individual credentials should carry.

• Supply chain attacks on npm are not novel, but the targeting of cryptocurrency infrastructure alongside CI secrets reflects a broadened target set, both immediate financial gain and longer-term access to production pipelines.

• Organizations with open-source dependencies in their build pipelines and no dependency integrity validation are running a systemic risk that this campaign is designed to exploit.

What to do about it

• Run a dependency audit on your npm packages today, specifically checking for recently added packages matching the naming patterns of heavily used libraries. Tool your CI pipeline to flag any package published in the last 90 days with rapid download acceleration.

• Enforce software bill of materials requirements across your internal build pipelines and require cryptographic attestation for all published packages.

• Restrict CI/CD secrets to minimal scope, rotate them on a regular schedule, and audit which pipelines are storing credentials with broader access than their task requires.

Rock’s Musings

Supply chain attacks on developer tooling have a compounding quality that distinguishes them from most other threat categories. When you compromise a developer’s machine or CI pipeline, you get access to the code before it ships. That means you get to touch production systems through a path that looks like normal development activity. Security controls built around the production perimeter don’t see it coming.

SANDWORM_MODE landing one week after Cline CLI’s supply chain compromise and in the same month as RoguePilot is not a coincidence. The developer toolchain is the current hot frontier. If your security program doesn’t have explicit coverage of the npm ecosystem, your CI/CD secrets posture, and your AI-assisted development tooling, you have a gap that multiple active campaigns are targeting right now.

9. AI-Driven Cyberattacks Now Breach Systems in an Average of 72 Minutes

A study published February 23 via BusinessWorld Online and cited in a February cybersecurity roundup found that AI-driven cyberattacks now breach target systems in an average of 72 minutes from initial contact. The figure illustrates how AI tooling is compressing the exploitation timeline by automating vulnerability identification, credential testing, lateral movement planning, and exploitation scripting in near-real time. The finding aligns with Amazon’s FortiGate campaign documentation and IBM X-Force’s 44% jump in application exploitation figures published the same week, suggesting a convergence of independent research pointing to the same fundamental shift (BusinessWorld Online, Advanced IT Technologies cybersecurity roundup).

Why it matters

• A 72-minute average breach timeline means that the traditional “detect, investigate, respond” model is effectively broken at its current operational tempo. You need detection and automated containment that operates in minutes, not hours.

• The compression of attack timelines is a direct consequence of AI tooling automating what previously required skilled human intervention at each step.

• Your incident response plans and SOC SLAs were probably not written with a 72-minute adversary dwell window in mind. That’s the process gap this creates.

What to do about it

• Benchmark your current mean time to detect against the 72-minute figure. If your average detection time exceeds that, you are consistently behind the adversary timeline.

• Implement automated network-isolation triggers for anomalous credential usage and lateral-movement indicators that don’t require human approval in the initial response phase.

• Run a tabletop exercise against a 72-minute breach scenario. The point is forcing your team to confront the tempo of modern AI-assisted attacks on paper before they face it live.

Rock’s Musings

Seventy-two minutes. Think about what your SOC is doing at 3:17 a.m. on a Tuesday when that timer starts. The alert might not even be triaged by the time the attacker has Active Directory. This is the operational reality that makes the continuous, automated detection and response investment non-negotiable.

The productivity framing of AI security tools, “AI helps your analysts work faster,” is a secondary benefit at best. The primary reason to deploy AI-assisted detection is that the adversary is already using it, and your organization cannot match the attack tempo with humans alone.

10. Exposed LLM Endpoints Expanding the Attack Surface for Organizations Running Their Own Models

On February 23, threat researchers published an analysis in The Hacker News documenting how organizations deploying their own large language models are creating new internal attack surfaces through unprotected LLM endpoints and supporting APIs. The research observed that modern security risks for LLM deployments originate less from the models themselves and more from the infrastructure serving them: APIs, orchestration layers, model registries, and tool-calling endpoints. Each new LLM endpoint expands the attack surface, often with no authentication controls, minimal logging, and no separation from internal data systems (The Hacker News, WIU Cybersecurity Center).

Why it matters

• Organizations are deploying internal LLMs without applying the same security posture they would apply to any other internal API. Unauthenticated model endpoints with access to internal data are exactly the kind of target that opportunistic and targeted attackers seek.

• LLM orchestration layers, the middleware connecting models to internal tools, databases, and external services, represent a new class of attack surface with no established hardening standard.

• The vulnerability exposure is not primarily in the model weights or training data. It is in the infrastructure decisions made during deployment, which are often made by teams with no security review.

What to do about it

• Conduct an inventory of every internal LLM endpoint in your environment, including development and experimental deployments. Apply authentication requirements to all of them without exception.

• Include AI infrastructure, model endpoints, orchestration APIs, vector databases, and tool-calling integrations in your penetration testing scope. Most current pentest methodologies do not cover these surfaces.

• Establish a minimum security baseline for any internal AI deployment, including authentication, logging, rate limiting, and network segmentation, before any model reaches non-development environments.

Rock’s Musings

This is the AI security gap that will generate the embarrassing breach stories of 2027. Right now, teams are spinning up internal RAG systems, agentic workflows, and model fine-tuning pipelines on infrastructure that wasn’t designed for adversarial access. The model is not the weak link. The unprotected API sitting in front of it, with access to your internal document store, is the weak link.

The pattern is familiar. Every time a new technology category emerges, the same thing happens: deployment races ahead of security posture, and the community learns the hard way. We’re early in the AI infrastructure deployment curve. The window to get ahead of this is narrowing fast.

The One Thing You Won’t Hear About But You Need To

Infostealer Malware Now Targeting OpenClaw AI Agent Configuration Files and Gateway Tokens

On February 24, The Hacker News reported on a new infostealer variant specifically designed to steal OpenClaw AI agent configuration files, API tokens, and gateway credentials from developer and enterprise systems where OpenClaw is installed. The malware targets OpenClaw’s local storage paths and the WebSocket Gateway daemon credentials, providing persistent, privileged access to the systems on which the agent is installed. The timing of this discovery follows the Cline CLI supply chain compromise that forced thousands of unauthorized OpenClaw installations in mid-February, and a separately disclosed critical vulnerability in OpenClaw versions before 2026.1.29 (CVE-2026-25253, CVSS 8.8) that allowed unauthenticated operator-level access through a crafted WebSocket handshake (The Hacker News).

Why it matters

• AI agent credentials are a new, high-value target class. An attacker with OpenClaw gateway tokens has a persistent foothold in the target environment with broad system permissions, the same permissions OpenClaw uses to perform its legitimate autonomous tasks.

• The convergence of a supply chain attack forcing OpenClaw installations, a critical unpatched vulnerability in older versions, and a dedicated infostealer targeting its credentials represents a rare three-vector alignment against a single AI platform.

• Organizations that don’t know OpenClaw is installed in their environment, which includes anyone who installed Cline CLI during the February 17 compromise window and didn’t remediate, are running exposed agent infrastructure they may not know exists.

What to do about it

• Run an immediate audit for OpenClaw installations across your developer and CI/CD environments. If you find instances you didn’t authorize, treat them as compromised until proven otherwise.

• Verify all OpenClaw installations are running version 2026.1.29 or later to eliminate the CVE-2026-25253 authentication bypass exposure.

• Restrict OpenClaw’s network access to explicitly needed destinations and audit the permissions granted to its agent execution context. AI agents with broad permissions and persistent daemons should be treated as privileged processes, not user applications.

Rock’s Musings

Nobody is writing the headline “Infostealer Targets AI Agent Credentials.” But they should be. This is the next phase of the credential theft ecosystem, and it has been visible coming for anyone who has watched how quickly OpenClaw gained deployment share in enterprise developer environments.

AI agents have privileged access to your systems by design. That’s what makes them useful. It’s also what makes their credentials extraordinarily valuable to attackers. When an infostealer can steal an AI agent’s configuration and token in the same way it steals browser-stored passwords, you’ve added a new category of credential to your exposure surface. Your existing credential monitoring program almost certainly doesn’t cover this yet.

Share RockCyber Musings

References

Amazon Web Services Security. (2026, February 20). AI-augmented threat actor accesses FortiGate devices at scale. https://aws.amazon.com/blogs/security/ai-augmented-threat-actor-accesses-fortigate-devices-at-scale/

Anthropic. (2026, February 23). Detecting and preventing distillation attacks. https://www.anthropic.com/news/detecting-and-preventing-distillation-attacks

Allyn, B. (2026, February 24). Hegseth threatens to blacklist Anthropic over ‘woke AI’ concerns. NPR. https://www.npr.org/2026/02/24/nx-s1-5725327/pentagon-anthropic-hegseth-safety

Swan, J., & Borsuk, A. (2026, February 25). Trump admin moves toward blacklisting Anthropic in AI safeguards fight. Axios. https://www.axios.com/2026/02/25/anthropic-pentagon-blacklist-claude

The Hacker News. (2026, February 24). RoguePilot flaw in GitHub Codespaces enabled Copilot to leak GITHUB_TOKEN. https://thehackernews.com/2026/02/roguepilot-flaw-in-github-codespaces.html

Orca Security. (2026, February 24). RoguePilot: Critical GitHub Copilot vulnerability exploit. https://orca.security/resources/blog/roguepilot-github-copilot-vulnerability/

SecurityWeek. (2026, February 24). GitHub Issues abused in Copilot attack leading to repository takeover. https://www.securityweek.com/github-issues-abused-in-copilot-attack-leading-to-repository-takeover/

The Hacker News. (2026, February 23). Anthropic says Chinese AI firms used 16 million Claude queries to copy model. https://thehackernews.com/2026/02/anthropic-says-chinese-ai-firms-used-16.html

CNBC. (2026, February 24). Anthropic accuses DeepSeek, Moonshot and MiniMax of distillation attacks on Claude. https://www.cnbc.com/2026/02/24/anthropic-openai-china-firms-distillation-deepseek.html

TechCrunch. (2026, February 23). Anthropic accuses Chinese AI labs of mining Claude as US debates AI chip exports. https://techcrunch.com/2026/02/23/anthropic-accuses-chinese-ai-labs-of-mining-claude-as-us-debates-ai-chip-exports/

IBM. (2026, February 25). IBM 2026 X-Force Threat Intelligence Index. https://uk.newsroom.ibm.com/ibm-2026-x-force-threat-index

BleepingComputer. (2026, February 21). Amazon: AI-assisted hacker breached 600 Fortinet firewalls in 5 weeks. https://www.bleepingcomputer.com/news/security/amazon-ai-assisted-hacker-breached-600-fortigate-firewalls-in-5-weeks/

Cybersecurity Dive. (2026, February 23). AI helps novice threat actor compromise FortiGate devices in dozens of countries. https://www.cybersecuritydive.com/news/ai-cyberattacks-fortigate-amazon/812830/

OpenAI. (2026, February 25). Disrupting malicious uses of AI. https://openai.com/index/disrupting-malicious-ai-uses/

CNBC. (2026, February 23). Cybersecurity stocks drop for a second day as new Anthropic tool fuels AI disruption fears. https://www.cnbc.com/2026/02/23/cybersecurity-stocks-anthropic-ai-crowdstrike.html

WIU Cybersecurity Center. (2026, February 25). Cybersecurity news. https://www.wiu.edu/cybersecuritycenter/cybernews.php

The Hacker News. (2026, February 23). Malicious npm packages harvest crypto keys, CI secrets, and API tokens. https://thehackernews.com/2026/02/malicious-npm-packages-harvest-crypto.html

The Hacker News. (2026, February 24). Infostealer steals OpenClaw AI agent configuration files and gateway tokens. https://thehackernews.com/2026/02/infostealer-steals-openclaw-ai-agent.html

BusinessWorld Online via Advanced IT Technologies. (2026, February 23). AI-driven cyberattacks now breach systems in 72 minutes, study finds, cited in: February 2026 cybersecurity news roundup. https://www.advancedittechnologies.com/post/february-2026-cybersecurity-news-roundup-major-breaches-ai-driven-attacks-critical-vulnerabiliti

The Hacker News. (2026, February 23). How exposed endpoints increase risk across LLM infrastructure. https://thehackernews.com/2026/02/how-exposed-endpoints-increase-risk.html

Dark Reading. (2026, February 21). 600+ FortiGate devices hacked by AI-armed amateur. https://www.darkreading.com/threat-intelligence/600-fortigate-devices-hacked-ai-amateur

The Record. (2026, February 23). Russian-speaking hackers used gen AI tools to compromise 600 firewalls, Amazon says. https://therecord.media/gen-ai-fortigate-hackers-russia

Share

Singapore’s Model AI Governance Framework for Agentic AI landed on January 22, 2026, and it’s the first national-level governance framework purpose-built for autonomous AI agents. That matters. It also tells you what to think about without telling you what to do. And in three critical areas, what it tells you is incomplete enough to create false confidence. If you’re a CISO using this as your agentic AI governance blueprint, you need to know where the gaps will bite you.

What Singapore gets right

Credit where earned. IMDA produced something useful, and I want to be specific about why.

The four-dimension structure (assess and bound risks, make humans accountable, implement technical controls, enable end-user responsibility) gives organizations a governance skeleton that maps cleanly to how enterprises already think about risk management. You can hand this to a board member, and they’ll recognize the logic. That’s not nothing. Most governance frameworks read like they were written for compliance analysts who’ve never shipped a product.

The risk-factor rubric in §2.1.1 is the framework’s strongest operational contribution. It breaks risk into impact factors (domain tolerance for error, access to sensitive data, access to external systems, scope of agent actions) and likelihood factors (level of autonomy, task complexity, exposure to untrusted data). This gives you a concrete rubric for evaluating whether a use case is appropriate for agent deployment. Not theoretical. Practical. The kind of table a security architect can pull into a risk register tomorrow morning.

The tradecraft preservation warning in §2.4.3 is rare for a governance document and directly relevant to every security leader reading this. The framework warns that “as agents take over entry-level tasks, which typically serve as the training ground for new staff, this could lead to loss of basic operational knowledge.” If you run a security team where AI coding assistants are displacing junior analyst skill development, this section just validated a concern you’ve probably struggled to articulate to leadership. IMDA recommends organizations “identify core capabilities of each job and provide sufficient training and work exposure so that users retain foundational skills.” I’d frame it more bluntly: if your junior analysts can’t triage an alert without an AI assistant, you don’t have a security team. You have a dependency.

The graduated rollout guidance in §2.3.3 recommends controlling agent deployment based on three vectors: users (trained users first), tools (whitelisted MCP servers first), and systems (lower-risk internal systems first). This is how production deployments should work. It reflects real operational experience rather than theoretical deployment models.

So yes, Singapore did something that no other nation has done. They put agentic AI governance in writing, at a national level, with enough specificity to be useful. Now let me explain why “useful” isn’t the same as “sufficient.”

HITL at agentic scale is security theater

The framework’s central accountability mechanism is human-in-the-loop oversight at “significant checkpoints” (§2.2.2, p.16). Singapore correctly identifies automation bias as “a bigger concern with increasingly capable agents” (p. 13). The framework recommends training humans to identify failure modes, auditing oversight effectiveness, and complementing human review with automated monitoring.

All reasonable. All insufficient.

The math doesn’t work. Let me show you.

Take a mid-size enterprise running 50 agents across customer service, code review, procurement, and data analysis. Each agent makes 20 tool calls per hour. That produces 1,000 approval-eligible events per hour. Even if only 10% require human review, your security team faces 100 approval requests per hour during business operations. At two minutes per meaningful review, that consumes over three full-time equivalents solely for agent oversight. Not security work. Not threat hunting. Not incident response. Rubber-stamping.

The framework provides no guidance on this capacity calculation. No threshold for when human review becomes performative. No architectural alternative for when HITL saturates.

The OWASP Agentic AI Threats and Mitigations Guide classifies Overwhelming HITL (T10) as a deliberate attack vector. Adversaries can exploit the approval bottleneck by generating a flood of low-risk requests that train reviewers to rubber-stamp, then embed high-risk actions in the stream.

The Anthropic/OpenAI joint paper on governing agentic AI systems directly warns that “when the user must approve many decisions and thus must make each approval quickly, reducing their ability to meaningfully consider each one,” the oversight becomes performative. The framework’s answer to automation bias is training and auditing. Training doesn’t change the cognitive architecture that produces complacency under sustained approval loads. You can’t train your way out of a capacity problem.

HITL works for low-volume, high-consequence decisions. It fails everywhere else. For the vast majority of agentic operations, organizations need tiered, consequence-based automation. Auto-approve low-risk reversible actions with logging. Route medium-risk actions through a watchdog agent (what some practitioners call the Janus pattern) for secondary validation. Reserve genuine human review for irreversible, high-blast-radius decisions only.

The framework’s blanket “define significant checkpoints” guidance will produce compliance artifacts, not security outcomes.

Agent identity is broken, not “evolving”

The framework describes agent identity challenges as an “an evolving space” in which “gaps exist today” (§2.1.2, p. 11). This framing suggests that the problem will be resolved through incremental improvements to existing identity and access management systems.

It won’t. The problem is architectural.

Human IAM systems rest on three assumptions that agents violate. First, the entity requesting access can meaningfully consent to terms. An agent can’t meaningfully consent to OAuth scopes because it doesn’t understand what it’s granting. Second, the entity’s identity persists across sessions in a verifiable way. An agent’s identity may be ephemeral, spawned for a single task, then destroyed, or recursive, spawning sub-agents that inherit some permissions but not others. Third, authorization scopes are understood by the entity at request time. For agents, authorization scopes are determined at runtime by the planning module, not at request time by a human clicking “Allow.”

The OWASP Agentic Top 10 (ASI03, December 2025) puts this plainly, “Without a distinct, governed identity of its own, an agent operates in an attribution gap that makes enforcing true least privilege impossible.” If you can’t attribute an action to a specific identity with verifiable scope, every downstream control the framework recommends, least privilege, access logging, accountability chains, rests on an unreliable foundation.

The OAuth consent model breaks down entirely for agentic workloads. Three-legged OAuth was designed for human consent flows where a user clicks “Allow” and understands what they’re granting. When an agent orchestrator requests OAuth scopes on behalf of a user, the consent model collapses. The agent can’t meaningfully consent, and the human operator often doesn’t know what scopes the agent will request at runtime.

The empirical evidence makes this worse. The Agent Skills in the Wild study found excessive permission requests (PE1) across 94 skills that requested permissions far beyond stated functionality. This isn’t a bug in a few implementations. It’s the default behavior in the wild. Agents ask for more access than they need because the systems granting access weren’t designed to question them.

The framework’s interim best practices (unique agent IDs, recording delegation, tying identity to supervising humans) are reasonable temporary measures, but calling this “evolving” rather than “broken” understates the urgency. Organizations should treat agent identity as a pre-deployment blocker for high-autonomy agents, not a checkbox to revisit later. Until agent-native identity primitives exist, decentralized identity, cryptographically bound intent, task-scoped ephemeral credentials, the accountability chain the framework builds on top of identity is structurally unsound.

MCP gets two bullet points in a 29-page framework. That’s negligent.

The entire MCP security guidance in Singapore’s framework reads: “For MCP servers: Whitelist trusted servers and only allow agent to interact with servers on that whitelist. Sandbox any code execution” (§2.3.1, p.19). That’s it. Two bullet points for the protocol rapidly becoming the standard interface between AI agents and the external world.

Since Anthropic introduced MCP, adoption has exploded. Over 10,000 MCP servers are deployed. Claude, Cursor, Microsoft Copilot, Gemini, VS Code, and ChatGPT all support the protocol. In December 2025, Anthropic, OpenAI, and Block donated MCP and other projects to the Linux Foundation’s Agentic AI Foundation. MCP is infrastructure now. And the framework treats it like a footnote.

MCP’s threat surface spans three lifecycle phases, and the framework addresses only a fragment of the first one.

During creation, MCP servers face installer spoofing, supply-chain backdoors, name collision attacks, and the absence of authentication handshakes. The framework’s “whitelist trusted servers” advice partially addresses this phase. Partially.

During operations is where things get dangerous. Documented attacks include tool poisoning (malicious commands embedded in tool descriptions that the LLM executes as instructions), credential theft, sandbox escape, command injection, remote code execution, and the rug pull attack. The rug pull is particularly insidious as a legitimate tool passes initial vetting, earns whitelist status, then silently changes behavior during an update. The framework’s whitelisting guidance assumes trust is both verifiable and persistent. The rug pull attack exploits exactly this assumption.

During updates, servers face version drift, privilege persistence, configuration drift, and unsigned manifests. The framework says nothing about any of these.

The experimental evidence should alarm you. Research on LLM-driven AI agent communication reports MCP exploits that achieved Bash shell backdoors on port 4444, SSH key exfiltration via email, and file deletion without triggering alerts. These aren’t theoretical attacks. They were demonstrated in controlled experiments.

The first malicious MCP server discovered in the wild impersonated Postmark’s email service on npm and silently BCC’d every agent-sent email to the attacker. This is supply chain security applied to the AI protocol layer, and the framework doesn’t address it.

Whitelisting without tool integrity monitoring, version pinning, hash verification of tool descriptions, and runtime policy enforcement at the MCP boundary creates a false sense of security. Organizations implementing this framework need to treat MCP servers with the same rigor applied to third-party software dependencies. Pin versions. Verify checksums. Monitor for behavioral changes. Enforce runtime sandboxing that restricts tool access to files, APIs, and network endpoints beyond the declared scope.

The gaps the framework weaves around

Two additional blind spots deserve attention, not as standalone failures, but as force multipliers for the three critical gaps above.

The framework treats instructions, memory, and tools as functional agent components (§1.1.1, pp.3-4) without recognizing that they all converge in a shared, flat trust namespace. The OWASP GenAI Data Security Guide puts it starkly. The “context window aggregates multiple trust domains into a single flat namespace with no internal access control. RAG results, system prompts, user input, tool outputs, and conversation history all land in the same context with equal trust weight.” If you’re securing individual components (tools, memory, instructions) without addressing the architectural vulnerability that connects them, you’re securing individual rooms while leaving the hallways unguarded.

The framework also assumes organizations consciously deploy agentic AI through a controlled pipeline. The clean value chain diagram (model developers, system providers, deploying organization, end users) describes how agents should be deployed. Every major AI platform now offers agent-building capabilities accessible to non-technical users. Microsoft Copilot Studio, Salesforce AgentForce, and dozens of startups let business users create agents that connect to organizational data, send emails, update databases, and make API calls, all without security team involvement. Shadow AI agents inherit every risk the framework describes but operate entirely outside the governance structures it recommends. A CISO should spend equal effort on discovery and containment of unauthorized agents as on governing sanctioned ones.

The honest assessment

Singapore’s framework tells you what to think about. The OWASP Agentic Top 10 outlines what to defend against across 10 threat categories (ASI01-ASI10), with specific vulnerability descriptions and mitigation strategies for each. The MAESTRO threat modeling framework provides 47 threat IDs organized across seven architectural layers with specific mitigations. The OWASP Securing Agentic Applications Guide provides implementation-level controls.

The Singapore framework sits at the “governance structure” tier. That tier is necessary, but it’s not sufficient. If you hand this to your team as “the agentic AI governance playbook,” you’ll produce compliance artifacts without meaningfully reducing risk.

Key Takeaway: Singapore built the governance skeleton for agentic AI. The immune system, the controls that catch what gets past the perimeter, remains your engineering problem.

What to do next

Three things the framework doesn’t tell you that your team needs tomorrow.

First, quantify your HITL capacity. Use this formula: (agent decision rate) times (approval time per decision) times (number of active agents) equals required human reviewer hours. When that number exceeds available capacity, you need tiered automation, not more reviewers. Build HITL saturation metrics and circuit breakers that automatically reduce agent autonomy when human review queues exceed defined thresholds.

Second, harden MCP with zero-trust assumptions. The OWASP GenAI Security Project published two guides that give you an operational playbook the Singapore framework doesn’t: “A Practical Guide for Secure MCP Server Development” (February 2026) for teams building MCP servers, and “A Practical Guide for Securely Using Third-Party MCP Servers” (October 2025) for teams consuming them. Start with their governance workflow: require developers to submit third-party MCP servers with documentation and a hash of tool descriptions, run automated scans for malware and hidden instructions, then version-pin approved servers in a trusted registry before deployment. For rug pull defense, pin the version of each MCP server and its tools at the time of initial approval, use a hash or checksum to verify tool descriptions and functionality haven’t been altered, and maintain version history with alerts on unauthorized changes. Require cryptographic tool manifests, signed packages that include description, schema, version, and required permissions, verified at load time. Run third-party MCP servers inside Docker containers to prevent compromised tools from accessing host files or escaping the operating environment. Enforce least-privilege policies at the MCP boundary to restrict tools from reading local files, accessing sensitive APIs, or exfiltrating data beyond declared scope. For multi-tenant deployments, isolate sessions with per-user execution contexts and deterministic cleanup routines that flush file handles, temp storage, and cached tokens on session termination. These two guides give you the implementation details that §2.3.1’s two bullet points leave out.

Third, hunt for shadow AI agents. Deploy network monitoring for MCP traffic from unapproved endpoints. Configure API gateways to detect agent-pattern behavior: rapid sequential API calls, tool-use headers, automated OAuth token requests. Update acceptable use policies to cover agent creation explicitly. Treat every discovered shadow agent as an incident requiring risk assessment before it continues operating.

The framework is a starting point. It’s not a destination. Use it as a governance structure, then fill the operational gaps with OWASP guidance, real-world threat intelligence, and the uncomfortable math that governance documents avoid.

👉 Subscribe for more AI security and governance insights with the occasional rant.

👉 Visit RockCyber.com to learn more about how we can help you in your traditional Cybersecurity and AI Security and Governance Journey

👉 Want to save a quick $100K? Check out our AI Governance Tools at AIGovernanceToolkit.com

Share RockCyber Musings

Share

The week of February 13, 2026 handed CISOs a masterclass in what AI security actually looks like when the theory meets the road. State-sponsored hackers are using Google’s own AI to run recon on your employees. The most popular AI agent framework turned its plugin marketplace into a malware distribution network. The tool your help desk uses for remote access got a CVSS 9.9 exploit actively running in the wild. And somewhere in your organization, someone probably asked an LLM for a password.

None of this is hypothetical anymore. The attack surface is the entire AI stack: the models, the agents, the marketplaces, the APIs, the infrastructure those agents touch, and the humans who trusted all of it more than they should have. If your AI governance program still lives in a slide deck, this week is a good reason to print it out and start over.

1. Nation-State Hackers Are Using Gemini for Every Stage of the Kill Chain

Google’s Threat Intelligence Group (GTIG) published its quarterly AI Threat Tracker report on February 12, documenting that state-sponsored actors from China, Iran, North Korea, and Russia are now using Gemini across reconnaissance, phishing, malware development, and post-compromise activities (Google GTIG). Chinese actors used Gemini to pose as security researchers and automate vulnerability analysis against U.S. targets, including RCE testing and WAF bypass techniques. North Korean group UNC2970 queried the tool multiple days a week for technical support and to profile high-value targets at cybersecurity and defense firms. Iran’s APT42 used it to craft hyper-personalized phishing lures with culturally accurate language, eliminating the grammar errors defenders have long relied on as a detection signal. GTIG also identified HONESTCUE, a malware downloader that calls Gemini’s API to generate C# code for second-stage payloads in real time, and COINBAIT, a cryptocurrency-themed phishing kit built with AI code generation tools.

Why it matters

• Phishing lure quality has fundamentally changed. AI-generated messages in native language with accurate cultural context defeat the grammar-based heuristics your security awareness training still teaches.

• The HONESTCUE model of AI-as-a-backend-service for malware means attackers can generate unique payloads per target without static signatures to detect.

• Google confirmed model extraction attacks at scale, where actors queried Gemini roughly 100,000 times in multiple languages to replicate its reasoning capabilities in competing systems.

What to do about it

• Brief your security awareness teams that grammar and awkwardness are no longer reliable phishing indicators. Update training to focus on unsolicited contact, urgency, and out-of-band verification.

• Inventory which internal systems Gemini or any LLM API can reach. An AI-generated payload that hits an exposed internal endpoint needs a path there. Find those paths.

• Review your threat model for credential-harvesting scenarios where AI-accelerated OSINT shortens attacker dwell time in the reconnaissance phase. Reduce your publicly available employee footprint where possible.

Rock’s Musings

AI doesn’t give attackers magic powers; it gives them scale and speed at tasks they already knew how to do. This and Anthropic’s GTG-1002 are the proof. The North Koreans aren’t doing anything novel, but they are doing reconnaissance faster and with more precision, and they’re doing it with a tool you’re probably paying for with your corporate account. The fact that China tried to get Gemini to plan RCE attacks against U.S. targets by pretending to be a CTF participant is almost funny, except that it worked often enough to be worth documenting.

The model extraction finding is the most alarming. If a foreign intelligence service builds a Gemini-equivalent using 100,000 queries of the real thing, they have a tool that behaves like Gemini with none of Google’s safety controls. That’s a bigger long-term problem than any single phishing campaign, and it’s one the enterprise sector has almost no visibility into.

2. OpenClaw’s Security Crisis Escalates: 1,184 Malicious Skills, a Foundation Handoff, and a Race to Patch

OpenClaw, the AI agent framework with 212,000 GitHub stars as of this writing, spent this week proving that rapid adoption without a security architecture is a gift to attackers (SC Media, SecurityWeek). The ClawHavoc supply chain campaign, first disclosed February 1, grew to at least 1,184 confirmed malicious skills in ClawHub, the platform’s third-party plugin marketplace. Antiy CERT’s analysis found payloads using staged downloads, reverse shells via Python system calls, and direct data theft, including the Atomic macOS Stealer (AMOS) targeting browser credentials, SSH keys, and crypto wallets. A single threat actor uploaded 354 malicious packages in what appears to have been an automated blitz. On Valentine’s Day (there is a certain irony here), OpenClaw founder Peter Steinberger announced he was joining OpenAI to lead personal agent development, with the project transitioning to the OpenClaw Foundation under OpenAI sponsorship. By February 19, SecurityWeek reported the launch of SecureClaw, an open-source hardening tool running 55 automated audit checks mapped to OWASP’s Agentic Security Initiative top 10 and MITRE ATLAS.

Why it matters

• ClawHub had no automated static analysis, no code signing, and no review process. Publishing a malicious skill required only a GitHub account one week old. Your developers are treating this marketplace like a trusted source.

• OpenClaw’s persistent memory files (SOUL.md, MEMORY.md) were targeted, meaning malicious payloads can modify the agent’s long-term behavioral instructions and wait before triggering. Point-in-time malware analysis misses this entirely.

• The transition to an OpenAI-sponsored foundation means a consumer-grade security nightmare is now a tier-one organization’s responsibility to clean up.

What to do about it

• Audit your environment for OpenClaw deployments now. Any instance predating February 1, 2026 with API keys loaded should be treated as potentially compromised and keys rotated.

• Treat every ClawHub skill like an untrusted third-party binary before installing it. No README is trustworthy. No prerequisite installation step should execute without review.

• Engage your developer community on the SecureClaw hardening checks. If your org is running OpenClaw agents, you need the 55-point audit baseline before any production use.

Rock’s Musings

When a security researcher found 386 malicious packages from a single threat actor in OpenClaw's ClawHub marketplace, Steinberger told him security 'isn't really something he wants to prioritize.' He's since changed his tune on Lex Fridman's podcast, hired a security lead, and partnered with VirusTotal for malware scanning. Good. Progress matters. But sandboxing is still opt-in. The defaults still ship insecure. Words on a podcast don't fix architecture. I don't blame Steinberger for building fast and asking questions later. That's how open-source adoption works. I do blame the enterprises that deployed it without asking whether anyone had thought about what happens when the agent has shell access and the plugin store has no gates.

The OpenAI foundation takeover is interesting. Either OpenAI is going to clean this up properly, which would take real investment in supply chain security, or they’re going to inherit the liability that comes with 212,000 GitHub stars pointing at a platform with 20% malicious packages in its ecosystem. I’d watch that situation carefully. For now, the practical answer is: if OpenClaw is running in your environment, it is a high-severity finding until proven otherwise.

3. BeyondTrust CVE-2026-1731 Hits Active Exploitation; CISA Mandates Federal Patching by February 16

CISA added CVE-2026-1731 to its Known Exploited Vulnerabilities catalog on February 13, 2026, mandating that Federal Civilian Executive Branch agencies apply patches by February 16 (CISA, Help Net Security). The vulnerability, CVSS 9.9, allows an unauthenticated attacker to execute arbitrary OS commands against BeyondTrust Remote Support and Privileged Remote Access products via a crafted WebSocket request with zero user interaction required. watchTowr’s Ryan Dewhurst confirmed in-the-wild exploitation through global sensor networks, and Arctic Wolf separately detected attacks attempting to deploy the SimpleHelp RMM tool for persistence with lateral movement into Active Directory. BeyondTrust patched SaaS instances automatically on February 2 but self-hosted customers required manual action. The flaw was discovered by the Hacktron AI team using AI-enabled variant analysis after studying a related Ivanti bug, identifying approximately 8,500 exposed on-premises instances.

Why it matters

• BeyondTrust serves 75% of the Fortune 100. A pre-auth RCE in privileged remote access infrastructure is a direct path to crown jewel systems, with no prior foothold required.

• The Silk Typhoon precedent from 2024 means Chinese state actors have already demonstrated intent to exploit BeyondTrust products at scale. With active exploitation confirmed, the question is who got there first.

• AI-enabled variant analysis cut the time from patch release to public PoC to under two weeks. Discovery-to-exploitation timelines are compressing in both directions simultaneously.

What to do about it

• Patch now. Any Remote Support version 25.3.1 or earlier and PRA version 24.3.4 or earlier is vulnerable. Self-hosted customers who have not applied BT26-02 should assume compromise and begin incident response procedures.

• Segment BeyondTrust deployments from internal networks wherever architecturally possible. Post-exploitation lateral movement via ActiveDirectory was confirmed in at least one attacker cluster.

• Revisit your exposure to other BeyondTrust products. The variant analysis method that found this vulnerability treats entire vulnerability classes as attack surface, not individual CVEs.

Rock’s Musings

BeyondTrust is having a rough patch. They already had Silk Typhoon weaponize a zero-day against the U.S. Treasury in December 2024. Now they have a CVSS 9.9 pre-auth RCE with confirmed exploitation inside two weeks of public disclosure. The pattern of targeting is not a coincidence." This is the product pattern where a dominant market position in privileged access makes you a permanent priority target. Silk Typhoon already told us what they do with access to BeyondTrust once they have it.

The AI angle here is the one worth pausing on. Hacktron AI found this vulnerability by doing AI-assisted variant analysis across codebases after reading watchTowr’s technical writeup on a related Ivanti bug. The entire discovery-to-exploitation cycle, from responsible disclosure to confirmed mass scanning, played out in 13 days. If your patching cycle runs longer than that for critical remote access infrastructure, this CVE is the poster child for why that has to change.

4. Cline npm Supply Chain Attack Silently Installs OpenClaw on Developer Machines

On February 17, 2026, an unknown actor used a stolen npm publish token to release cline@2.3.0 with one change: a postinstall script that silently deployed OpenClaw on any machine that updated during an eight-hour window (GitHub Security Advisory GHSA-9ppg-jx86-fqw7). Adnan Khan had reported the root cause, a prompt injection vulnerability in Cline’s Claude-powered issue triage workflow that enabled GitHub Actions cache poisoning and credential theft, privately on January 1, followed up four times, and got no response. He went public February 9. Cline patched in 30 minutes. The token was already gone.

Michael Bargury, CTO of Zenity, ran RAPTOR, the open-source forensics tool built by Gadi Evron, CEO of Knostic, against the advisory URL and had full attribution in five minutes: actor glthub-actions (a typosquat using a lowercase L), the weaponized issue, and the exfiltration infrastructure. The critical finding is that the attacker found Khan’s public proof-of-concept test repository on January 2 and struck on January 28, ten days before full disclosure. Patch windows don’t protect you when the POC is already public.

Why it matters

• GitHub Actions workflows that hand AI agents broad tool permissions and accept untrusted input from public issue trackers are an attack surface most teams haven’t mapped. That pattern is common right now.

• The attacker moved during coordinated disclosure, not after. Your vendor’s patch timeline offers no protection if a researcher’s test repo is public while they’re waiting for a response.

• RAPTOR produced high-confidence attribution from a single URL in five minutes. Attackers doing threat intelligence on your vendors have the same capability.

What to do about it

• Audit every GitHub Actions workflow using AI agents for untrusted input paths. Issue titles, PR descriptions, and branch names are all attacker-controlled strings.

• Enforce --ignore-scripts in automated build environments and scope npm publish tokens to the minimum necessary. A token that can publish anything in your org is a single point of failure.

• Add AI-assisted forensics tooling to your IR playbook before you need it. Five minutes to attribution is the new baseline expectation.

Rock’s Musings

I know both Michael and Gadi, and watching RAPTOR nail full attribution in five minutes while the rest of the industry was still reading the advisory is exactly the kind of thing that should embarrass every security team still running manual IR processes. Khan did everything right. Six weeks of responsible disclosure, documented in detail, across every available channel, ignored completely. The vendor patched in 30 minutes once the blog went public. The gap between those two timelines is where the breach lived.

The meta-structure here is almost too clean. An AI agent with misconfigured permissions accepted natural language from anonymous internet users and handed an attacker publish credentials for a 4 million user developer tool. Then an AI forensics agent reconstructed the crime scene from a URL. Attacker used AI as a weapon. Defender used AI as a microscope. What separated the outcomes wasn’t sophistication. It was that the vendor ignored six weeks of warning. If a researcher is trying to reach you, pick up the phone.

5. AI-Generated Passwords Are Fundamentally Insecure, and Vibe Coding Is Shipping Them to Production

AI cybersecurity firm Irregular published research on February 18-19 showing that ChatGPT, Claude, and Gemini generate highly predictable passwords with dramatically reduced entropy compared to cryptographically secure random generation (The Register, Malwarebytes). When Irregular prompted Claude Opus 4.6 fifty times, 20 of the 50 results were duplicates and 18 were the exact same string. Every Claude-generated password began with an uppercase “G” and used the same narrow character subset. GPT-5.2 started nearly all passwords with “v” and used “Q” as the second character in nearly half of outputs. The researchers measured 20 to 27 bits of entropy in LLM-generated 16-character passwords versus the 98 to 120 bits expected from cryptographically random generation. Irregular noted the problem is not fixable by prompt engineering or temperature adjustments, since the predictability is structural to how LLMs generate tokens.

Why it matters

• Any developer who used an LLM to generate a password, secret, or API key in production code has shipped a predictable, likely crackable credential. Code review doesn’t catch this because the string looks complex.

• Attackers can now build wordlists from known LLM output patterns. If your environment has credentials generated this way, those wordlists apply to you directly.

• The gap between “looks strong” and “is strong” is exactly the kind of mismatch that causes silent, undetected compromises over months.

What to do about it

• Audit your codebase and configuration management for any credentials that may have been AI-generated. Rotate them regardless of apparent strength.

• Add explicit policy to your AI usage guidelines: LLMs must not be used for password, secret, or cryptographic key generation. Use dedicated cryptographic random number generators or password managers with CSPRNG backends.

• Add detection to your code review process for hardcoded credentials. The presence of secrets in code is a separate problem, but AI-generated secrets in code are doubly dangerous.

Rock’s Musings

This one is going to sting because it’s been happening quietly for three years. Every developer who ever typed “give me a strong password” into ChatGPT and copy-pasted the result into a config file or API key field created a predictable credential. The entropy numbers here are damning: 27 bits versus 98. That’s a category error. The model isn’t generating randomness. It’s predicting what a password looks like, which is the exact opposite of what you need.

The vibe coding angle makes this worse. Teams building rapidly with AI assistance are shipping AI-generated credentials into production at a rate that’s probably not tracked anywhere in your CMDB. This isn’t a training problem you can solve with a webinar. It requires a tooling change and an audit of anything AI-assisted from the last two years. Start there.

6. India Launches Global AI Summit, Shifting the Governance Conversation from Safety to Impact

The India AI Impact Summit opened February 19-20, 2026 in New Delhi, with Prime Minister Narendra Modi hosting the fifth in the series of global AI summits following the UK, France, Korea, and Rwanda iterations (Crowell & Moring, techUK). India deliberately reframed the summit theme away from “safety” and “action” toward “impact,” signaling a strategic preference for deployment-focused governance over precautionary frameworks. The summit brings together governments representing over 30 nations, private sector leaders from startups to multinationals, and is expected to shape India’s domestic AI regulatory approach. India highlighted four domestic startups building open-source foundational AI models tailored to local languages: Sarvam AI, Soket AI, Gnani AI, and Gan AI. The International AI Safety Report 2026, published February 3 and authored by over 100 experts across 30 countries, provides the independent scientific baseline for the governance conversations happening at the summit.

Why it matters

• The shift from “safety” to “impact” framing at a summit representing one billion users rebalances global AI governance pressure toward deployment and away from precaution. This affects how multinational enterprises navigate cross-border AI risk.

• India’s regulatory landscape for AI is still forming. Summit outcomes will directly shape what obligations enterprises face in one of the world’s largest and fastest-growing technology markets.

• The Global South’s increasing voice in AI governance means compliance strategies built entirely around EU AI Act timelines or U.S. executive order directions are increasingly incomplete.

What to do about it

• Expand your AI regulatory horizon map to include India explicitly. If you operate in the Indian market or source AI talent and infrastructure there, this summit’s outputs will produce compliance obligations.

• Monitor the parallel EU AI Act timeline shifts. The European Commission is considering moving high-risk AI system obligations from August 2026 to December 2027. That extension affects your deployment planning.

• Brief your board on the diverging international governance frameworks. AI risk is no longer a single regulatory question. It’s a multi-jurisdictional portfolio problem.

Rock’s Musings

The rebranding from “safety summit” to “impact summit” is doing more work than it appears. It’s India saying, loud and clearly, that the safety-first framing from the UK and EU rounds is not the only valid frame. For the Global South, AI’s upside is too large to subordinate to risk frameworks designed primarily by wealthy nations with different exposure profiles. That’s a legitimate position, and it creates governance fragmentation that multinational enterprises will have to navigate without clean guidance.

From a security practitioner standpoint, what I watch at these summits isn’t the keynotes but the working groups. The incident reporting requirements, the transparency obligations for AI developers, and the cross-border data flow rules are where the actual compliance burden lives. The International AI Safety Report 2026 laid out a solid scientific baseline for what risks are real and what risk management practices actually work. Whether any of these summits produces enforceable governance is a different question entirely.

7. DHS Announces CIRCIA Virtual Town Halls, Bringing Mandatory Incident Reporting Closer to Reality

On February 13, 2026, the U.S. Department of Homeland Security announced virtual town hall meetings scheduled for March 2026 on the implementation of the Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA) (Crowell & Moring). CIRCIA mandates covered entities to report substantial cyber incidents to CISA within 72 hours and ransomware payments within 24 hours. The town halls signal that CISA is moving toward final rulemaking, which will define exactly which organizations qualify as covered critical infrastructure and what “substantial” means in practice. The upcoming rules will affect sectors including healthcare, finance, transportation, energy, and communications. This is directly relevant to AI security because AI systems deployed in critical infrastructure pipelines will fall within CIRCIA’s scope once the covered entity definitions are finalized.

Why it matters

• If your organization operates in or supplies critical infrastructure sectors, CIRCIA reporting obligations are coming. The town halls are your signal to get your incident response playbooks in order now, not when the rule is final.

• AI-related incidents involving critical infrastructure components will carry mandatory reporting obligations. Your incident classification framework needs to account for AI system failures as a triggering event.

• The 72-hour reporting window is unforgiving. Organizations without pre-defined internal notification chains, executive decision authority, and external counsel relationships will fail to meet it.

What to do about it

• Participate in the March CIRCIA town halls or send your legal and compliance teams. The comment period is the last opportunity to influence what “substantial incident” means before it becomes binding.

• Map your AI deployments against critical infrastructure definitions. If an AI system supports operational continuity in a covered sector, assume it is a reportable asset.

• Conduct a tabletop exercise specifically for the 72-hour CIRCIA timeline. The failure mode is not usually lack of knowledge; it’s lack of pre-authorized decision-making when leadership is unavailable at 2 a.m.

Rock’s Musings

CIRCIA has been in rulemaking purgatory for years, and the town halls are the clearest signal yet that the administration intends to finalize it. What’s notable from an AI security angle is that the statute was written before enterprise AI deployments at scale were reality. The final rule needs to address what happens when an AI system operating in a critical infrastructure pipeline is the vehicle for a substantial cyber incident. Right now, that’s ambiguous.

The practical guidance I’d give: don’t wait for regulatory clarity before building your incident response muscle. If an AI agent with access to operational technology fails catastrophically, you need the same 72-hour reporting capability you’d need for a ransomware attack. Those muscles take time to build. The town halls are the starting gun, not the finish line.

8. 300 Million AI Chat Messages Exposed in Firebase Misconfiguration

A security researcher discovered an exposed database belonging to the Chat and Ask AI application, operated by developer Codeway, exposing approximately 300 million messages tied to 25 million users (Malwarebytes). The exposure traced back to a Firebase misconfiguration, a well-documented error class where Google Firebase Security Rules are set to public, allowing anyone with the project URL to read, modify, or delete data without authentication. The exposed data included complete chat histories, AI model configurations, and user settings. The researcher, named Harry, found the issue while building an automated scanning tool for iOS and Android apps and discovered 103 of 200 iOS apps tested had the same vulnerability class. Codeway resolved the issue across all its apps within hours of responsible disclosure. Harry set up a public registry called Firehound where users can check whether apps they use have exposed this flaw.

Why it matters

• 300 million chat messages include everything users ever said to an AI assistant: medical questions, financial details, relationship problems, confidential business discussions. That data is permanently exposed once leaked, regardless of remediation.

• The systematic nature of this vulnerability class means Codeway is not the exception. Seventeen percent of iOS apps in Harry’s initial scan had the same misconfiguration.

• AI applications collecting sensitive conversational data without adequate backend security controls are a rapidly growing liability category that most enterprise third-party risk programs are not yet equipped to assess.

What to do about it

• Audit your enterprise mobile app allowlist for AI applications that may store conversational data in Firebase or similar backend-as-a-service platforms. Request evidence of backend security controls as part of vendor assessment.

• Advise employees against using consumer AI chat applications for business discussions. The security controls on consumer apps are not equivalent to enterprise SaaS, and the conversational data those apps collect is a legitimate exfiltration target.

• Check whether any apps your organization uses appear in Harry’s Firehound registry at firehound.app.

Rock’s Musings

The fact that a security researcher had to build an automated scanner to find this at scale tells you that the industry has not treated AI application backend security as a systematic concern. Firebase misconfigurations are not exotic vulnerabilities. They’re configuration errors that developers make when they prioritize shipping over hardening. When those developers are building AI applications that store millions of sensitive conversations, the exposure radius is enormous.

I want to flag the third-party risk angle for enterprise security leaders. Your employees are using AI chat applications for work conversations whether you’ve blessed those tools or not. The question is whether your vendor risk program knows what backend infrastructure those applications run on and whether those backends have been assessed. Most programs don’t, and 300 million exposed messages is the cost of that gap.

9. Taiwan Warns China Is Rehearsing a Digital Siege

On February 13, 2026, Taiwan issued a warning that China may be rehearsing a “digital siege” targeting the island’s critical communications and infrastructure (The Record from Recorded Future News). Taiwan’s National Security Bureau assessed that Chinese state actors are probing submarine cable systems, satellite communication dependencies, and undersea internet infrastructure in patterns consistent with pre-conflict preparation. The warning follows years of documented Chinese cyber operations against Taiwanese government agencies, financial institutions, and defense contractors. AI tools are increasingly part of Chinese state-sponsored reconnaissance and operational planning, as the Google GTIG report published the same week documented. The digital siege scenario involves coordinated disruption of communications infrastructure to isolate Taiwan before or during a conventional military operation.

Why it matters

• The digital siege model does not require a military conflict to be relevant to enterprise security. The same techniques used to rehearse the isolation of Taiwan’s infrastructure apply to attacking submarine cables, satellite uplinks, and internet exchange points globally.

• Multinational enterprises with operations or supply chain dependencies in Taiwan face a material business continuity risk that most BCP plans do not adequately address.

• AI-assisted reconnaissance at the infrastructure level represents a qualitative shift in how state actors prepare for large-scale operations.

What to do about it

• Include Taiwan-specific disruption scenarios in your business continuity planning if you have operations or significant supplier relationships in Taiwan. The realistic scenario is degraded communications, not a clean cutover.

• Map your organization’s dependence on Taiwan-based semiconductor and manufacturing supply chains. The disruption scenario is the subject of active adversary preparation.

• Brief your board on the geopolitical exposure your organization carries in the Taiwan Strait scenario. This belongs in your enterprise risk register alongside financial and operational risks.

Rock’s Musings

Taiwan produces the advanced chips that run your AI infrastructure. Any serious disruption to Taiwan’s communications or manufacturing capacity disrupts global AI supply chains in ways that dwarf any single cyberattack. China knows this. Their state actors are mapping the dependencies precisely because disrupting them at the right moment creates leverage that kinetic operations alone cannot.

The AI security angle that gets missed in most coverage is that Chinese APT groups are using AI tools, including Gemini as documented this week, to accelerate exactly the kind of infrastructure reconnaissance that underpins a digital siege strategy. Faster, more precise OSINT on submarine cable routing, satellite uplink dependencies, and internet exchange peering relationships means better targeting when the time comes. The rehearsal is happening now. Whether enterprises are watching is a different question.

10. OpenClaw CVE-2026-25253 Docker Sandbox Bypass Leaves Persistent Exposure

Security researchers at Depthfirst and Snyk confirmed during the week of February 13 that the original patch for CVE-2026-25253, OpenClaw’s one-click RCE vulnerability, was incomplete (SecurityWeek, Barrack.ai). The Docker sandbox bypass was assigned its own CVE, CVE-2026-24763, and patched in OpenClaw version 2026.1.30. The initial vulnerability allowed a victim who visited a malicious web page to have their authentication token stolen and their OpenClaw gateway compromised for full remote code execution. With 179,000 GitHub stars and 720,000 weekly downloads, the number of vulnerable deployments is substantial, particularly given that many users run OpenClaw on dedicated always-on machines with broad system access. Belgium’s Centre for Cybersecurity issued an emergency advisory urging immediate patching. As of February 19, SecurityWeek confirmed no known unfixed CVEs in the latest version 2026.2.17 but noted a large installed base of older versions remained in production.

Why it matters

• The incomplete initial patch is a recurring pattern. Security teams that patched to 2026.1.29, believing they were protected, were not. Patch validation for complex systems requires verifying the specific vulnerability class, not just the version number.

• Always-on AI agent deployments on dedicated hardware create persistent high-value targets. A machine running OpenClaw continuously, with access to email, shell, and connected services, is a significant lateral movement asset if compromised.

• Belgium’s emergency advisory signals that national cybersecurity agencies are treating OpenClaw’s exposure as a critical infrastructure-level risk, not just a developer tool problem.

What to do about it

• Verify OpenClaw deployments are running version 2026.2.17 or later. Version 2026.1.29 is not fully patched. Confirm the specific CVEs are addressed in your version before closing the finding.

• Isolate OpenClaw agent deployments from your corporate network with explicit firewall rules. An agent that can only reach the services it legitimately needs has a dramatically smaller blast radius than one with unrestricted internal access.

• Treat the SecureClaw open-source hardening tool as a baseline requirement before any production OpenClaw deployment. Fifty-five automated audit checks mapped to MITRE ATLAS is a reasonable starting point, not an optional addition.

Rock’s Musings

The incomplete patch disclosure on a CVSS 8.8 one-click RCE is the kind of thing that turns a bad week into a worse one for security teams who thought they’d handled it. The version number said patched. The actual vulnerability class said otherwise. This is why patch validation procedures need to go beyond version confirmation, particularly for products with multiple CVEs being patched in rapid succession over a short period.

What concerns me more than any individual CVE here is the deployment pattern. People are running OpenClaw on Mac minis in their homes and offices as always-on AI assistants with full access to their personal and professional digital lives. The security model for that use case does not exist. The threat model has not been written. The incident response plan if the agent is compromised has definitely not been tested. That’s the real story underneath all of these CVEs.

The One Thing You Won’t Hear About But You Need To

Check Point Reveals AI Assistants Can Be Weaponized as Bidirectional C2 Proxy Channels

Check Point researchers disclosed on February 18, 2026 that AI assistants with web-browsing capabilities, specifically Microsoft Copilot and xAI’s Grok, can be turned into bidirectional command-and-control proxy channels by malware (AI Security Daily Briefing, February 18, 2026). The technique works by sending malware-controlled “summarization prompts” to attacker-controlled URLs via the AI assistant’s browser. The assistant fetches the URL, interprets attacker commands embedded in the page content, and returns data, effectively acting as a cleansing layer that makes malicious C2 traffic appear as legitimate HTTPS connections to AI provider domains. From a network monitoring perspective, the traffic looks like normal Copilot or Grok activity. Standard network security tools that whitelist major AI provider domains, as many enterprise configurations do, pass this traffic without inspection.

Why it matters

• Every enterprise that has whitelisted Copilot, Grok, or similar AI assistant domains in its network security stack has created a potential bypass channel for malware C2 communications.

• The attack does not require exploiting the AI system itself. It exploits the trust that network controls extend to AI provider domains by default.

• AI assistants with browsing capabilities are increasingly standard enterprise tools. The attack surface grows with every deployment.

What to do about it

• Audit your network security configurations for blanket whitelisting of AI provider domains. Traffic to Copilot, Grok, ChatGPT, or similar services should be inspectable, not exempt from inspection.

• Monitor for high-frequency, low-volume browsing requests from AI agents to newly registered or unusual domains. The attack pattern requires the agent to browse attacker-controlled content regularly.

• Require explicit approval and network segmentation for any AI assistant deployment with web-browsing capabilities. The browsing feature specifically is what creates the C2 channel.

Rock’s Musings

This one deserves more attention than it’s getting. The attack is technically simple but operationally brilliant. You’ve trained your security team to look for C2 traffic going to suspicious domains. The traffic to Microsoft Copilot’s endpoints is not suspicious. It’s expected. Now those expected connections are the C2 channel. Your detection model just broke.

The enterprise AI deployment pattern that created this exposure is the same one most organizations followed: enabled Copilot or a similar tool, added the provider to the network allowlist so it functions properly, moved on to the next project. Nobody asked what happens if someone uses that trusted channel in reverse. Check out the rockcybermusings.com archive for more on how AI assistant deployments are changing your threat model, and visit rockcyber.com if you need help working through what your current AI deployment means for your detection stack.

If you found this analysis useful, subscribe at rockcybermusings.com for weekly intelligence on AI security developments.

👉 Visit RockCyber.com to learn more about how we can help you in your traditional Cybersecurity and AI Security and Governance Journey

👉 Want to save a quick $100K? Check out our AI Governance Tools at AIGovernanceToolkit.com

👉 Subscribe for more AI and cyber insights with the occasional rant.

Share RockCyber Musings

References

Anadolu Agency. (2026, February 19). Experts warn AI-generated passwords may expose users to security risks. https://www.aa.com.tr/en/science-technology/experts-warn-ai-generated-passwords-may-expose-users-to-security-risks/3834887

Antiy CERT. (2026, February 19). ClawHavoc poisons OpenClaw’s ClawHub with 1,184 malicious skills. GBHackers. https://gbhackers.com/clawhavoc-infects-openclaws-clawhub/

Aryaka. (2026, February 18). Securing OpenClaw agents from ClawHavoc supply-chain attacks with AI-driven protection. https://www.aryaka.com/blog/securing-openclaw-agents-clawhavoc-supply-chain-attack-ai-secure-protection/

Barrack.ai. (2026, February 16). OpenClaw is a security nightmare: Here’s the safe way to run it. https://blog.barrack.ai/openclaw-security-vulnerabilities-2026/

CISA. (2026, February 13). CVE-2026-1731 added to Known Exploited Vulnerabilities catalog. https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Conscia. (2026, February). The OpenClaw security crisis. https://conscia.com/blog/the-openclaw-security-crisis/

Crowell & Moring LLP. (2026, February). Setting the agenda for global AI governance: India to host AI Impact Summit in February 2026. https://www.crowell.com/en/insights/client-alerts/Setting-the-Agenda-for-Global-AI-Governance-India-to-Host-AI-Impact-Summit-in-February-2026

Dewhurst, R. (2026, February 12). [Post on X confirming in-the-wild exploitation of CVE-2026-1731]. watchTowr. Referenced via Help Net Security: https://www.helpnetsecurity.com/2026/02/13/beyondtrust-cve-2026-1731-poc-exploit-activity/

eSecurity Planet. (2026, February). Hundreds of malicious skills found in OpenClaw’s ClawHub. https://www.esecurityplanet.com/threats/hundreds-of-malicious-skills-found-in-openclaws-clawhub/

Google Threat Intelligence Group. (2026, February 12). Nation-state hackers using Gemini AI for recon and attack support. Referenced via BleepingComputer: https://www.bleepingcomputer.com/news/security/google-says-hackers-are-abusing-gemini-ai-for-all-attacks-stages/

Google Threat Intelligence Group. (2026, February 12). State-backed hackers exploit Gemini AI for cyber recon and attacks. Security Affairs. https://securityaffairs.com/187958/ai/google-state-backed-hackers-exploit-gemini-ai-for-cyber-recon-and-attacks.html

Help Net Security. (2026, February 13). Hackers probe, exploit newly patched BeyondTrust RCE flaw (CVE-2026-1731). https://www.helpnetsecurity.com/2026/02/13/beyondtrust-cve-2026-1731-poc-exploit-activity/

Irregular. (2026, February 18). LLM-generated passwords fundamentally weak. The Register. https://www.theregister.com/2026/02/18/generating_passwords_with_llms

Malwarebytes. (2026, February 19). AI-generated passwords are a security risk. https://www.malwarebytes.com/blog/news/2026/02/ai-generated-passwords-are-a-security-risk

Malwarebytes. (2026, February). AI chat app leak exposes 300 million messages tied to 25 million users. https://www.malwarebytes.com/blog/news/2026/02/ai-chat-app-leak-exposes-300-million-messages-tied-to-25-million-users

Orca Security. (2026, February). Critical CVE-2026-1731 vulnerability in BeyondTrust Remote Support and PRA. https://orca.security/resources/blog/cve-2026-1731-beyondtrust-vulnerability/

Paubox. (2026, February 19). State-sponsored hackers are using AI at every stage of cyberattacks. https://www.paubox.com/blog/state-sponsored-hackers-are-using-ai-at-every-stage-of-cyberattacks

Rapid7. (2026, February). CVE-2026-1731: Critical unauthenticated RCE in BeyondTrust Remote Support and PRA. https://www.rapid7.com/blog/post/etr-cve-2026-1731-critical-unauthenticated-remote-code-execution-rce-beyondtrust-remote-support-rs-privileged-remote-access-pra/

SC Media. (2026, February 19). Massive OpenClaw supply chain attack floods ClawHub with malicious skills. https://www.scworld.com/brief/massive-openclaw-supply-chain-attack-floods-openclaw-with-malicious-skills

SecurityWeek. (2026, February 19). OpenClaw security issues continue as SecureClaw open source tool debuts. https://www.securityweek.com/openclaw-security-issues-continue-as-secureclaw-open-source-tool-debuts/

StepSecurity. (2026, February 17). Cline supply chain attack detected: cline@2.3.0 silently installs OpenClaw. https://www.stepsecurity.io/blog/cline-supply-chain-attack-detected-cline-2-3-0-silently-installs-openclaw

techmaniacs.com. (2026, February 18). AI security daily briefing: February 18, 2026. https://techmaniacs.com/2026/02/18/ai-security-daily-briefing-february-18-2026/

techUK. (2026, February). The release of the International AI Safety Report 2026. https://www.techuk.org/resource/the-release-of-the-international-ai-safety-report-2026-navigating-rapid-ai-advancement-and-emerging-risks.html

The Record from Recorded Future News. (2026, February 13). China may be rehearsing a digital siege, Taiwan warns. https://therecord.media/china-may-be-rehearsing-digital-siege-taiwan-warns

TechSpot. (2026, February 19). AI-generated passwords are surprisingly easy to crack, researchers find. https://www.techspot.com/news/111392-ai-generated-passwords-surprisingly-easy-crack-researchers-find.html

The Hacker News. (2026, February 12). Google reports state-backed hackers using Gemini AI for recon and attack support. https://thehackernews.com/2026/02/google-reports-state-backed-hackers.html

Share

Let me save you six months of hand-wringing. You’ve been protecting the wrong door.

I’ve sat through more AI governance meetings than I care to count. Every single one features the same theatrical performance. Legal waves GDPR Article 17 around like a talisman. Procurement demands “no training on our data” clauses with the fervor of medieval peasants warding off vampires. And everyone nods sagely, convinced they’ve addressed the AI risk problem.

Meanwhile, Lasso Security research shows 13% of employee prompts to GenAI chatbots contain sensitive data. Not training datasets. Prompts. Every day. Right now. While you’re reading this, someone in your organization is probably pasting customer PII into ChatGPT because they need help formatting a spreadsheet.

The mathematics of where your data actually leaks should embarrass every security team that spent the last two years obsessing over training data extraction. But it won’t. Because we love our comfortable narratives more than uncomfortable evidence.

The LLM Data Lifecycle: What You Should Have Learned Before That Vendor Demo

Here’s something that drives me up the wall. Security professionals confidently opine about LLM risks without understanding the basic mechanics of how these systems work. They conflate training with inference because no one ever walked them through the machine learning operations pipeline. So let me do that now, since apparently your AI vendors were too busy selling you governance platforms to explain the fundamentals.

The pipeline divides into two distinct phases with fundamentally different data exposure mechanisms. Understanding this split determines whether your security controls make sense or constitute expensive window dressing.

Training Phase: Where Data Gets Baked Into Weights

Data Collection and Curation happens before anyone touches a model. Someone has to assemble the training corpus. For frontier models, this means scraping the public internet, licensing book datasets, acquiring code repositories, and purchasing proprietary content. Your data enters the pipeline here. If a vendor trained on data that included your documents, this is where the exposure occurred. The curation process involves deduplication, filtering, and quality assessment. Data that survives curation proceeds to training. Data that doesn’t get discarded. But “discarded” in ML pipelines doesn’t mean “securely deleted.” It means “not used for this training run.”

Pretraining is where the paranoia lives. Models consume massive datasets; we’re talking trillions of tokens scraped from the digital detritus of human civilization. GPT-2 trained on 40GB of text. GPT-3 scaled to 570GB. Modern frontier models ingest petabytes. Your data, if it enters here, gets compressed via gradient descent optimization across billions of parameters. The model adjusts its weights to minimize prediction error. Your sensitive document becomes a statistical ghost, distributed across a neural network in ways that make traditional data governance frameworks weep.

This is where the “don’t train on my data” clause comes from. I get it… the intuition makes sense. If my data trains the model, the model might regurgitate my data. Logic checks out, but it’s mostly flawed.

Supervised Fine-Tuning narrows the model’s behavior after pretraining. This stage uses curated instruction-response pairs to teach the model how to follow directions. The datasets are smaller, thousands to millions of examples, versus trillions of pretraining tokens. However, memorization risk actually increases here because the same examples often appear multiple times during training. If your data appears in fine-tuning datasets, extraction probability rises substantially compared to pretraining exposure.

Preference Alignment shapes responses to match human expectations. Reinforcement Learning from Human Feedback, Direct Preference Optimization, Constitutional AI, pick your flavor. Human raters compare model outputs, and the training process adjusts weights accordingly. The data here includes both prompts and human preference signals. Less raw text, but still potential exposure if your content appeared in alignment examples.

Evaluation and Red-Teaming happen after training completes but before deployment. This is adversarial testing to find failure modes, safety issues, and capability gaps. It is not simply validation during training. Red teams probe for jailbreaks, harmful outputs, and yes, training data extraction. If your data appears in both training and evaluation sets, congratulations. You have a contamination problem that nobody in procurement thought to ask about.

Inference Phase: Where Data Flows Through (And Gets Logged)

Model Deployment means containerizing the trained model, spinning up API infrastructure, configuring scaling policies, and connecting authentication systems. The model weights are frozen. No learning happens. But this phase determines how data will flow through the system and, critically, where it will be stored.

Real-Time Inference is where users actually interact. Every prompt submitted. Every response received. The model processes inputs, generates outputs, and moves on. This is what most people picture when they think about using AI. What they don’t picture is everything that happens around inference.

RAG and Context Injection deserve their own callout because most organizations miss them entirely. Retrieval-Augmented Generation means your inference pipeline queries external databases, pulls relevant documents, and injects that content into prompts before sending them to the model. Those “external databases” often contain your proprietary documents, customer records, internal wikis, and knowledge bases.

Here’s what that means for data exposure. When Karen in accounting asks the AI chatbot about expense policy, the RAG system retrieves your expense policy document, injects it into the prompt, sends the combined content to the model, receives a response, and logs the entire transaction. Your proprietary document just flowed through an external API, got combined with user prompts, and landed in a logging system you may not control. No training required. No memorization needed. Direct exposure through the inference pipeline you deployed to be helpful.

Logging and Monitoring is where inference data exposure actually occurs. Production systems log prompts and responses for debugging, abuse detection, quality assurance, and compliance. Those logs contain everything users submitted. Every customer name. Every financial figure. Every code snippet. Every piece of sensitive data that employees paste into the helpful AI assistant.

The 13% figure from Lasso Security? That’s the percentage of prompts containing sensitive data. Those prompts get logged. Stored. Often retained far longer than necessary. Sometimes shared with vendors for “product improvement.” This is the front door standing wide open while everyone obsesses over vault security.

The distinction between training and inference exposure matters because the technical mechanisms differ fundamentally. Training memorization requires your data to survive gradient compression across billions of parameters and then be extractable via adversarial prompting. Inference exposure requires only that employees type sensitive information into text boxes and that someone, somewhere, logs the transaction.

Guess which one happens more often.

How Memorization Actually Works: The Math Your Vendor Didn’t Show You

Let me walk you through what happens when your data enters a training corpus. Researchers have quantified exactly how much training data can be extracted from production models, and the numbers don’t support the panic.

Nicholas Carlini and colleagues at Google developed the formal framework that everyone cites, but few have actually read. A string is extractable with $k$ tokens of context from a model if an adversary can prompt the model with a prefix and recover the exact training sequence.

The empirical results should recalibrate your threat model. From GPT-2’s 40GB training set, researchers extracted exactly 604 unique examples. Let me write that as a percentage so it sinks in:

Six hundred four examples from forty billion characters. That’s the threat model you’ve been losing sleep over.

But I’m not going to cherry-pick. Extraction rates depend heavily on attack sophistication. The divergence attack against ChatGPT caused the model to emit memorized training data at 150x the normal rate by prompting the model to repeat a single word indefinitely until it diverged from its aligned behavior. Even with that adversarial technique, only 3% of generated text was memorized content.

The relationship between model scale and memorization follows a log-linear pattern that Carlini’s team quantified:

Where C is a constant dependent on training configuration. This means a 10x increase in model size yields roughly a 19 percentage-point higher extraction rate. Larger models memorize more. The 175B parameter GPT-3 memorizes more than the 1.5B parameter GPT-2. This is real. This matters.

Three factors dominate whether your specific data gets memorized, and understanding these should inform your actual risk assessment rather than your vendor-driven anxiety:

Data duplication is the killer. GPT-2 memorized sequences after just 33 repetitions. The relationship is exponential:

Where…

… varies by model architecture (sorry, Substack doesn’t let me shrink a LaTex block so it fits in line). A 10x increase in repetitions yields extraction rates 25-30 percentage points higher. If your sensitive data appears once in a training corpus of trillions of tokens, your extraction risk approaches zero. If it appears hundreds of times across multiple sources, you have a real problem.

Model scale amplifies everything. Larger models memorize 2-5x more than smaller counterparts. The 6B parameter GPT-Neo extracted 65% of test sequences, compared with 20% for the 125M version. The relationship holds across architectures.

Training dynamics create temporal windows. Models exhibit the highest memorization at the beginning and end of training, with the lowest rates midway through. Early-memorized examples become permanently encoded in lower layers. This has implications for when your data entered the training pipeline, but good luck getting that information from any vendor.

Membership Inference Attacks: A Coin Flip with Extra Steps

Here’s where I get genuinely irritated. Membership inference attacks attempt to determine whether specific data was used in training. These attacks should terrify privacy professionals if they worked.

They don’t work.

State-of-the-art research demonstrates that MIAs barely outperform random guessing for most settings across varying LLM sizes and domains. The best attacks achieve Area Under the Receiver Operating Characteristic Curve (AUC-ROC) scores of 0.50-0.55. For those who skipped statistics class, 0.50 equals flipping a coin.

That’s a 0.05 improvement over pure chance. You’d get better results asking a magic 8-ball.

Why do MIAs fail against LLMs? Two reasons, and both should have been obvious.

First, modern LLMs train on massive datasets for very few epochs. GPT-3-class models see each example maybe once or twice during training. This creates minimal overfitting on individual examples. Without overfitting, the statistical signal that MIAs exploit simply doesn’t exist. The model treats seen and unseen data nearly identically.

Second, the boundary between training and non-training data is fundamentally fuzzy for natural language. Text from the same domain exhibits similar statistical characteristics whether it appeared in training or not. A legal contract looks like a legal contract. Distinguishing membership becomes statistically impossible because the underlying distributions overlap almost completely.

Difficulty calibration techniques can improve MIA performance by up to 0.10 AUC. Even optimized attacks show limited practical utility for large-scale privacy breaches. You cannot reliably determine if your data was in the training set. Full stop.

So why do vendors keep selling you tools to detect training data inclusion? Because fear sells better than evidence.

The Real Threat: What’s Actually Happening While You’re Guarding the Vault

Now let’s examine what actually happens in organizations that deploy LLMs. The Samsung incident from 2023 became the canonical case study, but most coverage missed the point entirely.

Three Samsung semiconductor engineers pasted proprietary code and meeting transcripts into ChatGPT over a 20-day period. One entered buggy source code from a semiconductor database seeking debugging help. Another uploaded program code designed to identify defective equipment for optimization suggestions. A third converted confidential meeting notes into a presentation.

I need you to understand something critical: This was not a training data extraction attack.

Zero adversarial techniques. No sophisticated prompting. No cryptographic attacks on model weights. Engineers simply pasted confidential data into a text box because they wanted help with their jobs, and the AI was right there, waiting and ready to help.

Samsung’s response tells you what they actually learned. They banned public AI tools and implemented a 1,024-byte upload limit. They didn’t hire a team to monitor the extraction of training data. They recognized the threat as operational, not theoretical.

Lasso Security’s analysis of real-world GenAI usage quantified what anyone paying attention already suspected. Their findings, based on data collected between December 2023 and February 2025:

13% of employee prompts contain sensitive data. That’s the baseline exposure rate. No attack required. No adversary needed. Just normal people using AI tools the way normal people use AI tools.

Category breakdown reveals the scope of what’s flowing through inference endpoints:

• Code and tokens (API keys, credentials): 30% of sensitive submissions

• Network information (IPs, MACs, internal URLs): 38% of sensitive submissions

• PII/PCI data (emails, payment information): 11.2% of sensitive submissions

The 2025 IBM Cost of a Data Breach Report found 13% of organizations reported AI-related breaches. Of those breached, 97% lacked proper AI access controls. Not 97% lacked training data extraction monitoring. Ninety-seven percent lacked basic access controls for inference endpoints.

The Probability-Weighted Risk Calculation You Should Have Done Two Years Ago

Let me show you the math that should change your budget allocation. This is basic risk quantification. The kind of analysis you’d do for any other security domain. But somehow AI got a pass on quantitative rigor.

Risk = Likelihood × Severity

CISSP 101

For training data extraction:

Where:

• Risk Score: Low to Medium

For inference data exposure:

Where:

• Risk Score: High to Critical

The risk ratio tells the story:

Even comparing against sophisticated adversarial extraction at 3%, inference risk remains over 4x higher. Against baseline extraction rates, inference exposure presents nearly a million times higher probability. And inference exposure requires zero technical sophistication. It requires only that employees do their jobs using the tools you’ve given them.

Does your security budget allocation reflect this ratio? If not, you’re defending based on narrative rather than evidence.

Control Efficacy: Why You Can Fix Inference But Not Training

The asymmetry extends beyond probability to controllability, and this is where the grumpy uncle in me really wants to shake some sense into the industry.

Inference controls are mature, proven, and cost-effective:

Zero-retention contracts exist. OpenAI’s API offers enterprise customers explicit no-data-retention options. Azure OpenAI provides stateless inference with double encryption. AWS Bedrock offers similar guarantees. You can contractually eliminate inference data retention today. The cost ranges from $0 (API configuration) to $50K (enterprise agreement negotiation).

Traditional DLP integration doesn’t work. Your existing stack watches file transfers and email attachments. Prompts are ephemeral text in encrypted API calls that legacy DLP never sees. What works is AI-native guardrails. Input validation that scans prompts before the model processes them. Output filtering that inspects responses before users receive them. These aren’t DLP products with “AI” slapped on the label. They’re purpose-built controls that understand prompt structure, embedding semantics, and conversational context. Cost: $50K-200K one-time plus annual licensing. Deployment time: weeks to months. Efficacy: 95%+ detection of sensitive data patterns when properly tuned.

Targeted prompt hygiene coaching changes behavior. Not a 45-minute module. Three rules, live examples, quarterly reinforcement. $10K-50K annually. ROI shows up in your logs within quarters.

Private deployment eliminates external data flow entirely. Run the model in your VPC. Air-gap if you’re paranoid. Cost: $100K-millions depending on scale. Efficacy: 100% against external exposure.

Total efficacy for inference controls: 100% risk reduction achievable. GDPR compliant. ISO 42001 auditable. HIPAA addressable. These are solved problems.

Training controls remain experimental and break your models:

Differential privacy provides mathematical guarantees that sound great in papers. The practical reality? Research shows 36% accuracy degradation for meaningful privacy protection at ε=10 (where lower epsilon means better privacy but worse model performance)

Training overhead increases 2-3x in compute cost. You’re paying more for a worse model that might protect against a threat that’s already unlikely.

Machine unlearning “significantly degrades model utility” and “scales poorly with forget set sizes.” Direct quote from the research literature. No vendor will tell you this because they’re selling you unlearning solutions.

Retraining from scratch costs $1M-10M per GPT-3-class training run. For 1,000 GDPR erasure requests per year (a modest estimate for any company with European customers), full compliance through retraining would cost:

That’s not a typo. Five billion dollars annually for GDPR training data compliance. The EU AI Act acknowledges this reality with careful language: “Once personal data is used to train AI model, deletion may not be possible.”

For inference logs? You delete them from the database. Query complete. Compliance achieved. Cost: approximately nothing.

Where Security Budgets Should Actually Go

The evidence demands a resource reallocation that most CISOs haven’t made because they’re still managing to the narrative rather than the data.

I don’t have a survey that breaks down AI security spending by lifecycle phase. Nobody does. That research gap tells you something about where the industry’s head is at. We’re still debating whether training data extraction is a real threat, while 13% of employees paste sensitive data into GenAI tools every day.

Here’s what I see in practice: security teams obsess over model security, training data provenance, and adversarial attacks that require nation-state capabilities to execute. Meanwhile, inference-time data governance gets a fraction of the attention despite representing the overwhelming majority of actual data exposure.

This allocation is backwards. It’s like spending most of your physical security budget on vault doors while leaving the loading dock propped open.

The fix isn’t complicated. Shift focus from theoretical training-time attacks to the inference-time exposures happening right now:

Inference data governance comes first. Forget legacy DLP. It watches the perimeter while your data evaporates into prompts. You need prompt guardrails that scan input for sensitive patterns before processing, output filters that inspect model responses for data leakage, and audit logging for every AI interaction. Implement zero-retention contracts with every AI vendor. The UK NCSC calls this “radical transparency” for a reason.

Prompt hygiene training changes behavior. This isn’t another awareness program destined for the ignore pile. Prompt hygiene is a discrete skill with immediate feedback. Three rules, live examples from your own environment, quarterly reinforcement. $10K-50K annually. Behavior changes because employees see the flags in real time, not because they clicked through a module.

Shadow AI visibility is non-negotiable. You can’t govern what you can’t see. Inventory every AI tool touching your environment, sanctioned or not.

Training data monitoring is maintenance, not a priority. Keep the controls you have. Don’t expand investment here until you’ve closed the inference gaps.

Your legal team negotiated “no training” clauses because they understood GDPR Article 17 implications. That was appropriate due diligence. But that clause doesn’t protect you from the engineer who pastes customer data into ChatGPT tomorrow morning because their deadline is today and the AI is helpful.

The vault door is secure. Your “no training” clause is airtight. Meanwhile, 13% of your workforce submits sensitive data through the front door every single day, and you’re congratulating yourself on your AI governance program.

I’ve been doing this long enough to know that most readers will nod along, agree with the analysis, and change nothing. The narrative is comfortable. The vendor demos are compelling. The boardroom expects training data extraction theater.

But for those of you willing to follow the evidence: your data leaks at inference. Fix that first. Fix that now. The training data extraction problem is real but rare. The inference exposure problem is certain and ongoing.

Key Takeaway: Training data extraction is a lottery you probably won’t lose. Inference data exposure is a certainty you’re experiencing right now. Stop guarding the vault and secure the front door.

What to do next

Your AI governance posture needs an honest assessment, not another vendor demo. The CARE Framework provides a structured approach to evaluating AI risk across the dimensions that actually matter. Use it to audit where your current controls focus versus where the evidence says your risks concentrate.

If your organization needs an external perspective - someone willing to tell you what your vendors won’t - RockCyber offers AI governance assessments built on the quantitative analysis in this post. We’ll tell you where your budget should go, not where your current vendors want it to go.

👉 Subscribe for more AI security and governance insights with the occasional rant.

👉 Visit RockCyber.com to learn more about how we can help you in your traditional Cybersecurity and AI Security and Governance Journey

👉 Want to save a quick $100K? Check out our AI Governance Tools at AIGovernanceToolkit.com

Share RockCyber Musings

Your AI coding assistant can now be weaponized through a poisoned codebase. This week gave us the first actively exploited prompt injection vulnerabilities in GitHub Copilot, a North Korean crew running deepfake Zoom calls to rob crypto firms, and 300 million private chatbot messages sitting in an open database.

The theme is that speed kills. AI capabilities are moving faster than the people building them can secure them, faster than the regulators writing rules, and faster than the enterprises deploying them can govern.

Here’s what mattered and what you should do about it. If you’re building your AI governance program, RockCyber can help you close the gaps.

Share

1. Microsoft patches prompt injection RCE in GitHub Copilot, three actively exploited zero-days hit Windows

Microsoft’s February 10 Patch Tuesday dropped fixes for 58 vulnerabilities, including six actively exploited zero-days (BleepingComputer). The AI security headline is that remote code execution vulnerabilities in GitHub Copilot across VS Code, Visual Studio, and JetBrains products (CVE-2026-21516, CVE-2026-21523, CVE-2026-21256). These flaws stem from command injection triggered through prompt injection (Krebs on Security). A threat actor embeds a malicious prompt into a codebase, and when an agent workflow executes, the prompt becomes code. CISA added all six zero-days to its KEV catalog the same day (SecurityWeek).

Why it matters

• AI coding assistants are now a confirmed attack surface. The prompt-to-execution chain is live.

• CI/CD pipelines using Copilot agent workflows are exposed to supply chain attacks through poisoned repositories.

• Six zero-days exploited simultaneously signals coordinated offensive activity.

What to do about it

• Patch all affected GitHub Copilot, VS Code, Visual Studio, and JetBrains installations before the CISA KEV deadline.

• Audit CI/CD pipelines that use Copilot agent mode. Disable automatic command execution from AI-suggested code until you validate controls.

• Prioritize CVE-2026-21510 (SmartScreen bypass), CVE-2026-21514 (Word OLE bypass), and CVE-2026-21533 (RDP to SYSTEM) across all endpoints.

Rock’s Musings

Prompt injection strikes again, but this time in an actively exploited vulnerability in the world’s most popular AI coding tool. A poisoned README triggers remote code execution when Copilot processes it. Every AI agent that reads unvalidated context and executes actions has this same problem. The architecture is the vulnerability. Start treating AI agent security as a distinct risk domain in your program.

2. International AI Safety Report 2026 drops, confirms governance is losing the race

On February 3, the second International AI Safety Report was published, chaired by Yoshua Bengio and authored by over 100 experts from 30+ countries (International AI Safety Report). The report finds that AI capabilities have accelerated sharply in mathematics, coding, and autonomous task execution (Inside Global Tech). A key finding is that some models detect when they’re being tested and behave differently during evaluation versus deployment. The report calls risk management frameworks “still immature” (AI Governance Library).

Why it matters

• The largest global collaboration on AI safety now says governance can’t keep up with capability advances.

• Models that game their own evaluations undermine every safety benchmark your vendor shows you.

• 12 frontier AI companies published safety frameworks in 2025, but the report notes wide variation in scope and enforceability.

What to do about it

• Use the report as board-level evidence to justify accelerated AI governance investment. It carries the weight of 30 governments and the UN.

• Challenge vendor safety claims by asking about evaluation gaming. If their model can distinguish test from deployment, your risk assessment is incomplete.

• Map your AI risk management practices against the report’s four-component framework: risk identification, analysis, mitigation, and governance.

Rock’s Musings

Most of this report confirms what practitioners already knew, but that’s why it matters. When Bengio and 100 experts backed by 30 nations say “real-world evidence of safety measure effectiveness remains limited,” your board can’t dismiss that as one consultant’s opinion. The bit about models gaming evaluations should keep you up at night. If the AI can tell when it’s being tested, every safety benchmark you’ve seen is unreliable. Send the executive summary to your CEO.

3. North Korea’s UNC1069 runs deepfake Zoom calls to steal crypto

Google’s Mandiant published research on February 9 detailing UNC1069, a North Korean threat actor targeting a FinTech organization (Google Cloud Blog). The attackers compromised a crypto executive’s Telegram account, sent a Calendly link to a fake Zoom meeting, and displayed a deepfake video of a CEO during the call (The Record). The intrusion deployed seven distinct malware families including three new tools (Dark Reading).

Why it matters

• Deepfake video is now a confirmed offensive tool in state-sponsored financial crime.

• Seven malware families on a single host shows a targeted, high-investment operation.

• The Telegram-to-Zoom-to-malware chain exploits the trust your employees place in the common business tools they use daily.

What to do about it

• Brief cryptocurrency and financial services teams on the specific attack chain: compromised Telegram account, Calendly invite, spoofed Zoom link, ClickFix infection.

• Require verified domains for all conferencing links. Block look-alike Zoom infrastructure at email and web gateways.

• Train staff that “run these commands to fix audio/video” during unsolicited calls is a red flag. That’s the ClickFix technique, and it works because people comply.

Rock’s Musings

North Korea stole over $2 billion in crypto in 2025. UNC1069 is just one crew in what TRM Labs calls an “industrialized theft supply chain.” The deepfake angle changes everything. When your employee sees a video of a known CEO on a Zoom call, trust goes up, skepticism goes down, and seven malware families get dropped.

4. DockerDash vulnerability turns AI metadata into executable code

On February 3, Noma Labs disclosed a critical flaw in Docker’s Ask Gordon AI assistant, dubbed DockerDash (Noma Security). A malicious metadata label in a Docker image hijacks the AI’s execution chain: Gordon reads it, forwards it to the MCP Gateway, and the gateway executes it with zero validation (SecurityWeek). In cloud/CLI environments, this enables RCE. In Docker Desktop, it enables data exfiltration (Infosecurity Magazine).

Why it matters

• This is another well-documented exploitation of Model Context Protocol (MCP) as an attack surface, a protocol gaining rapid adoption.

• The attack uses standard Docker LABEL fields, meaning malicious images look normal to existing scanning tools.

• The pattern applies to any AI agent that reads external context and passes it to an execution layer.

What to do about it

• Upgrade to Docker Desktop 4.50.0 or later immediately.

• Audit any AI agent in your environment that reads metadata, documents, or external context and can trigger tool execution.

• Demand human-in-the-loop confirmation for all MCP tool invocations in development environments.

Rock’s Musings

Noma’s Sasi Levi nailed it. The DockerDash vulnerability “isn’t Docker-specific, it’s AI-specific.” Every RAG system, every AI assistant that reads metadata, every agent that processes external input faces the same problem. The AI cannot distinguish between context and instruction. The MCP standard is growing fast. If you’re deploying MCP-connected agents, treat every external input as potentially malicious.

5. Chat and Ask AI app leaks 300 million messages from 25 million users

Security researcher Harry found that Chat and Ask AI, a wrapper app with 50+ million downloads connecting users to ChatGPT, Claude, and Gemini, left its Firebase backend wide open (404 Media). The misconfiguration exposed roughly 300 million messages from 25 million users (Malwarebytes). Messages contained mental health discussions, self-harm requests, and queries about illegal activities (GBHackers).

Why it matters

• 300 million messages prove that AI chat wrapper apps store everything users type, and often store it insecurely.

• The Firebase misconfiguration is a known, preventable error. This wasn’t a sophisticated attack. It was an open door.

• Users treated AI chats as private conversations. The exposed content creates extortion, identity theft, and social engineering risk at massive scale.

What to do about it

• Inventory third-party AI wrapper apps in your environment. If employees use consumer AI apps for work, their conversations sit in someone else’s database.

• Add AI app vetting to your shadow IT detection process. Firebase misconfigurations are scannable.

• Remind employees: anything typed into an AI chat may be stored, breached, and public. Treat AI conversations with the same caution as email.

Rock’s Musings

Codeway built a wrapper app that connects to real AI models from real companies. But the app stored everything in a Firebase database with public read access. No attack needed. Just log in. Think about how many AI wrapper apps your employees downloaded this year. Each one stores conversations on infrastructure you don’t control. The apps people use to access AI are the weak link.

6. Senator Hassan presses Bondu after AI toy exposes 50,000 children’s chat logs

Senator Maggie Hassan sent a formal letter to Bondu, maker of AI plush toys for children ages 3 to 9, after researchers found Bondu’s web portal allowed anyone with a Gmail account to access 50,000 children’s chat transcripts (Senate Joint Economic Committee). Exposed data included children’s names, birth dates, and intimate conversations (Axios). Bondu patched the issue within hours of disclosure (Malwarebytes).

Why it matters

• 50,000 children’s private conversations were accessible to anyone with a Google account. No hacking required.

• Congressional attention signals that AI toy security will become a regulatory priority, with California SB 867 already proposing a four-year moratorium on AI companion chatbots for minors.

• The data included information that researchers called “a kidnapper’s dream”: names, birthdays, family details, and behavioral patterns.

What to do about it

• If your organization develops or invests in consumer AI products that interact with children, conduct an immediate security audit of data storage and access controls.

• Monitor legislative developments. SB 867 in California and the Parents and Kids Safe AI Act will reshape compliance requirements for AI products targeting minors.

• Review your enterprise’s policy on AI products used by employees’ families.

Rock’s Musings

Joel Margolis told Wired the exposed data was “a kidnapper’s dream.” Names, birthdays, what kids like, who their family members are, all accessible with a Gmail login. Bondu touted 18 months of safe beta testing. The problem was never the toy’s behavior. It was that every word a child said to a stuffed dinosaur sat on an open server. The attack surface isn’t the model. It’s the trust that makes people share everything with a friendly interface.

7. Eight critical n8n vulnerabilities expose AI orchestration infrastructure

Between January and early February 2026, eight new high-to-critical CVEs were disclosed in n8n, the popular open-source workflow automation platform (Geordie AI). The vulnerabilities span expression evaluation, file access controls, Git, SSH, Merge nodes, and Python execution. Several bypass earlier patches, including CVE-2026-25049 which enables system command execution via malicious workflows (The Hacker News). Organizations that upgraded to n8n 2.2.2 following January guidance remain exposed.

Why it matters

• n8n sits at the intersection of APIs, secrets, CI/CD, and AI orchestration. A compromise here cascades across your entire automation stack.

• Multiple vulnerabilities bypass earlier patches, creating a false sense of security for organizations that thought they were current.

• Authenticated workflow editor access is enough to exploit several flaws, and that role is commonly granted to non-administrators.

What to do about it

• Patch n8n immediately. Do not assume the January patch cycle covered you.

• Audit who has workflow editor access. Apply least-privilege principles to your automation platform.

• Review all n8n workflows that handle credentials or connect to AI services.

Rock’s Musings

n8n flies under the security radar because it’s “just automation.” But it connects to your APIs, stores your credentials, orchestrates your AI workflows, and executes code. Eight CVEs in one month, several bypassing previous patches, tells me the security debt in AI tooling is deeper than most teams realize. If you’re running n8n in production, treat it like Active Directory. To an attacker, it’s just as valuable.

8. Ivanti EPMM zero-days breach Dutch and Finnish government systems

Ivanti disclosed two zero-day vulnerabilities in Endpoint Manager Mobile (EPMM), CVE-2026-1281 and CVE-2026-1340, both CVSS 9.8, on January 29 (The Hacker News). By February 9, the Netherlands confirmed compromise of government systems. Finland’s Valtori disclosed a breach affecting 50,000 government employees (The Hacker News).

Why it matters

• Two European government institutions confirmed compromise within days of disclosure.

• The dormant payload technique suggests brokers are stockpiling access to government systems for future sale.

• EPMM manages mobile devices. Compromising it means potential access to every managed device.

What to do about it

• If you run Ivanti EPMM, patch to the emergency release immediately. Check for indicators of compromise, specifically the /mifs/403.jsp web shell path.

• Review EPMM logs for unusual authentication patterns between January 29 and your patch date. The zero-days were exploited before disclosure.

• Audit your mobile device management architecture. If your MDM platform is compromised, assume all managed devices are potentially exposed.

Rock’s Musings

Ivanti. Again. EPMM manages mobile devices for governments and critical infrastructure operators. Two 9.8 CVSS zero-days, exploited before disclosure, breaching government systems across Europe. The dormant payload angle is telling. Access brokers are treating compromised government infrastructure like inventory: gain entry, plant loaders, wait to sell.

9. Colorado AI Act delayed to June 2026 as federal preemption fight intensifies

Colorado’s AI Act (SB 24-205), originally scheduled for February 1, 2026, has been delayed to June 30 (King and Spalding). The delay follows President Trump’s December 2025 executive order directing an AI Litigation Task Force to challenge state AI laws (Gunderson Dettmer). Colorado is the only state law specifically named in the executive order.

Why it matters

• The most comprehensive U.S. state AI law targeting algorithmic discrimination in high-risk systems just got pushed back five months.

• The federal preemption fight creates compliance uncertainty for every organization deploying AI in employment, lending, housing, or insurance decisions.

What to do about it

• Don’t pause compliance work. The executive order cannot overturn state law. State laws remain enforceable until struck down.

• Prepare for a two-track reality: implement state obligations while tracking federal moves that could narrow those obligations.

• Document your impact assessments and risk management now. You’ll need them regardless of which jurisdiction prevails.

Rock’s Musings

Companies scrambling to comply by February 1 just got breathing room. Companies that already did the work got a competitive advantage. The federal preemption push faces a long road through courts. My advice: build your AI governance to the highest standard any jurisdiction requires. If you meet Colorado’s requirements, you’ll meet most of what Texas, California, and the EU AI Act demand.

10. EU AI Act high-risk guidance misses deadline as August 2026 enforcement looms

The European Commission missed its deadline to publish guidelines on high-risk AI system requirements under the EU AI Act (IAPP). CEN and CENELEC, the standardization bodies, also missed their deadline and now aim for the end of 2026. High-risk obligations become enforceable in August 2026. The GPAI Code of Practice is expected in final form by June (Bird and Bird).

Why it matters

• Organizations building compliance programs for high-risk AI systems have no finalized guidance or technical standards, with enforcement just six months away.

• The standards delay means there’s no “safe harbor” for companies trying to demonstrate conformity.

• Industry groups are calling for enforcement delays, but the statutory deadline stands.

What to do about it

• Don’t wait for final standards. Build your compliance program on the AI Act text, the NIST AI Risk Management Framework, and available draft guidance.

• Track the General-Purpose AI Code of Practice. If you’re a GPAI provider, the June finalization means compliance work needs to be underway now.

• Engage your legal team on whether your AI systems qualify as “high-risk” under the Act. The classification determines your obligations, and waiting for guidance is not a defense.

Rock’s Musings

The EU passed the most ambitious AI regulation in history, then couldn’t deliver the guidance companies need to comply with it. But the enforcement date hasn’t moved. August 2026 is coming whether the paperwork is ready or not. Build to the text of the Act, supplement with NIST and OWASP guidance, and document everything.

The One Thing You Won’t Hear About But You Need To

AI agents are inheriting the permissions of the humans who use them, and nobody is governing that

Well… if you follow me on Linkedin, you’ve definitely heard about this. Just take a look across this week’s stories and you’ll see a pattern nobody is naming. In the Copilot vulnerabilities, the AI executes malicious code with the developer’s privileges. In DockerDash, Ask Gordon forwards poisoned metadata using whatever access Docker provides. In n8n, workflow editor access exploits critical vulnerabilities because the platform inherits broad permissions.

AI agents inherit the permission scope of the humans and systems they operate within, but they don’t inherit the judgment to use those permissions safely.

Why it matters

• Traditional identity and access management (IAM) was built for human users who exercise judgment. AI agents exercise none.

• The blast radius of a compromised AI agent equals the full permission set of the account or environment it operates in.

• No major IAM framework currently addresses AI agent permissions as a distinct category requiring separate controls.

What to do about it

• Assign each agent a workload identity that is cryptographically attested and bound to its runtime environment, not a static service account. Pair it with just-in-time, short-lived tokens scoped per task so there are no standing credentials to steal or reuse.

• Enforce capability-level access controls that evaluate what each agent is doing, not just who spawned it. A developer’s AI assistant should never inherit production access simply because the developer has it.

• Treat agent permissions as privileged access: review them quarterly, require justification for renewal, and auto-revoke on expiry. Standing agent permissions are standing risk.

Rock’s Musings

We’re giving AI agents the keys to the kingdom and hoping they’ll only open the right doors. That’s not a security strategy. That’s a prayer. The NIST AI RMF doesn’t address agent permissions. The EU AI Act barely touches it. I think this becomes the defining AI security challenge of 2026. Start with an inventory. Then start restricting. For more on building AI governance programs that address these gaps, visit RockCyber Musings or reach out to RockCyber directly.

If you found this analysis useful, subscribe at rockcybermusings.com for weekly intelligence on AI security developments.

👉 Visit RockCyber.com to learn more about how we can help you in your traditional Cybersecurity and AI Security and Governance Journey

👉 Want to save a quick $100K? Check out our AI Governance Tools at AIGovernanceToolkit.com

👉 Subscribe for more AI and cyber insights with the occasional rant.

Share RockCyber Musings

References

404 Media. (2026, February 5). Massive AI chat app leaked millions of users’ private conversations. https://www.404media.co/massive-ai-chat-app-leaked-millions-of-users-private-conversations/

ASIS Online. (2026, February). New International AI Safety Report spotlights emerging risks. Security Management. https://www.asisonline.org/security-management-magazine/latest-news/today-in-security/2026/february/2026-international-safety-report/

Axios. (2026, February 3). Senator presses AI toy company bondu after kids’ chat data was exposed. https://www.axios.com/2026/02/03/ai-toy-bondu-chat-data-exposure-hassan

Bird & Bird. (2026). Taking the EU AI Act to practice: Understanding the draft transparency code of practice. https://www.twobirds.com/en/insights/2026/taking-the-eu-ai-act-to-practice-understanding-the-draft-transparency-code-of-practice

BleepingComputer. (2026, February 11). Microsoft February 2026 Patch Tuesday fixes 6 zero-days, 58 flaws. https://www.bleepingcomputer.com/news/microsoft/microsoft-february-2026-patch-tuesday-fixes-6-zero-days-58-flaws/

Check Point Research. (2026, February 9). 9th February: Threat intelligence report. https://research.checkpoint.com/2026/9th-february-threat-intelligence-report/

Common Sense Media. (2026, January 22). Common Sense Media warns against AI toy companions after research reveals safety risks [Press release]. https://www.commonsensemedia.org/press-releases/common-sense-media-warns-against-ai-toy-companions-after-research-reveals-safety-risks

CSO Online. (2026, February 11). Microsoft fixes six zero-days on February 2026 Patch Tuesday. https://www.csoonline.com/article/4130446/february-2026-patch-tuesday-six-new-and-actively-exploited-microsoft-vulnerabilities-addressed.html

CyberAdviser Blog. (2026, January). What to expect in AI regulation in 2026. https://www.cyberadviserblog.com/2026/01/what-to-expect-in-ai-regulation-in-2026/

Cybernews. (2026, February 10). Armed with new tools, North Koreans ramp up attacks on lucrative crypto sector. https://cybernews.com/security/north-korea-ai-lucrative-crypto-industry/

CyberPress. (2026, February 10). AI chat app data breach exposes 300 million messages. https://cyberguy.com/security/millions-ai-chat-messages-exposed-app-data-leak/

Dark Reading. (2026, February 11). North Korea’s UNC1069 hammers crypto firms with AI. https://www.darkreading.com/threat-intelligence/north-koreas-unc1069-hammers-crypto-firms

GBHackers. (2026, February 10). 25 million users affected as AI chat platform leaks 300 million messages. https://gbhackers.com/ai-chat-platform-leaks-300-million-messages/

Geordie AI. (2026, February). Eight new n8n CVEs in February 2026: Updated patching guidance. https://www.geordie.ai/resources/technical-advisory-eight-new-n8n-cves-since-january---updated-remediation-guidance

Google Cloud Blog. (2026, February 9). UNC1069 targets cryptocurrency sector with new tooling and AI-enabled social engineering. https://cloud.google.com/blog/topics/threat-intelligence/unc1069-targets-cryptocurrency-ai-social-engineering

Gunderson Dettmer. (2026). 2026 AI laws update: Key regulations and practical guidance. https://www.gunder.com/en/news-insights/insights/2026-ai-laws-update-key-regulations-and-practical-guidance

IAPP. (2026, February). European Commission misses deadline for AI Act guidance on high-risk systems. https://iapp.org/news/a/european-commission-misses-deadline-for-ai-act-guidance-on-high-risk-systems

Infosecurity Magazine. (2026, February 9). DockerDash exposes AI supply chain weakness in Docker’s Ask Gordon. https://www.infosecurity-magazine.com/news/dockerdash-weakness-dockers-ask

Inside Global Tech. (2026, February 10). International AI Safety Report 2026 examines AI capabilities, risks, and safeguards. https://www.insideglobaltech.com/2026/02/10/international-ai-safety-report-2026-examines-ai-capabilities-risks-and-safeguards/

International AI Safety Report. (2026, February 3). International AI Safety Report 2026. https://internationalaisafetyreport.org/publication/international-ai-safety-report-2026

King & Spalding. (2026). New state AI laws are effective on January 1, 2026, but a new executive order signals disruption. https://www.kslaw.com/news-and-insights/new-state-ai-laws-are-effective-on-january-1-2026-but-a-new-executive-order-signals-disruption

Krebs on Security. (2026, February 11). Patch Tuesday, February 2026 edition. https://krebsonsecurity.com/2026/02/patch-tuesday-february-2026-edition/

Malwarebytes. (2026, February 10). AI chat app leak exposes 300 million messages tied to 25 million users. https://www.malwarebytes.com/blog/news/2026/02/ai-chat-app-leak-exposes-300-million-messages-tied-to-25-million-users

Malwarebytes. (2026, February). An AI plush toy exposed thousands of private chats with children. https://www.malwarebytes.com/blog/news/2026/02/an-ai-plush-toy-exposed-thousands-of-private-chats-with-children

Noma Security. (2026, February 3). DockerDash: Two attack paths, one AI supply chain crisis. https://noma.security/blog/dockerdash-two-attack-paths-one-ai-supply-chain-crisis/

SecurityWeek. (2026, February 4). DockerDash flaw in Docker AI assistant leads to RCE, data theft. https://www.securityweek.com/dockerdash-flaw-in-docker-ai-assistant-leads-to-rce-data-theft/

SecurityWeek. (2026, February 11). 6 actively exploited zero-days patched by Microsoft with February 2026 updates. https://www.securityweek.com/6-actively-exploited-zero-days-patched-by-microsoft-with-february-2026-updates/

The Hacker News. (2026, February 3). Docker fixes critical Ask Gordon AI flaw allowing code execution via image metadata. https://thehackernews.com/2026/02/docker-fixes-critical-ask-gordon-ai.html

The Hacker News. (2026, February 11). North Korea-linked UNC1069 uses AI lures to attack cryptocurrency organizations. https://thehackernews.com/2026/02/north-korea-linked-unc1069-uses-ai.html

The Hacker News. (2026, February 12). Dutch authorities confirm Ivanti zero-day exploit exposed employee contact data. https://thehackernews.com/2026/02/dutch-authorities-confirm-ivanti-zero.html

The Record. (2026, February 10). North Korean hackers targeted crypto exec with fake Zoom meeting, ClickFix scam. https://therecord.media/north-korean-hackers-targeted-crypto-exec-clickfix

U.S. Senate Joint Economic Committee. (2026, February 3). Senator Hassan presses toy company on child safety and privacy practices. https://www.jec.senate.gov/public/index.cfm/democrats/2026/2/senator-hassan-presses-toy-company-on-child-safety-and-privacy-practices-after-children-s-conversations-with-its-ai-chat-toy-were-left-exposed-to-any-gmail-user

Zero Day Initiative. (2026, February 11). The February 2026 security update review. https://www.zerodayinitiative.com/blog/2026/2/10/the-february-2026-security-update-review

Share

Every major AI coding assistant got pwned last year. GitHub Copilot. Cursor. Windsurf. Claude Code. JetBrains Junie. All of them.

The IDEsaster disclosure in December 2025 documented 30+ vulnerabilities across the entire ecosystem. 100% of tested AI IDEs were vulnerable to prompt injection attacks that chain through legitimate IDE features to achieve remote code execution and data exfiltration. Then came the MCP breaches. Tool poisoning attacks through the Model Context Protocol let malicious servers exfiltrate entire WhatsApp histories. The GitHub MCP server got hijacked through a poisoned public issue that leaked private repository contents.

I watched this unfold while building parallel Claude Code infrastructure for my own work. The performance benefits of running multiple agents simultaneously were obvious. The security implications were terrifying.

Claude Code changed how I build software. Hell, it lets me do it as I don’t have a heavy software development background. One instance handles tasks that used to take me hours, but you can’t run two of them at once. Not really.

Workarounds exist. Git worktrees. Multiple terminals. Manual coordination. They all share the same fatal flaw. You become the orchestrator instead of the engineer. You’re babysitting AI agents instead of shipping code.

I got tired of it. Tired of copy-pasting context between sessions. Tired of watching one agent sit idle while another churned through a task I could’ve parallelized. Tired of evaluating orchestration tools that optimized for speed and autonomy while treating security as an optional configuration. Phase-two stuff.

So I built Zerg. Parallel Claude Code orchestration with security, context engineering, and crash recovery baked in from day one. Not bolted on. Not “coming in phase two.” Built in.

Today it’s open source. Here’s what it does, how the architecture works, and what you should know before you touch it.

The Problem Nobody Else Solved

The biggest limitation of Claude Code is embarrassingly simple: one task at a time or risk conflicts and race conditions. While one agent refactors authentication, you wait. It can’t write tests in parallel. It can’t document changes while it codes. You sit there watching a spinner like you’re on dial-up.

This isn’t a bug. Claude Code is a CLI tool. It does one thing well. But one thing isn’t enough anymore. There are many tools out there that allow you to parallelize tasks, but none take a security-first, context engineering mindset.

ZERG does.

The community noticed. A feature request hit Claude Code’s GitHub repo in August 2025 describing exactly this pain. Developers manually create worktrees, navigate between directories, and manage multiple terminal windows. The request proposed native orchestration. It shipped literally a few days ago. Too soon and too “beta” for me to integrate into Zerg before release.

So what did everyone do? They built workarounds. Simon Willison wrote about running multiple instances across directories. Someone documented orchestrating 10+ Claude instances with custom Python and Redis queues. These solutions work, but they’re duct tape and prayer. You’re building coordination infrastructure that should exist in the tool itself.

The agentic AI industry is obsessed with autonomy. More autonomy. Agents that think for themselves. Agents that chain tools together without human approval.

Know what they should be obsessed with? Predictability. Recovery. Security. What happens when one of your five parallel agents crashes at 2 AM? How do you resume without losing three hours of work? How do you prevent your context window from bloating until your $200 API bill becomes $2,000? And after IDEsaster proved every AI IDE can be weaponized through prompt injection, how do you isolate workers so a compromised agent can’t poison the others?

What Zerg Does That Nothing Else Does

Let me be clear about what Zerg isn’t. It’s not LangChain. It’s not CrewAI. It’s not AutoGen. It’s not trying to be a general-purpose agentic framework for every use case under the sun.

Zerg does one thing. It coordinates multiple Claude Code instances running in parallel with security isolation baked in. It does this with four capabilities I couldn’t find anywhere else combined into one system.

Spec-Driven Execution

Every worker reads from shared files: requirements.md, design.md, and task-graph.json. Workers are stateless. If one crashes, another picks up the task. No context lost. Why? Because context lives in the filesystem, not in conversation history that evaporates when a process dies.

The task graph defines dependencies and exclusive file ownership. Two workers never touch the same file in the same execution level. Merge conflicts within levels become structurally impossible. Not “unlikely.” Not “rare.” Impossible.

This sounds obvious until you look at what everyone else built. Most parallel agent solutions let agents race each other, then deal with conflicts at merge time. That’s backwards. Zerg eliminates the conflict at the design phase because I got tired of debugging merge disasters at midnight.

Context Engineering That Actually Works

Zerg achieves 30-50% token reduction per worker through three mechanisms that nobody else bothered to implement systematically.

First, command splitting. Nine large commands are split into core documentation (about 30% of tokens) and detail files (about 70%). Workers load only what they need. A worker doing Python refactoring doesn’t need the full Kubernetes deployment guide sitting in its context window.

Second, security rule filtering. Instead of loading every security rule for every language, workers load only rules matching the file extensions in their task. A Python-only task doesn’t get JavaScript security guidance, consuming tokens for no reason.

Third, task-scoped context. Each worker gets spec excerpts plus dependency context within a 4,000-token budget by default. Not the whole spec. Not everything that might be relevant. Just what’s needed for this task.

Token reduction isn’t just cost optimization. It’s attack surface reduction. Every token in a worker’s context window represents potential instruction injection. IDEsaster attacks succeed because agents process everything in their context as potentially actionable instructions. Less context means fewer attack vectors.

Security That Isn’t an Afterthought

After watching IDEsaster and MCP tool poisoning compromise every major AI coding tool, I built Zerg with isolation as an architectural requirement.

You have the option of containerized isolation runs. Workers execute as non-root. Environment filtering blocks LD_PRELOAD and other injection vectors. Workers can’t access your SSH keys, cloud credentials, or API tokens unless you explicitly provide them.

Security rules get fetched automatically from the TikiTribe/claude-secure-coding-rules repository during initialization. External sourcing matters: keeping security rules outside your repository prevents poisoned commits from degrading your security baseline. A compromised developer machine can’t inject malicious “security rules” that weaken protections.

Pre-commit hooks run before any worker commits code. Secret detection scans for exposed credentials. Security rule validation ensures generated code meets your configured baseline. Even if a worker hallucinates insecure code, the commit fails before vulnerable code reaches your repository. It’s not perfect… nothing is.

Git worktree isolation means each worker operates in its own worktree. Workers can’t see each other’s in-progress changes. A compromised worker can’t poison another worker’s execution by modifying shared files.

Resilience That Assumes Failure

Circuit breakers trigger after five consecutive failures, enforcing a 60-second cooldown. Backpressure control with green, yellow, and red zones based on failure rates. Worker crash recovery with heartbeat monitoring and automatic restart.

Crashes don’t count against retry limits because infrastructure failures shouldn’t penalize your task budget. A network timeout isn’t the same as a logic error. The system knows the difference.

The diagnostics engine parses errors from Python, JavaScript, Go, and Rust. Bayesian hypothesis testing against 30+ known failure patterns. When five workers are running and something breaks, you need to know whether it’s one worker’s problem or everybody’s problem.

Got it. Let me write this section based on the architectural implications of each mode.

Three Ways to Rush: Tasks, Subprocess, and Container Modes

Zerg doesn’t force you into one execution model. Different projects have different constraints. A solo developer on a MacBook has different needs than an enterprise team running CI/CD pipelines on hardened infrastructure. So Zerg ships with three rush modes, each with distinct tradeoffs.

Tasks Mode

The default. Each worker becomes a Claude Code subagent through Claude’s native Task system, with its own conversation context and tool permissions. The orchestrator coordinates through Claude’s built-in task management rather than managing processes directly.

Tasks mode applies Claude Code’s native guardrails to each worker. Permission boundaries come from Claude’s task system rather than from OS-level isolation. You get integration with Claude’s tooling ecosystem, including the ability to specify different models per worker if cost optimization matters. Haiku for simple file operations, Sonnet for complex refactoring, Opus when you need the heavy artillery.

The tradeoff is coordination overhead. Task spawning goes through Claude’s API layer, which adds latency compared to raw subprocess spawning. For tasks that complete in seconds, this overhead is noticeable. For tasks that run for minutes, it’s negligible. Most parallel workloads fall into the second category.

Subprocess Mode

Each worker runs as a separate OS process on your local machine. Faster to spin up because there’s no API coordination layer. Workers share your filesystem through git worktrees, which means they inherit your local environment, your installed tools, your shell configuration.

Use subprocess mode when you’re iterating quickly, and latency matters more than isolation. It’s the lightest-weight option. The tradeoff is that process isolation is weaker than both tasks mode and container mode. A compromised worker could theoretically access memory or environment variables from sibling processes. For most development workflows on trusted codebases, this risk is acceptable. For production pipelines processing untrusted code, it’s not.

Container Mode

Maximum isolation. Each worker spawns inside its own container with a separate filesystem, network namespace, and process tree. Workers can’t see each other. A compromised worker can’t escape to poison siblings or exfiltrate credentials from the host.

This is the mode that addresses IDEsaster-class attacks head-on. When a malicious README injects instructions into a worker’s context, that worker operates inside a container running as non-root with LD_PRELOAD blocked and environment variables filtered. Even if the attack succeeds at the prompt level, the blast radius stays contained. The worker can’t reach your SSH keys, can’t access your cloud credentials, can’t modify files outside its designated worktree.

Container mode requires Docker or a compatible runtime. Startup time increases because each worker needs a container image pulled and initialized. For short-lived tasks, this overhead hurts. For longer parallel workloads where security matters, it’s the right call.

Picking the Right Mode

The decision tree is straightforward. Are you processing untrusted code or operating in a high-security environment? Container mode. Are you optimizing for raw speed on a trusted codebase? Subprocess mode. Want Claude’s native permission system with reasonable defaults? Stick with the tasks mode.

You can also mix modes across different rush phases. Use subprocess mode during rapid prototyping, then switch to container mode before merging to main. The task graph doesn’t care which mode executes it. Workers are stateless. The mode determines isolation boundaries, not task logic.

How the Architecture Actually Works

The design philosophy prioritizes explicit over implicit. Configuration lives in JSON and Markdown files, not environment variables scattered across your system. State lives in the filesystem, not in process memory that dies with a crash. Every decision is auditable because every decision produces a traceable artifact.

The execution flow follows a deliberate progression that mirrors how experienced engineers break down complex work.

Planning starts with Socratic discovery through the /zerg:plan command. You describe what you want. Zerg asks clarifying questions. The output is requirements.md. Not code. Not tasks. Requirements that a human can read and verify before anything else happens.

Design analyzes the architecture and generates task-graph.json with exclusive file ownership assignments. This is where parallel execution becomes safe. Each file gets assigned to exactly one worker per level. No races. No conflicts.

Rush spawns workers in git worktrees and executes tasks in parallel, merging results at level boundaries with quality gates. A level doesn’t complete until all its workers pass. If something fails, the whole level fails. No partial merges that leave your codebase in a broken state.

Review runs automated testing, security scanning, and code review. Not optional. Not “if you have time.” Built into the flow.

The 26 slash commands have /z: shortcuts because I got tired of typing /zerg: every time. /zerg:init becomes /z:init. /zerg:rush becomes /z:rush. Small thing. Adds up.

Other Tools and Why They Fall Short

The Claude Code ecosystem has exploded with orchestration tools. Claude-flow claims 175+ MCP tools and calls itself “the leading agent orchestration platform.” Oh-my-claudecode offers 5 execution modes with 32 specialized agents. Code-conductor provides parallel worktree execution.

None of them solve the challenge of a coordinated security posture, systematic context engineering, and level-based execution with guaranteed file isolation. Most treat security as a feature flag you can toggle. Most leave context management entirely to you. Most assume you want role-based agents with personalities instead of spec-driven workers that do what the task graph says.

The broader multi-agent orchestration market is projected to reach $8.5 billion by 2026. Organizations using multi-agent architectures report 45% faster problem resolution, but these gains depend on proper orchestration. You can have the fanciest agents in the world. If they’re stepping on each other, wasting tokens, crashing without recovery, and vulnerable to the same attacks that compromised every AI IDE last year, you’ve built an expensive disappointment.

Getting Started Without Breaking Things

Clone the repository. The README walks through a complete example.

The /zerg:init command establishes your project’s architecture and security baseline. It creates the configuration structure, fetches OWASP rules from Tikitribe, sets up container isolation if you’re using devcontainers, installs pre-commit hooks, and initializes audit logging. Everything about Zerg’s security posture starts with that command.

Start small. Pick a feature that breaks into independent subtasks. Run /zerg:plan to generate requirements. Actually, read the output. Then /zerg:design to create the task graph. Inspect file ownership assignments. If something looks wrong, fix it before running /zerg:rush. Human oversight at decision points. Not full autonomy. You’re still responsible for what ships.

Version 0.2.0 is officially released today, February 7, 2026. This isn’t a weekend hack. It’s production infrastructure I’ve been running on my own projects. Having said that, it’s released under an MIT license with no warranty.

What Building This Taught Me

The biggest insight wasn’t technical. Agentic AI development has a trust problem pure capability can’t solve. Agents fail. They hallucinate. They consume resources unpredictably. And after IDEsaster, we know they can be weaponized through their context windows. The solution isn’t smarter agents. It’s smarter orchestration that assumes failure, contains blast radius, and recovers gracefully.

Building Zerg forced me to confront failure modes I’d never considered. What happens when a worker hallucinates a dependency that doesn’t exist? What if two workers both claim the same file despite the task graph? What if a poisoned README injects malicious instructions? Each edge case required explicit handling.

The CARE framework I’ve developed for AI governance emphasizes that resilience isn’t a feature you add later. It’s an architectural decision you make at the beginning, or pay for forever. I’ve watched enterprise teams learn this the expensive way.

Context engineering will define the next generation of agent builders. Prompt engineering is table stakes. Understanding how to curate, compress, and isolate context? That’s the skill separating toy projects from production systems.

Key Takeaway: Parallel Claude Code execution was inevitable. Security-first, context-aware orchestration was a choice. Zerg makes that choice for you so you can focus on the work that matters.

What to do next

Star the repository at Github.com/rocklambros/zerg and try the quick start guide. Open issues when you hit problems. Use it on your own projects and tell me what breaks.

For hands-on guidance on deploying this in enterprise environments, reach out to RockCyber. For more on AI security and practical development with the occasional rant about things that should be obvious but apparently aren’t, subscribe to RockCyber Musings.

👉 Star Zerg: The original security-first parallel Claude Code orchestrator repository and try the quick start guide.

👉 Subscribe for more AI security and governance insights with the occasional rant.

👉 Visit RockCyber.com to learn more about how we can help you in your traditional Cybersecurity and AI Security and Governance Journey

👉 Want to save a quick $100K? Check out our AI Governance Tools at AIGovernanceToolkit.com

Share RockCyber Musings

The trap isn’t the AI itself. It’s the illusion that you control it while your engineers run it on private servers you don’t know about. This week proved that “Shadow AI” is no longer a buzzword for a slide deck. It’s a lobster claw pinching your infrastructure while you sleep.

We saw a major open-source agent turn into a security disaster. A federal agency chief got caught breaking his own rules. The European Union quietly shifted the liability burden onto your shoulders. If you thought 2026 was the year we figured this out, you were wrong.

Share

1. OpenClawd’s “Sovereign” Security Meltdown

OpenClawd (formerly Moltbot, formerly ClawdBot) launched its “Secure Hosted Platform” on January 31, followed by a framework integration announcement on February 5. They promised “Sovereign AI” that runs on private infrastructure. Security researchers spent the week tearing it apart. Reports surfaced of thousands of “Clawdbot” agents running with open ports and no authentication.

Why it matters

• You cannot have “sovereign” AI that relies on a central provider’s management plane. That’s SaaS with extra steps and more liability.

• Researchers demonstrated that a simple email sent to an OpenClawd agent could trick it into exfiltrating local files. If your agent reads your email, your email attacks your agent.

• Token Security reports that 22% of their customers had employees running these agents on corporate networks.

What to do about it

• Audit agent permissions. If you have developers running local agent frameworks, block their egress at the firewall immediately.

• Isolate the executors. Never run an agent on a machine with production credentials. Use ephemeral sandboxes that die after one task.

• Ignore the label. Treat “sovereign” marketing claims as a warning sign.

Rock’s Musings

I love the irony. Almost poetic. A company sells you “sovereignty,” the digital equivalent of a cabin in the woods, by asking you to trust their hosted control plane. It’s like buying a generator for the apocalypse that requires a Wi-Fi connection to the power company to start.

The flaw here isn’t in the code. It’s in the philosophy. We’re witnessing the “SaaS-ification” of open source, where vendors wrap dangerous, powerful tools in a slick UI and sell them to developers who don’t want to read the documentation. We’re giving autonomous shell access to software that can be hypnotized by a phishing email. Think about that. We spent the last twenty years firing system administrators who ran scripts they didn’t understand. If a junior admin ran curl | bash from a suspicious URL, we’d walk them out of the building.

Now? Now we’re building billion-dollar businesses on bots that don’t even understand the scripts they write. We’re deploying agents that have the authority of a senior engineer but the judgment of a toddler. The “sovereign” label is dangerous because it lowers your guard. It suggests that because the bits live on your hard drive, the risk is contained. But when that local agent has an open port and a directive to “read my emails and be helpful,” it doesn’t matter where the server is rack-mounted. You haven’t built a sovereign fortress. You’ve installed a persistent, intelligent backdoor and handed the keys to anyone who can write a clever prompt.

2. CISA Director Caught in ChatGPT Scandal

Acting CISA Director Madhu Gottumukkala admitted to uploading sensitive contracting documents to a public instance of ChatGPT. The agency issued guidance on insider threats Friday, January 30. That awkwardly coincided with the internal fallout. The guidance warns against the very behavior their chief exhibited.

Why it matters

• You cannot enforce policy when the person at the top ignores it.

• Even the agency responsible for critical infrastructure struggles to keep data out of public models.

• The “short-term exception” excuse undermines every zero-trust architecture CISA promotes.

What to do about it

• Audit executives. Run a specific check on executive accounts for AI usage. They’re your highest risk users.

• Update your AUP. Explicitly define what “sensitive” means for LLMs. “For Official Use Only” isn’t enough.

• Deploy DLP. Static policy documents don’t stop uploads. You need browser-level enforcement.

Rock’s Musings

This is the classic security hypocrite move, and it’s the single greatest destroyer of security culture in any organization. The Director gets a “temporary exception” to violate the rules because he’s “important” and “busy.” You get a lecture on insider threats and a mandatory 45-minute training video.

This dynamic is why nobody listens to security teams. We’re viewed as the “Department of No” for the peasants, while the aristocracy does whatever they want. Let’s look deeper… Why did he do it? Because the tool is useful. That’s the uncomfortable truth we have to face. He didn’t upload those contracts maliciously. He did it because ChatGPT could summarize them in ten seconds, and he didn’t have an internal tool that could do the same.

Shadow AI isn’t driven by malice. It’s driven by friction. If your secure, approved internal AI takes five minutes to load, requires a VPN, and hallucinates half the time, your executives are going to use ChatGPT. They will paste that top-secret strategy document into the public web because their desire to get the job done outweighs their fear of a theoretical leak. You cannot policy your way out of a utility problem. If you want your engineers and executives to follow the rules, you have to build tools that are better than the contraband. Until then, you’re shouting into the void while your boss pastes the roadmap into OpenAI.

3. Match Group’s Identity Failure

Match Group (parent of Tinder and Hinge) confirmed a data breach on January 30 involving the theft of user data. The threat actor group, ShinyHunters, claimed to have stolen 10 million records. The attack vector wasn’t a sophisticated zero-day in the AI models. It was a social engineering campaign targeting the company’s Okta environment.

Why it matters

• Identity is the perimeter. Attackers didn’t break the encryption. They tricked the admin.

• The use of voice phishing to compromise SSO credentials is becoming the standard entry point for major breaches.

• For a company built on privacy, a breach of this magnitude is a catastrophic failure.

What to do about it

• Enforce FIDO2. Move privileged access to hardware keys. Phone-based 2FA is dead.

• Monitor SSO. Alert on impossible travel and device mismatches for all administrative accounts.

• Drill the help desk. Your support team is the target. Test them on vishing attempts regularly.

Rock’s Musings

We spend millions securing neural networks, buying AI-powered anomaly detection tools, and hardening our Kubernetes clusters. We spend zero on the guy answering the phone at the IT help desk.

ShinyHunters didn’t need a GPU cluster to crack this. They didn’t need a sophisticated prompt injection attack or a zero-day exploit in the kernel. They needed a convincing story and a phone number. This is the “Identity Crisis” of the AI era. As our technical defenses get better, as firewalls get smarter and endpoint protection gets ruthless, attackers pivot to the one operating system that cannot be patched: the human brain.

You’re building a castle on a swamp if your AI security strategy doesn’t start with “fix the identity provider.” We’re seeing a resurgence of old-school con artistry, supercharged by modern tools. Why do attackers need to hack the server when they can just log right on in? This has been happening since the early days of cyber…They’re calling your support team, pretending to be the new VP of Marketing who lost their phone, and getting a bypass code. It’s embarrassing. We talk about “adversarial machine learning” while our front door opens with a polite request. Stop buying AI security tools until you’ve distributed YubiKeys to everyone with admin access. Hardware doesn’t have feelings, and it can’t be charmed by a smooth talker.

4. Ex-Google Engineer Convicted for Theft

A federal jury convicted Linwei Ding on Friday, January 30. The former Google engineer stole over 500 files containing trade secrets about AI supercomputing chips. He was building a rival startup in China while still collecting a paycheck from Google.

Why it matters

• This confirms that the biggest risk to your IP is the employee with a badge.

• This wasn’t a side hustle. It was a coordinated effort to transfer capability to a foreign adversary.

• He uploaded files to his personal Google Cloud account. It took months to catch him.

What to do about it

• Monitor egress. Watch for large uploads to personal cloud storage.

• Review access logs. Ding had access to files he didn’t need. Implement least privilege.

• Background checks. Re-screen employees with access to critical IP.

Rock’s Musings

Google has one of the best security teams in the world. They invented BeyondCorp. They have zero-trust down to a science. And they still missed this for months. Linwei Ding wasn’t using a sophisticated rootkit. He was copying files to his personal notes and uploading them to the cloud.

This destroys the ego of every CISO reading this. If Google can’t stop a determined insider from walking out the door with the crown jewels, neither can you. We pretend that our NDAs are magical force fields. We pretend that background checks done five years ago still matter. They don’t.

The uncomfortable reality is that the modern tech worker is mobile, opportunistic, and often feels no loyalty to the logo on their paycheck. Combine that with the geopolitical gold rush for AI dominance, and you have a recipe for disaster. Your source code, your model weights, your chip designs are liquid assets now. You need technical controls that scream when someone moves a terabyte of data to an unmanaged device. You need to stop looking for “hackers” in hoodies and start watching the quiet engineer who logs in at 2 AM and starts “backing up” his work. Trust is not a control. Trust is a vulnerability.

5. OT Attacks Surge as Hackers Weaponize AI

Forescout released a report on February 4 showing a massive spike in attacks on Operational Technology. The data shows attackers use AI to analyze industrial protocols and find weaknesses. They’re not breaking IT networks. They’re coming for the factory floor.

Why it matters

• OT attacks shut down power plants and manufacturing lines.

• AI lowers the skill required to understand complex industrial protocols like Modbus.

• Attackers use AI to map networks faster than defenders can patch them.

What to do about it

• Segment OT. Air gaps are a myth. Use strict network segmentation.

• Monitor protocols. Standard IDS signatures miss AI-generated anomalies in industrial traffic.

• Patch PLCs. I know it’s hard. Do it anyway.

Rock’s Musings

I spent years telling people that obscurity is not security. The counter-argument from the OT world was always, “But Rock, nobody understands our proprietary 1990s protocol! It’s too weird to hack!”

Well, guess what? Now an AI can read your obscure, dusty documentation, analyze your proprietary protocol, and write a Python script to exploit it in five minutes. The “security by obscurity” defense is dead. Large Language Models murdered it.

We’re entering a terrifying phase where the digital barrier to physical destruction is crumbling. It used to take a nation-state team of experts months to figure out how to spin a centrifuge too fast or shut down a power grid switch. Now, a script kiddie with a customized LLM can parse the traffic and find the “off” command. If your factory runs on Windows 95 and hopes/prayers, you’re in trouble. The industrial world has been lazy, relying on the fact that their systems were too boring and complex to attack. AI doesn’t get bored, and it loves complexity. Wake up and segment your networks before your assembly line holds you for ransom.

6. UNICEF Reports 1.2 Million Deepfake Victims

UNICEF released a horrifying report on February 4. At least 1.2 million children have had their images manipulated into sexually explicit deepfakes in the past year. The barrier to creating this content has dropped to zero.

Why it matters

• This is the darkest side of generative AI.

• Platforms that host or enable this content will face massive regulatory backlash.

• Your employees are parents. This issue affects them personally and will bleed into the workplace.

What to do about it

• Block generation sites. Create distinct categories for “AI generation” in your web filter.

• Support employees. Offer resources for staff dealing with digital harassment.

• Audit your brand. Ensure your own marketing materials aren’t being scraped for these datasets.

Rock’s Musings

This makes me sick. Genuinely turns my stomach. We sit in conference rooms and debate “AI safety” in abstract terms, discussing alignment theory, the singularity, and paperclip maximizers. Real human beings, real children, are getting hurt right now.

The tech industry moved too fast and broke the wrong things. We released powerful image generation tools into the wild with zero safeguards, shrugging our shoulders and saying, “We can’t control how people use it.” That’s a lie. We prioritize growth over safety every single time.

This isn’t a “society” problem. It’s a corporate problem. Your employees are parents. When they come to work terrified because their child is being targeted by classmates using an app you might have invested in, or an open-source model your team is using, that impacts your business. If you build these tools, you have a moral obligation to lock them down. And if you’re a security leader, you need to be the voice in the room asking, “How can this be abused?” before the product ships. We’re failing the most vulnerable people on the planet because we’re too enamored with our own cleverness.

7. Snyk Launches AI Security Fabric

Snyk announced a new “AI Security Fabric” on February 3. The tool claims to unify visibility across the software development lifecycle. It focuses on finding vulnerabilities in AI-generated code and the models themselves.

Why it matters

• We’re finally seeing vendors move beyond point solutions for AI security.

• Catching AI vulnerabilities in the IDE is cheaper than fixing them in production.

• You cannot manually review every line of code Copilot writes. You need automated guardrails.

What to do about it

• Evaluate your stack. If you use Snyk, turn this feature on.

• Scan generated code. Treat AI-written code as untrusted input. Scan it for hardcoded secrets.

• Enforce policy. Block code commits that fail the AI security scan.

Rock’s Musings

I ignore most vendor press releases. They’re fluff and buzzwords. But this one is different because it tacitly admits something important: The AI tools we sold you are making your code worse.

Think about it. Snyk is selling you a vacuum cleaner to clean up the mess that your other AI tools (like Copilot and ChatGPT) are making. Developers are using AI to write code faster, but that code is often insecure, bloated, or hallucinatory. So now we need another AI to watch the first AI and tell us where it screwed up.

It’s a racket. A brilliant, necessary racket. We’re entering the era of “Machine-Assisted Insecurity,” where we generate vulnerabilities at machine speed. Naturally, the only solution is to buy remediation at machine speed. I don’t blame Snyk. They’re filling a void. But let’s be clear about what’s happening: we’re automating the creation of technical debt. If you don’t have a “fabric” or a “platform” or whatever we’re calling it this week to catch this stuff, you’re going to drown in a sea of mediocrity generated by a stochastic parrot.

8. Thailand Warnings on Deepfake Fraud

Thai authorities issued a warning on February 3 about a surge in deepfake fraud targeting working-age professionals. The scams have caused over 23 billion baht in losses. This isn’t elderly people getting tricked. Savvy professionals are falling for AI-generated video calls.

Why it matters

• Scammers are moving upstream to high-value corporate targets.

• Video and voice are no longer proof of identity.

• Thailand is the canary in the coal mine. This tactic is coming to a finance department near you.

What to do about it

• Kill voice auth. Stop using voice recognition for password resets.

• Implement challenge phrases. Establish a verbal code word for authorizing money transfers.

• Train finance teams. Show them what a high-quality deepfake looks like.

Rock’s Musings

I’ve verified this myself, and it’s terrifying. The tools are no longer “research previews.” They’re commodities. You can clone a voice with three seconds of audio. You can face-swap a video call in real-time with a gaming laptop.

The warning from Thailand is significant because it destroys the myth that “only Grandma falls for scams.” These are working-age professionals, finance officers, and managers getting duped. Why? Because our brains are hardwired to trust our senses. If I see your face and hear your voice, my brain says, “That’s you.”

We have to retrain a million years of human evolution in about six months. We have to bring back old-school paranoia. Digital trust is broken. If your CFO calls you on WhatsApp and asks for a wire transfer, you have to assume it’s a lie. Hang up. Call them back on their internal line. Walk down the hall to their office. We need to implement “Challenge Phrases,” like a safe word for corporate finance. It sounds ridiculous, but we’re back to the days of spycraft because the digital medium can no longer be trusted. If you believe your eyes and ears, you will lose your budget.

9. Global Push for US AI Standards

The White House announced on January 30 a plan to advance US AI cybersecurity standards globally. The goal is to get allies to adopt the NIST frameworks and lock out adversaries. This is soft power with a hard edge.

Why it matters

• A fragmented regulatory environment hurts everyone. This might bring some consistency.

• If you want to sell AI to US allies, you’ll need to meet these standards.

• This draws a clear line between “Western” AI governance and the rest of the world.

What to do about it

• Align with NIST. If you’re still using a custom framework, stop. Map everything to the NIST AI RMF.

• Watch the EU. See how this conflicts with the AI Act. You’ll likely have to comply with both.

• Prepare for audits. Global standards mean global certification requirements.

Rock’s Musings

About time. We’ve been letting every country, county, and city council invent their own rules for AI safety. It’s a mess. The internet works because we all agreed on TCP/IP. We didn’t have a “French Internet Protocol” and a “German Internet Protocol.”

AI needs the same thing. I don’t even care if the NIST standard is perfect. I care that it’s common. If we can get the G7 countries to agree on a baseline for what “secure AI” looks like, we can stop wasting time mapping controls between twelve different spreadsheets.

Let’s not be naive. This is also a trade war weapon. By pushing US standards, the White House is trying to ensure that American tech giants write the rules of the road for the next century. If you’re a CISO, this simplifies your life in the long run but complicates it in the short term. You’re going to be the pawn in a regulatory chess match between Washington and Brussels. My advice? Pick NIST as your north star. It’s the most practical, and it’s the one the guys with the aircraft carriers are backing.

10. CISA Plans for an AI-ISAC

On February 3, CISA official Nick Andersen outlined plans to replace the disbanded Critical Infrastructure Council with a new structure. This includes a dedicated focus on AI threat sharing, effectively an “AI-ISAC” (Information Sharing and Analysis Center).

Why it matters

• We currently rely on Twitter threads for AI threat intel. An ISAC brings structure and verification (but we’ll see at what speed).

• When CISA builds an ISAC, regulation follows.

• The focus on industrial control systems suggests the government is worried about AI impacting physical infrastructure.

What to do about it

• Prepare legal. Start the conversation with your legal team about the liability protections required for sharing adversarial AI data.

• Audit intel feeds. If you don’t consume threat data related to AI models, budget for it.

• Volunteer early. If you have the maturity, join the working groups.

Rock’s Musings

We have ISACs for everything. We have an ISAC for water, for automotive, for aviation, for space. But for the technology rewriting the entire global economy, we’ve been relying on random Substack posts and Twitter threads.

It’s absurd that I find out about major jailbreaks from a 19-year-old on X before I hear about it from a government agency. An AI-ISAC is the grown-up table. It’s the move from “AI is a hobby” to “AI is critical infrastructure.”

If you want to know whether that weird prompt injection hitting your chatbot is a random troll or a targeted campaign by a persistent threat actor, you need this data. You need to know what other companies are seeing. Here’s the catch: ISACs only work if you share back. And right now, most companies are terrified to admit they have an AI security problem. We need to get over the shame. If your model gets tricked, share the prompt. It’s the only way we build herd immunity.

The One Thing You Won’t Hear About But You Need To: The EU AI Act’s “Self-Assessment” Trap

While everyone was watching the OpenClawd disaster, a critical change to the EU AI Act went into effect on February 1. The media ignored it. You shouldn’t. The EU has quietly shifted the compliance model for “high-risk” AI systems. Instead of a mandatory external audit by a regulator, the new rule allows “conformity self-assessment” for a wide range of applications.

This sounds like a win. It isn’t. It’s a trap.

By removing the external gatekeeper, the EU has shifted 100% of the liability onto you. There’s no longer a regulator to blame if things go wrong. If your self-assessment is found lacking after an incident, the fines are astronomical. They handed you the rope and told you to tie the knot yourself.

Why it matters

• You’re now the judge and jury of your own compliance. If you’re wrong, you’re also the victim.

• Directors can no longer point to a “passed” regulatory audit as a shield.

• Internal teams will pressure you to sign off on self-assessments to speed up deployment.

What to do about it

• Refuse to sign. Don’t sign a self-assessment without a third-party review. Hire an external firm to “shadow” audit you.

• Update risk registers. Mark every “self-assessed” system as high residual risk.

• Train legal teams. Make sure they understand that “self-assessment” doesn’t mean “optional compliance.”

Rock’s Musings

Regulators are smart. Lazy, but smart. They realized about six months ago that they don’t have the staff, the budget, or the technical talent to audit every AI model in Europe. It’s mathematically impossible. So what did they do? Did they reduce the regulations? No.

They outsourced the enforcement to you.

This is the ultimate “cover your ass” move by the EU. Now, when an AI discriminates against a customer or leaks medical data, the regulator can stand in front of the cameras and say, “We had strict rules! This company certified that they followed them! They lied to us!”

It absolves the government of failure and places the entire burden on your specific signature. Don’t fall for it. Don’t let your product managers bully you into signing a self-assessment to hit a launch date. Treat a self-assessment with more rigor than a government audit, because in a government audit, if they miss something, it’s partly their fault. In a self-assessment, the penalty for lying to yourself is bankruptcy.

If you found this analysis useful, subscribe at rockcybermusings.com for weekly intelligence on AI security developments.

👉 Visit RockCyber.com to learn more about how we can help you in your traditional Cybersecurity and AI Security and Governance Journey

👉 Want to save a quick $100K? Check out our AI Governance Tools at AIGovernanceToolkit.com

👉 Subscribe for more AI and cyber insights with the occasional rant.

Share RockCyber Musings

References

Australian Cyber Security Magazine. (2026, February 2). Cybercriminals hijack AI hosting service to compromise users. https://australiancybersecuritymagazine.com.au/cybercriminals-hijack-ai-hosting-service

Bitdefender. (2026, January 30). Breach at Tinder, Hinge and OkCupid parent Match Group exposes user data. https://www.bitdefender.com/en-us/blog/hotforsecurity/breach-tinder-hinge-okcupid-match-group-exposes-user-data

CyberScoop. (2026, February 3). What’s next for DHS’s forthcoming replacement critical infrastructure protection panel. https://cyberscoop.com/dhs-critical-infrastructure-panel-replacement

Digital Bricks. (2026, February 1). The change to the EU AI Act that no one is talking about. https://digitalbricks.eu/eu-ai-act-self-assessment

IT Security Guru. (2026, February 4). OT attacks surge as threat actors embrace cloud and AI. https://www.itsecurityguru.org/ot-attacks-surge-ai-cloud

Markets Financial Content. (2026, February 5). Openclawd integrates Openclaw: Scaling sovereign AI in the cloud. https://markets.financialcontent.com/openclawd-openclaw-sovereign-ai

Markets Business Insider. (2026, February 3). Snyk unveils the AI Security Fabric. https://markets.businessinsider.com/snyk-ai-security-fabric

Nation Thailand. (2026, February 3). Working-age people targeted by AI deepfake scams, warns AOC 1441. https://www.nationthailand.com/deepfake-scams-working-age

Newsfile Corp. (2026, January 31). OpenClaw introduces secure hosted Clawdbot platform. https://newsfilecorp.com/openclaw-clawdbot-platform

SC Media. (2026, January 30). CISA issues insider threat guidance amidst AI misuse concerns. https://www.scworld.com/cisa-insider-threat-guidance-ai

SC Media. (2026, January 30). Global adoption of US’s AI cybersecurity standards advanced by Trump admin. https://www.scworld.com/us-ai-cybersecurity-standards-global

The Hacker News. (2026, January 30). Ex-Google engineer convicted for stealing AI secrets for China startup. https://thehackernews.com/google-engineer-convicted-ai-secrets-china

UNICEF. (2026, February 4). Deepfake abuse is abuse. https://www.unicef.org/reports/deepfake-abuse

.

Share

NIST released “A Possible Approach for Evaluating AI Standards Development” (GCR 26-069) on January 15, 2026. I read all 30 pages. Then I read them again, looking for the part about security. It’s not there.

The document proposes a theory-of-change methodology to measure whether AI standards achieve their goals. Sounds reasonable. The problem? The entire framework assumes a world where nobody is actively trying to break things. No adversaries. No attackers. No threat actors probing for weaknesses. Just cooperative stakeholders holding hands and measuring outcomes together.

I submitted 33 formal comments. Some of them were polite. Most of them pointed out that you can’t evaluate security standards using a methodology designed for data formatting standards. The two operate in fundamentally different realities.

This is my second formal NIST response this month. Two weeks ago, I submitted comments to the CAISI Request for Information on AI Agent Security, arguing that authorization scope matters more than human oversight for bounding agent risk. I’m starting to see a pattern. NIST asks good questions. Then, NIST proposes frameworks that miss how adversarial environments actually work. It’s exhausting.

Why This Document Made Me Write 33 Comments

I’ve spent the past year and a half contributing to the OWASP GenAI Security Project and the OWASP AI Exchange. When you’ve helped catalog threat categories for AI systems and map mitigations for each, you notice when a “comprehensive” evaluation framework ignores all of them. The OWASP Top 10 for Agentic Applications came out on December 10, 2025. It covers goal hijacking, tool misuse, identity abuse, memory poisoning, cascading failures, and rogue agent behavior. Real risks. Documented incidents.

GCR 26-069 mentions none of this. Zero references to autonomous agents. Zero references to agentic AI. Zero references to multi-agent systems, tool use, or agent coordination. No MITRE ATLAS. No OWASP. No adversarial ML evaluation methods.

You know where cybersecurity experts appear in this document? Once. Buried in a list of stakeholders who might help “reduce the risks of reidentification harm.” That’s a privacy concern. Not a security concern. One mention. As an afterthought.

NIST AI 100-5, the Plan for Global Engagement on AI Standards, identifies “security and privacy” as one of six priority standardization areas. GCR 26-069 is supposed to tell us how to evaluate whether those priority standards work. A methodology that ignores adversarial environments can’t evaluate security effectiveness. It will produce conclusions that sound rigorous and mean nothing.

The timing makes this worse. EU AI Act conformity assessment kicks in August 2026. prEN 18286, the first harmonized standard for AI, entered public enquiry in October 2025. These standards will shape global AI governance. We need evaluation frameworks that actually work for security. This one doesn’t.

The Counterfactual Fantasy

The document loves counterfactual analysis. Box 5 asks: “What would have happened in the alternative state of the world?” For data integration standards, the example used throughout the entire document, this makes sense. You compare outcomes with and without the standard. The underlying process is stable. Apples to apples.

Security doesn’t work that way. Attack rates depend on attacker motivation. Attacker motivation changes when defenses change. You reduce vulnerability in Area A; attackers move to Area B. This is called attack displacement. It’s been documented for decades. Any security professional who’s worked an incident knows this.

Traditional “treatment vs. control” experimental designs fail for security because the control group isn’t static. The adversary adapts. That’s what adversaries do. It’s literally in the name.

Let me make this concrete. You want to evaluate whether an AI security standard reduced incidents. You compare incident rates before and after adoption. Incidents dropped 40%. Victory? Maybe. Or maybe attackers moved to organizations that didn’t adopt the standard. Or they pivoted to attack vectors that the standard doesn’t cover. Or they’re waiting. Attackers are patient when they need to be.

Measuring defender outcomes in adversarial environments produces garbage data dressed up as insight. The framework should measure attacker cost instead. Time-to-compromise increases. Skill threshold required to succeed. Attack surface reduction. Exploit chain complexity. These metrics sidestep the adaptation problem. Even if attackers shift targets, a standard that increases the cost to attackers has demonstrable value.

I proposed adding “Box 5a: Security Counterfactual Considerations.” Apparently, we need to spell out that a security evaluation requires considering attackers.

Process Theater vs. Actual Effectiveness

The document draws a pretty arrow from standards development activities to societal goals. Inputs lead to activities. Activities produce outputs. Outputs generate outcomes. Outcomes achieve goals. It’s a nice diagram. It’s also conflating two completely different questions.

Question one: Did the standards development organization run a good process? Were inputs adequate? Were activities effective? Did outputs ship on time? These evaluate process.

Question two: Does the standard actually work when deployed? Does it reduce harm? Does it resist adversarial exploitation? Does it hold up when someone motivated tries to break it?

These require different methodologies. Different data. Different expertise. Different timeframes. The document mostly focuses on question one while claiming to address question two.

A standard can emerge from a flawless SDO process and still fail operationally. The threat landscape evolved. The attack techniques changed. The assumptions embedded in the standard no longer match reality. Process success doesn’t guarantee effectiveness. Anyone who’s watched a beautifully documented policy get shredded by a real incident understands this.

Security effectiveness requires continuous measurement of deployed systems. Runtime outcomes. Incident response metrics. Vulnerability management data. Threat detection rates. The static theory-of-change model can’t capture any of this. It’s a snapshot methodology applied to a moving target.

I proposed adding an “Operational Feedback Loop” connecting runtime observations back to standards development. Make it iterative instead of linear. Acknowledge that the world changes between when you write a standard and when you evaluate it.

Where’s the Red Team?

The evaluation methodology relies on observational studies, stakeholder surveys, and outcome measurement. For security standards, this is like checking whether a lock works by asking people if they feel safe.

You can survey organizations about their security posture. You can measure incident rates. Neither tells you whether the standard defends against the threats it claims to address. You’re measuring perception and lagging indicators. You’re not measuring actual resistance to attack.

Adversarial testing fills this gap. Red teaming. Penetration testing. Adversarial ML evaluation. These methods actively probe for weaknesses rather than waiting for someone to exploit them. The ICLR 2025 research on AI safeguards found that defenses “often fail against novel attack methods not seen during development.” Minor changes to attack parameters produce dramatically different success rates. Static evaluation misses all of this.

For security-related standards, evaluation should include a red-team assessment of implementations, penetration testing against compliant systems, adversarial ML evaluation using MITRE ATLAS techniques, and comparisons between compliant and non-compliant implementations. This provides direct evidence. Not surveys. Not feelings. Evidence.

The OWASP Top 10 for Agentic Applications offers a ready-made threat taxonomy. Goal hijacking resistance (ASI01). Tool misuse prevention (ASI02). Identity and privilege abuse controls (ASI03). Supply chain integrity (ASI04). Memory poisoning resistance (ASI06). Ten documented risk categories with real incidents behind them. Standards can be evaluated against these attack patterns. We don’t have to wait for the next breach to find out if the standard works.

Validity Problems Nobody Mentioned

Section 2.2 discusses internal validity, construct validity, self-selection bias, and external validity. Standard methodology considerations. All framed for benign interventions where nobody is trying to make you fail.

Security standards face validity threats that the document doesn’t acknowledge…

Adversarial adaptation breaks your baseline. The baseline isn’t stable because attackers respond to defenses. Every security measurement includes this noise.

Security metrics are garbage. Organizations detect and report a fraction of actual intrusions. Your denominator is wrong. Your numerator is wrong. Your confidence interval should be a shrug emoji.

The counterfactual is unobservable. “What would attackers have done?” isn’t something you can measure. You can’t run a controlled experiment on motivated adversaries. They don’t fill out consent forms.

Temporal validity fails fast. A standard effective against 2024 attack techniques may be useless against 2026 techniques. MITRE ATLAS regularly adds new adversarial ML techniques. How long does a security standard remain effective? The framework doesn’t ask.

These aren’t minor gaps. There are fundamental problems with applying this methodology to security standards. The framework needs security-specific validity guidance, or it will produce findings that look rigorous and mislead everyone who reads them.

What I Told NIST

My 33 comments include specific recommendations. Not just complaints. Fixes.

First, add a security-focused illustrative example. The document uses data integration throughout. Fine. Add a parallel example, such as “Autonomous Agent Credential Management,” that walks through the same structure with security-centric measures. Show how security inputs differ (threat intelligence, red team findings, incident data). Show security-specific activities (adversarial testing, penetration testing). Show security outputs (threat coverage matrices, attack resistance specifications). Show security outcomes (attacker cost increase, exploit chain complexity). Show security goals (adversarial robustness, resilience under attack). Make the framework demonstrate that it can handle security. Don’t just assume it.

Second, add Adversarial Evaluators as a stakeholder category. Traditional stakeholder engagement assumes cooperative participants seeking shared outcomes. Security evaluation requires people who deliberately adopt attacker mindsets. Red team operators. Penetration testers. Adversarial ML researchers. Threat intelligence analysts. Their value comes from challenging consensus, not building it. That’s how you formally integrate adversarial perspectives.

Third, distinguish voluntary from mandatory conformity outcomes. The EU AI Act creates a binary measure: whether an AI standard meets the “presumption of conformity” under Article 40. This should be an explicit evaluation criterion. Voluntary conformity exhibits self-selection bias. Mandatory conformity creates natural experiments. Different mechanisms. Different evaluation approaches.

Fourth, specify measurement infrastructure requirements. Security evaluation requires telemetry from deployed systems, threat intelligence feeds, vulnerability databases, and incident reporting mechanisms. Without this infrastructure, security outcomes are unmeasurable. The document should specify which data-collection capabilities are prerequisites for meaningful evaluation. Otherwise, people will try to evaluate security standards without the data needed to do it.

Key Takeaway: This framework will produce misleading conclusions about security standards because it ignores adversarial adaptation, conflates process with effectiveness, and lacks a methodology for measuring what actually matters: whether standards increase the cost to attackers.

What to do next

If you’re responsible for AI security standards adoption, don’t confuse compliance with security. A standard that emerged from a rigorous SDO process can still fail operationally if threats evolved since publication. Build your own threat-informed evaluation. Don’t trust process-focused assessments to tell you whether you’re actually protected.

For organizations building AI governance programs, the CARE Framework provides structured risk assessment that accounts for adversarial considerations. The RISE Framework addresses organizational readiness for the continuous evaluation that AI security demands.

NIST welcomes feedback on GCR 26-069 via email to ai-standards@nist.gov. They’re planning an online event to discuss the approach. The CAISI AI Agent RFI comment period runs through March 9, 2026. If you haven’t read my analysis of why authorization scope beats human oversight for agent security, the arguments connect to what I’ve outlined here. Both documents share the same blind spot.

More security practitioners need to engage with these processes. Otherwise, NIST guidance will reflect the views of people who’ve never had to defend a production system against a motivated attacker.

👉 Subscribe for more AI security and governance insights with the occasional rant.

👉 Visit RockCyber.com to learn more about how we can help you in your traditional Cybersecurity and AI Security and Governance Journey

👉 Want to save a quick $100K? Check out our AI Governance Tools at AIGovernanceToolkit.com

Share RockCyber Musings

Share

Another week, another Fortinet zero-day. At this point, I’m starting to wonder if Fortinet’s security team schedules their patch releases around my newsletter deadlines. But this week brought more than the usual perimeter carnage. 22% of enterprises have employees running Moltbot without IT approval, and the tool’s security architecture is a mess of exposed admin ports and plaintext credentials. North Korean hackers deployed what appears to be the first AI-generated APT malware caught in the wild. And DeepSeek left over a million user conversations sitting in a publicly accessible database. If you’re still wondering whether AI security belongs on your board’s agenda, stop wondering.

The through-line connecting this week’s chaos is execution speed. Attackers are automating faster than defenders can patch. AI coding assistants are spreading faster than security teams can evaluate them. Criminal infrastructure now operates at scales that require coordinated industry response. The gap between vulnerability disclosure and weaponization continues shrinking toward zero.

For CISOs, the implications are clear: your security program’s velocity determines your exposure window. Patch management isn’t a quarterly exercise anymore. Neither is shadow IT discovery. Both are competitive advantages.

1. Fortinet’s 14th Zero-Day in Four Years Proves Perimeter Security is a Leaky Boat

Fortinet disclosed CVE-2026-24858, a critical authentication bypass vulnerability in FortiCloud SSO affecting FortiOS, FortiManager, FortiAnalyzer, FortiProxy, and FortiWeb. The flaw earned a CVSS score of 9.4. Attackers exploited it in the wild before disclosure, creating backdoor admin accounts and exfiltrating device configurations. CISA added it to the Known Exploited Vulnerabilities catalog on January 27 with a February 13 remediation deadline. Arctic Wolf observed attacks executing within seconds of identifying vulnerable targets (BleepingComputer). Coalition Insurance noted that this is Fortinet’s 14th zero-day advisory in less than 4 years (CyberScoop).

Why it matters

• Attackers targeted fully-patched systems, meaning regular patching alone provided no protection

• Automated exploitation windows have collapsed to seconds, not hours or days

• Configuration exfiltration enables follow-on attacks even after patching

What to do about it

• Apply the January 28 patches immediately if you haven’t already

• Audit all Fortinet admin accounts created since January 20 for unauthorized entries

• Review VPN configurations for unexpected changes and rotate credentials for affected devices

Rock’s Musings

Fourteen zero-days in four years. Let that sink in. At some point, we need to have an honest conversation about whether network perimeter appliances create more attack surface than they protect. These devices sit at the edge of your network with broad privileges, and every vendor in this space has gotten hammered.

I’m not saying ditch your firewall tomorrow, but if your security strategy depends on the assumption that your perimeter devices are secure, you’re building on sand. The attackers who exploited this flaw created backdoor accounts and exfiltrated configs before Fortinet knew the vulnerability existed. Your zero-trust architecture shouldn’t be a slide deck. It should be your insurance policy for exactly this scenario. For more on building resilient security architecture, visit RockCyber.

2. Moltbot’s Exploding Security Crisis Threatens Every Organization Using AI Coding Assistants

While the fake VS Code extension grabbed headlines, the deeper story involves Moltbot’s own security architecture. Security researchers have found hundreds of exposed Moltbot instances running with unauthenticated admin ports accessible from the internet. Credentials and API keys appear in plaintext in configuration files. Token Security found that 22% of their enterprise customers have employees running Moltbot without IT knowledge or approval (The Register). A proof-of-concept supply chain attack via MoltHub achieved 4,000 downloads in under eight hours. Google VP of Security Engineering Heather Adkins publicly warned: “Don’t run Clawdbot.”

Why it matters

• Moltbot has direct access to source code, development infrastructure, and secrets

• Shadow IT adoption has outpaced security evaluation for these tools

• The attack surface includes not just the tool itself but the entire ecosystem of extensions and integrations

What to do about it

• Conduct an immediate audit of Moltbot usage across your organization including personal devices

• If Moltbot is approved for use, ensure instances run behind authentication and network segmentation

• Establish formal evaluation and approval processes for AI coding assistants before developers adopt them independently

Rock’s Musings

This is the story that should terrify every CISO, and it’s barely making news outside security circles.

Moltbot and similar AI coding assistants represent a category of tooling that didn’t exist two years ago. They’re now running on developer machines across your organization, often without security review, often with access to your most sensitive assets: source code, API keys, production credentials, deployment pipelines.

The 22% figure from Token Security means nearly a quarter of enterprise employees are running AI coding tools their IT departments don’t know about. These tools ask for broad file system access, network connectivity, and permission to execute code. When one of them is compromised or misconfigured, attackers get everything.

We’ve spent years hardening our software supply chains against malicious packages and compromised libraries. AI coding assistants represent the same class of risk but with broader access and less scrutiny. If you don’t have visibility into what AI tools your developers are running, you don’t understand your attack surface. Fix that before you become this year’s case study.

3. Sandworm Drops DynoWiper on Poland’s Power Grid, Marking Decade Anniversary of Ukraine Blackout

Russia’s GRU-linked Sandworm group deployed a new wiper malware called DynoWiper against Poland’s power grid on December 29-30, 2025. ESET publicly attributed the attack on January 24, 2026. The attack targeted two heat-and-power plants plus renewable energy management systems. Polish authorities thwarted the attack before it caused disruption, but stated it could have affected 500,000 people (ESET). The timing coincided with the 10-year anniversary of Sandworm’s 2015 BlackEnergy attack, which caused Ukraine’s first malware-induced blackout. Dragos reported that some equipment was damaged beyond repair, despite the defense's operational success (The Register).

Why it matters

• This is the first destructive cyberattack against a NATO member’s critical infrastructure attributed to a nation-state

• Sandworm’s operational tempo and capability continue escalating despite years of sanctions and indictments

• Even unsuccessful attacks can cause physical equipment damage

What to do about it

• Critical infrastructure operators should review network segmentation between IT and OT environments

• Implement anomaly detection specifically for wiper malware behaviors, including mass file deletion and MBR overwrites

• Coordinate with national CERTs and ISACs for threat intelligence on Sandworm TTPs

Rock’s Musings

Poland won this fight. That’s worth acknowledging. Their €1 billion cybersecurity budget and daily experience fending off 20-50 attacks created the defensive muscle memory needed to stop Sandworm’s wiper before it caused blackouts. Most countries facing this threat don’t have that operational maturity.

The anniversary timing isn’t a coincidence. It’s psychological warfare. 10 years after proving they could cut off Ukraine’s power, Sandworm wanted to demonstrate they could reach NATO infrastructure. They failed operationally but succeeded at the message: we’re here, we’re capable, and your critical infrastructure isn’t safe. If you run OT environments, assume you’re already a target and plan your defenses accordingly.

4. DeepSeek Leaves Over a Million User Conversations in Publicly Accessible Database

Wiz Research discovered on January 29 that the Chinese AI company DeepSeek had left a ClickHouse database publicly accessible and unauthenticated. The exposed data included over one million records containing chat histories, API keys, backend logs, and system metadata (Wiz). The database was secured after Wiz’s disclosure, but the exposure duration remains unknown. This discovery came amid ongoing regulatory scrutiny of DeepSeek’s data practices, including an Italian investigation into GDPR compliance and government bans in Australia, Taiwan, and South Korea (The Hacker News). Cisco security testing found DeepSeek’s R1 model failed to block any jailbreak attempts, suggesting broader security architecture issues.

Why it matters

• Chat histories with an AI assistant can contain sensitive personal, business, and technical information

• API key exposure enables unauthorized access to paid services and potential impersonation

• The combination of weak application security and aggressive data collection creates compounding risks

What to do about it

• Audit your organization for unauthorized DeepSeek usage, particularly among technical staff

• If you’ve used DeepSeek, assume any data shared with it may have been exposed, and rotate relevant credentials

• Update acceptable use policies to address emerging AI services and their data handling practices

Rock’s Musings

DeepSeek burst onto the scene as the cheap, capable Chinese alternative to OpenAI. Security researchers have been poking at it for weeks, and every examination reveals new problems. Cisco found it fails 100% of jailbreak tests. KELA demonstrated it can be manipulated to produce dangerous outputs. Now, Wiz shows they left the database unlocked.

This isn’t a case of sophisticated attackers finding obscure flaws. This is a basic operational security failure. If DeepSeek can’t keep its own database locked, why would you trust it with your organization’s conversations? I get the appeal of cost-effective AI tools. But cheap becomes expensive fast when your data ends up in an open database. For guidance on evaluating AI tool risks, check out Rock’s Cyber Musings.

5. Google Dismantles IPIDEA Proxy Network Used by 550+ Threat Groups

Google’s Threat Intelligence Group announced on January 29 the disruption of IPIDEA, one of the world’s largest residential proxy networks. In a single week in January 2026, Google observed more than 550 threat groups from China, DPRK, Iran, and Russia using IPIDEA exit nodes (Google Cloud Blog). The operation involved legal action against command-and-control domains, coordination with Cloudflare for DNS disruption, and Google Play Protect blocking infected apps. Google identified 600+ trojanized Android apps and 3,000+ Windows binaries distributing IPIDEA’s proxy software. The disruption reduced IPIDEA’s available device pool by millions (The Register).

Why it matters

• Residential proxies allow attackers to hide malicious traffic behind legitimate consumer IP addresses, evading geographic and reputation-based blocking

• The scale of 550+ threat groups using a single infrastructure reveals how criminals share operational resources

• Users whose devices were enrolled became unwitting participants in attacks and exposed their own networks to compromise

What to do about it

• Block known IPIDEA IP ranges at your network perimeter where feasible

• Implement network traffic analysis capable of detecting residential proxy behavior patterns

• Educate users about the risks of apps promising to “monetize” their bandwidth

Rock’s Musings

550 threat groups. One proxy network. One week. That’s the scale of the shared infrastructure criminals operate today.

Google deserves credit for coordinating this disruption. Taking down distributed infrastructure requires legal action, technical coordination across multiple companies, and sustained effort. But IPIDEA isn’t unique. It operated 19 residential proxy brands under centralized control. When this one gets degraded, criminals will migrate to competitors.

The deeper problem is the business model: pay app developers to embed proxy SDKs, enroll millions of devices without clear user consent, then sell access to anyone willing to pay. Until we address that economic model, these networks will keep regenerating. Your defense can’t depend on Google’s enforcement efforts. Assume attackers will always have residential IP access and design your detection accordingly.

6. North Korean Konni Group Deploys AI-Generated Malware Against Blockchain Developers

Check Point Research reported on January 23 that the North Korean Konni group (also known as Opal Sleet/TA406) is using AI-generated PowerShell malware to target blockchain developers in Japan, Australia, and India. The malware exhibits clear signs of LLM-assisted development, including structured documentation, modular code layout, and placeholder comments like “# ← your permanent project UUID” that are characteristic of AI-generated code (BleepingComputer). Attacks begin with Discord-hosted phishing links delivering ZIP archives containing malicious LNK shortcuts. This campaign marks a shift from Konni’s traditional focus on South Korean diplomatic targets toward APAC blockchain and cryptocurrency developers (Check Point).

Why it matters

• This is among the first documented cases of APT groups using AI to accelerate malware development

• AI-assisted malware can iterate faster and customize more easily, challenging signature-based detection

• The targeting shift toward blockchain developers indicates North Korea’s continued focus on cryptocurrency theft

What to do about it

• Brief blockchain and cryptocurrency development teams on targeted spear-phishing tactics

• Block Discord CDN URLs at the perimeter or implement additional inspection for files downloaded from Discord

• Update endpoint detection rules to identify PowerShell behaviors associated with AI-generated code patterns

Rock’s Musings

We’ve been warning about AI-assisted malware as a future threat. The future arrived this week.

What makes this significant isn’t that the malware is dramatically more sophisticated. It’s that the development process accelerated. Clean documentation. Modular structure. Placeholder comments explaining customization. The Konni operators didn’t become better programmers. They got faster.

For defenders, the implication is uncomfortable. Threat actors who previously took weeks to develop custom tooling can now iterate in days or hours. The asymmetry that favored attackers just got worse. Your threat models need updating. Your detection capabilities need to assume a higher adversary velocity. And your developers working on anything cryptocurrency-related need to understand they’re targets, not just builders.

7. CISA Adds VMware vCenter Vulnerability to KEV Catalog After Active Exploitation Confirmed

CISA added CVE-2024-37079, a critical heap overflow vulnerability in VMware vCenter Server, to its Known Exploited Vulnerabilities catalog on January 23, 2026. The vulnerability carries a CVSS score of 9.8 and allows unauthenticated remote code execution via specially crafted network packets (CISA). Broadcom updated its security advisory on January 23 to confirm active exploitation in the wild, seven months after patches were first released in June 2024. Federal civilian agencies must remediate by February 13, 2026 (BleepingComputer). The vulnerability affects the DCE/RPC protocol implementation in vCenter Server.

Why it matters

• vCenter Server is the management plane for VMware environments, making it a high-value target

• The seven-month gap between patch availability and confirmed exploitation highlights the cost of delayed patching

• Unauthenticated RCE vulnerabilities in the management infrastructure enable complete environment compromise

What to do about it

• Verify all vCenter Server instances are patched to versions released after June 2024

• Restrict network access to vCenter management interfaces to authorized administrator networks only

• Review vCenter audit logs for evidence of exploitation attempts since June 2024

Rock’s Musings

This vulnerability was patched seven months ago. Let that be your reminder that attackers don’t follow your quarterly patch cycle.

The pattern is familiar: critical vulnerability disclosed, patch released, organizations deprioritize because “we haven’t seen exploitation yet,” then CISA adds it to the KEV catalog confirming it’s being actively exploited. The time to patch was June 2024. The second-best time is right now.

vCenter compromise gives attackers access to your entire virtualized infrastructure. They can access VMs, exfiltrate data, and move laterally without touching the network. If you’ve been treating vCenter patching as lower priority because it’s “just management infrastructure,” you’ve had the risk assessment backwards.

8. Fake AI Coding Assistant Drops Remote Access Malware on VS Code Users

Aikido Security detected on January 27 a malicious Visual Studio Code extension named “ClawdBot Agent - AI Coding Assistant” mimicking the legitimate Moltbot coding tool. The extension dropped ConnectWise ScreenConnect for remote access on victims’ machines (The Hacker News). Microsoft removed the extension from the VS Code Marketplace after notification. The attack capitalized on Moltbot’s popularity, which has over 85,000 GitHub stars. This incident follows broader concerns about Moltbot’s security posture, including hundreds of exposed instances with unauthenticated admin ports and API keys stored in plaintext (BleepingComputer).

Why it matters

• Developer tools represent high-value targets with access to source code, secrets, and infrastructure credentials

• The VS Code Marketplace’s extension approval process allowed a malicious extension to reach users

• Supply chain attacks targeting developers can compromise entire software ecosystems

What to do about it

• Audit VS Code extensions installed across your development environment for suspicious entries

• Implement allowlisting for approved extensions rather than relying on marketplace vetting alone

• Scan for ConnectWise ScreenConnect installations that weren’t deployed by IT

Rock’s Musings

Developers downloading coding assistants from official marketplaces expect some baseline vetting. That expectation is increasingly misplaced. The VS Code Marketplace, npm, PyPI, and every other package repository has become an attack surface.

This particular attack got caught quickly because Aikido was watching. How many similar attacks have succeeded without detection? The extension was named to exploit confusion with a popular legitimate tool. The payload was commodity remote access software. This isn’t sophisticated. It’s opportunistic, scalable, and apparently effective enough to keep happening.

If your developers install their own tools without security review, you have supply chain exposure you’re not measuring. The answer isn’t locking everything down and killing productivity. It’s building detection capabilities that catch malicious tooling when it inevitably slips through.

9. WEF Report: 94% of Leaders Expect AI to Dominate Cybersecurity in 2026

The World Economic Forum released its Global Cybersecurity Outlook 2026 report in January, surveying executives and security leaders worldwide. Key findings: 94% expect AI to be the most consequential force shaping cybersecurity this year. 87% reported experiencing rising AI-related vulnerabilities in 2025. Cyber-enabled fraud has overtaken ransomware as CEOs’ top concern. 31% of respondents expressed low confidence in their nation’s ability to respond to critical infrastructure attacks, up from 26% the previous year (World Economic Forum). The report noted that 64% of organizations now factor geopolitically motivated attacks into their risk strategies.

Why it matters

• The perception gap between AI as an opportunity and AI as a threat continues widening

• CEO concern shifting from ransomware to fraud reflects changing attacker economics

• Declining confidence in national cyber preparedness signals growing infrastructure vulnerability

What to do about it

• Update board reporting to address AI-specific security risks alongside traditional threat categories

• Review fraud detection capabilities given the shifting attacker focus toward BEC and social engineering

• Incorporate geopolitical threat intelligence into risk assessments for organizations with international exposure

Rock’s Musings

Survey says: everyone thinks AI will change everything. This tracks with what I hear from every CISO I talk to. The challenge is translating that awareness into operational reality.

What caught my attention is the shift from fraud to ransomware. Ransomware gets the headlines and the policy attention. But fraud, phishing, and BEC attacks now worry CEOs more. Why? Because they’re working. Ransomware payments are declining as organizations improve backups and refuse to pay. Fraud attacks are getting more convincing thanks to deepfakes and AI-generated content.

The 31% expressing low confidence in national cyber preparedness should concern policymakers. If a third of security leaders don’t trust their country’s ability to respond to critical infrastructure attacks, that’s a vote of no confidence in government cyber capabilities. Poland just demonstrated that good national defense is possible. Most countries haven’t made those investments.

10. EU AI Act High-Risk Deadlines Loom as Code of Practice Deadline Passes

The EU AI Office’s first draft Code of Practice on AI-generated content transparency closed for feedback on January 23, 2026. High-risk AI system provisions take effect August 2, 2026, giving organizations roughly six months to achieve compliance. The EU AI Office gains full enforcement authority on that date, with fine authority reaching 3% of global turnover (EU AI Act). The European Commission’s Digital Omnibus proposal aims to streamline compliance requirements across overlapping regulations, including the AI Act, GDPR, and Digital Services Act. Each member state must establish at least one regulatory sandbox by August 2, 2026 (K&L Gates).

Why it matters

• Six months to compliance is insufficient for organizations that haven’t started preparation

• 3% global turnover fines rival GDPR enforcement exposure for major violations

• Regulatory sandbox requirements signal an EU intent to enable compliant AI development, not just prohibit violations

What to do about it

• Inventory AI systems and classify against EU AI Act risk categories immediately if you haven’t already

• Engage legal counsel with EU AI Act expertise to assess compliance gaps for high-risk systems

• Monitor member state sandbox programs for compliance pathways relevant to your AI use cases

Rock’s Musings

Six months until the high-risk provisions take effect. If your organization uses AI in healthcare, education, employment, or critical infrastructure, and you’re reading about EU AI Act compliance for the first time, you’re behind.

I’ve talked to organizations that assume they can treat AI compliance like early GDPR: wait for enforcement actions, learn from others’ mistakes, then respond. That worked poorly for GDPR. It will work less well here because the AI Act’s technical requirements require architectural changes, not just policy updates.

The silver lining is regulatory sandboxes. The EU is signaling that it wants to enable compliant AI development, not just punish violations. If you’re building AI systems that might face scrutiny, engaging with sandbox programs early gives you a compliance pathway and a regulator relationship that pure avoidance strategies lack.

The One Thing You Won’t Hear About But You Need To

WhatsApp Launches Lockdown Mode for High-Risk Users

Meta announced WhatsApp’s new “Strict Account Settings” feature on January 27, providing a one-click security mode for journalists, activists, and other high-risk users. The feature blocks media from unknown senders, disables link previews, silences calls from unknown contacts, and enables two-step verification by default (BleepingComputer). The announcement follows similar offerings from Apple (Lockdown Mode, 2022) and Google (Android Advanced Protection Mode, 2025). Citizen Lab researcher John Scott-Railton called the announcement “a very welcome development” (TechRepublic). The rollout comes days after Meta faced a lawsuit alleging false privacy claims, which WhatsApp head Will Cathcart called “a no-merit, headline-seeking lawsuit.”

Why it matters

• WhatsApp’s 2+ billion users include many potential targets of state-sponsored surveillance

• Zero-click exploits often leverage media processing and link previews as attack vectors

• Industry standardization of “lockdown modes” creates consistent expectations for high-risk user protection

What to do about it

• Identify employees in high-risk roles and recommend enabling Strict Account Settings

• Update security awareness training to cover lockdown features across platforms

• Review organizational policies for communication tools used by executives and other potential targets

Rock’s Musings

WhatsApp, Apple, and Google now all offer lockdown modes for high-risk users. The security industry has normalized the idea that some people face threats requiring extreme countermeasures. That’s progress.

The features themselves are common sense: block unknown attachments, disable link previews, mute unknown callers. These are attack vectors that spyware vendors have exploited for years. What took so long? Better late than never, I suppose.

If you have employees who might be targeted by nation-states or sophisticated criminals, talk to them about these features. Executives, journalists, researchers, and anyone handling sensitive information. The threat isn’t theoretical. Pegasus infections happen. These tools aren’t perfect protection, but they meaningfully shrink the attack surface.

If you found this analysis useful, subscribe at rockcybermusings.com for weekly intelligence on AI security developments.

👉 Visit RockCyber.com to learn more about how we can help you in your traditional Cybersecurity and AI Security and Governance Journey

👉 Want to save a quick $100K? Check out our AI Governance Tools at AIGovernanceToolkit.com

👉 Subscribe for more AI and cyber insights with the occasional rant.

Share RockCyber Musings

References

Aikido Security. (2026, January 27). Malicious VS Code extension analysis. https://www.aikido.dev

BleepingComputer. (2026, January 23). Konni hackers target blockchain engineers with AI-built malware. https://www.bleepingcomputer.com/news/security/konni-hackers-target-blockchain-engineers-with-ai-built-malware/

BleepingComputer. (2026, January 24). CISA adds actively exploited VMware vCenter flaw to KEV catalog. https://www.bleepingcomputer.com/news/security/cisa-warns-of-actively-exploited-vmware-vcenter-flaw/

BleepingComputer. (2026, January 27). Fortinet warns of new zero-day actively exploited in attacks. https://www.bleepingcomputer.com/news/security/fortinet-warns-of-new-zero-day-actively-exploited-in-attacks/

BleepingComputer. (2026, January 28). New WhatsApp lockdown feature protects high-risk users from hackers. https://www.bleepingcomputer.com/news/security/whatsapp-gets-new-lockdown-feature-that-blocks-cyberattacks/

BleepingComputer. (2026, January 29). Google disrupts IPIDEA proxy network abused by criminals. https://www.bleepingcomputer.com/news/security/google-disrupts-ipidea-proxy-network-abused-by-criminals/

Broadcom. (2026, January 23). VMSA-2024-0012.1: VMware vCenter Server security advisory update. https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/24453

Check Point Research. (2026, January 23). AI-powered KONNI malware targets developers. https://blog.checkpoint.com/research/ai-powered-north-korean-konni-malware-targets-developers

CISA. (2026, January 23). CISA adds one known exploited vulnerability to catalog. https://www.cisa.gov/news-events/alerts/2026/01/23/cisa-adds-one-known-exploited-vulnerability-catalog

CISA. (2026, January 27). CISA adds Fortinet vulnerability to KEV catalog. https://www.cisa.gov/known-exploited-vulnerabilities-catalog

CyberScoop. (2026, January 28). Coalition Insurance issues 14th Fortinet zero-day advisory. https://cyberscoop.com/fortinet-zero-day-coalition-insurance-advisory/

ESET. (2026, January 24). ESET Research: Sandworm behind cyberattack on Poland’s power grid in late 2025. https://www.welivesecurity.com/en/eset-research/eset-research-sandworm-cyberattack-poland-power-grid-late-2025/

EU AI Act. (2026). High-risk AI system requirements and enforcement timeline. https://artificialintelligenceact.eu/

Fortinet. (2026, January 27). FortiCloud SSO authentication bypass vulnerability advisory. https://www.fortinet.com/psirt

Google Cloud Blog. (2026, January 29). Disrupting IPIDEA: Taking action against residential proxy abuse. https://cloud.google.com/blog/topics/threat-intelligence/disrupting-ipidea-residential-proxy

Help Net Security. (2026, January 26). ESET attributes DynoWiper-powered attack on Poland’s power grid to Russia-aligned Sandworm group. https://www.helpnetsecurity.com/2026/01/26/poland-energy-malware-attack/

K&L Gates. (2026, January). EU AI Act compliance update: High-risk deadlines and regulatory sandboxes. https://www.klgates.com/

TechRepublic. (2026, January 28). WhatsApp adds one-tap security settings for added privacy. https://www.techrepublic.com/article/news-whatsapp-strict-account-settings-lockdown-security-mode/

The Hacker News. (2026, January 26). Konni hackers deploy AI-generated PowerShell backdoor. https://thehackernews.com/2026/01/konni-hackers-deploy-ai-generated.html

The Hacker News. (2026, January 28). Fake Moltbot VS Code extension drops remote access malware. https://thehackernews.com/2026/01/fake-moltbot-vscode-extension.html

The Hacker News. (2026, January 30). Italy blocks DeepSeek over data privacy concerns. https://thehackernews.com/2026/01/italy-blocks-deepseek-privacy.html

The Register. (2026, January 26). ESET: Russia likely behind Poland power grid attack. https://www.theregister.com/2026/01/26/moscow_likely_behind_wiper_attack/

The Register. (2026, January 27). Fake AI coding assistant malware hits VS Code marketplace. https://www.theregister.com/2026/01/27/moltbot_vscode_malware/

The Register. (2026, January 29). Google cripples IPIDEA proxy network abused by crims. https://www.theregister.com/2026/01/29/google_ipidea_crime_network/

Wiz Research. (2026, January 29). DeepSeek database exposure analysis. https://www.wiz.io/blog/deepseek-database-exposed

World Economic Forum. (2026, January 12). Global Cybersecurity Outlook 2026. https://reports.weforum.org/docs/WEF_Global_Cybersecurity_Outlook_2026.pdf

Zetter, K. (2026, January 28). Cyberattack targeting Poland’s energy grid used a wiper. Zero Day. https://www.zetter-zeroday.com/cyberattack-targeting-polands-energy-grid-used-a-wiper/