The LiteLLM Supply Chain Cascade: Empirical Lessons in AI Credential Harvesting and the Future of Infrastructure Assurance

By Ramkumar Sundarakalatharan | March 27, 2026 | Comments 0 Comment

TL:DR: This is an Empirical Study and could be quite long for non-researchers. If you’d prefer the remediation protocol directly, you can head to the bottom. In case you want to understand the anatomy of the attack and background, I have made a video that can be a quick explainer.

Background and Summary:

The compromise of the LiteLLM Python library in March 2026 stands as a definitive case study in the fragility of modern AI infrastructure. LiteLLM, an open-source API gateway, acts as a critical abstraction layer enabling developers to interface with over 100 LLM providers through a unified OpenAI-style format.¹ It effectively becomes the central node through which an organisation’s most sensitive AI credentials, including keys for OpenAI, Anthropic, Google Vertex AI, and Amazon Bedrock, are routed and managed.² Its scale is reflected in its reach, averaging approximately 97 million downloads per month on PyPI.³

On 24 March 2026, malicious actors identified as TeamPCP published two poisoned versions, 1.82.7 and 1.82.8, directly to PyPI.³ The choice of target was deliberate. By compromising a package designed to centralise AI credentials, the attackers positioned themselves for broad and immediate access across multiple providers. The breach impacted high-profile organisations such as NASA, Netflix, Stripe, and NVIDIA, underscoring LiteLLM’s deep integration into production environments.⁵

The attack itself leveraged a subtle but powerful mechanism. Version 1.82.8 introduced a malicious .pth file, ensuring code execution at Python interpreter startup, regardless of whether the library was imported.⁴ This effectively turned installation into a compromise. Detection, however, did not come from security tooling. A flaw in the attacker’s implementation triggered an uncontrolled fork bomb, exhausting system resources and crashing machines.⁵ This failure, described as “vibe coding”, became the only signal that exposed the breach, likely preventing widespread, silent exfiltration across production systems.

The Architectural Criticality of LiteLLM and the Blast Radius

The positioning of LiteLLM within the AI stack represents a classic single point of failure. Modern enterprise AI deployments often involve multiple providers to balance cost, latency, and performance requirements. LiteLLM provides the necessary proxy logic to handle these providers through a single endpoint. Consequently, the environment variables and configuration files associated with LiteLLM deployments house a concentrated wealth of sensitive information.

LiteLLM Market Penetration and Integration Scale

Metric	Value / Entity
Monthly Downloads (PyPI)	95,000,000 – 97,000,000 ³
Daily Download Average	~3.4 – 3.6 Million ³
Direct Institutional Users	NASA, Netflix, NVIDIA, Stripe ³
Transitive Dependencies	DSPy, CrewAI, MLflow, Open Interpreter ²
GitHub Stars	> 40,000 ⁵
Cloud Presence	Found in ~36% of cloud environments ⁸

The blast radius of the March 24th incident extended far beyond direct users of LiteLLM. The library is a frequent transitive dependency for a wide range of AI frameworks and orchestration tools. Organizations using DSPy for building modular AI programs or CrewAI for agent orchestration inadvertently pulled the malicious versions into their environments without ever explicitly initiating a pip install litellm command.² This highlights a fundamental tension in the AI development cycle: the speed of adoption for agentic AI tools has outpaced the visibility that security teams have into the underlying software supply chain.²

The Anatomy of the Poisoning: Versions 1.82.7 and 1.82.8

The poisoning of the LiteLLM package was conducted with a high degree of stealth, bypassing the project’s official GitHub repository entirely. The malicious versions were published straight to PyPI using stolen credentials, meaning there were no corresponding code changes, release tags, or review processes visible to the community on GitHub until after the damage had been initiated.³

Technical Divergence in Malicious Releases

In version 1.82.7, the attackers injected 12 lines of obfuscated, base64-encoded code into the litellm/proxy/proxy_server.py file.2 This payload was designed to trigger during the import of the litellm.proxy module, which is the standard procedure for users deploying LiteLLM as a proxy server. While effective, this required the package to be active to execute its malicious logic.9Version 1.82.8, however, utilised the much more aggressive .pth file mechanism. The attackers included a file named litellm_init.pth (approximately 34,628 bytes) within the package root.⁹ In Python, .pth files are automatically processed and executed during the interpreter’s initialisation phase. By placing the payload here, the attackers ensured that the malware would fire the second the package existed in a site-packages directory on the machine, whether it was imported or not.⁴ This mechanism is particularly dangerous in environments where AI development tools or language servers (like those in VS Code or Cursor) periodically scan and initialise Python environments in the background.⁵

Execution Triggers and Persistence Mechanisms

The .pth launcher in version 1.82.8 utilised a subprocess. Popen call to execute a second Python process containing the actual data-harvesting payload.10 Because the initialisation logic was flawed, an oversight attributed to “vibe coding”, this subprocess itself triggered the .pth file again, initiating a recursive chain of process creation.⁹ The resulting exponential fork bomb can be described by the function N(t)= 2^t, where ^N is the number of processes and ^t is the number of initialisation cycles. Within a matter of seconds, the affected machines became unresponsive, leading to the crashes that ultimately exposed the operation.⁹

The Discovery: FutureSearch and the Cursor Connection

The identification of the LiteLLM compromise began with a developer at FutureSearch, Callum McMahon, who was testing a Model Context Protocol (MCP) plugin within the Cursor AI editor.² The plugin utilised the uvx tool for Python package management, which automatically pulled in the latest version of LiteLLM as an unpinned transitive dependency.⁹When the Cursor IDE attempted to load the MCP server, the uvx tool downloaded LiteLLM 1.82.8. Almost immediately, the developer’s machine became unresponsive due to RAM exhaustion.⁹ Upon investigation using the Claude Code assistant to help root-cause the crash, McMahon identified the suspicious litellm_init.pth file and traced it back to the newly published PyPI release.⁷ This discovery highlights a significant security gap in the current AI agent ecosystem: many popular development tools and “copilots” automatically pull and execute dependencies with little to no review, creating a frictionless path for supply chain malware to reach the local machines of developers who hold broad access to corporate infrastructure.²

The TeamPCP Attack Chain: From Security Tools to AI Infrastructure

The compromise of LiteLLM was the culminating event of a multi-week campaign by TeamPCP (also tracked as PCPcat, Persy_PCP, DeadCatx3, and ShellForce).⁹ This actor demonstrated a profound ability to execute a “cascading” supply chain attack, where the credentials stolen from one ecosystem were used to penetrate the next.¹⁵

The March 19th Inflection Point: The Trivy Compromise

The campaign gained critical momentum on March 19, 2026, when TeamPCP targeted Aqua Security’s Trivy, the most widely adopted open-source vulnerability scanner in the cloud-native ecosystem.¹⁷ By exploiting a misconfigured workflow and a privileged Personal Access Token (PAT) that had not been fully revoked following a smaller incident in late February, the attackers gained access to Trivy’s release infrastructure.¹⁸

The attackers force-pushed malicious commits and tags (affecting 76 out of 77 tags) to the aquasecurity/trivy-action repository, silently replacing legitimate security tools with weaponized versions.⁶ Because LiteLLM utilized Trivy within its own CI/CD pipeline for automated security scanning, the execution of the poisoned Trivy binary allowed TeamPCP to harvest the PYPI_PUBLISH token for the LiteLLM project from the runner’s memory.⁹ This created a recursive irony: the security tool designed to protect the project became the very mechanism of its downfall.⁵

Multi-Ecosystem Campaign Timeline

By the time LiteLLM was poisoned, TeamPCP had already breached five major package ecosystems in a period of two weeks.⁴ Their operations moved with a speed that exceeded the industry’s ability to respond, using each breach as a stepping stone to unlock the next layer of the software stack.³

Deep Analysis of the Malware Payload

The malware deployed in the LiteLLM attack was a sophisticated, three-stage infostealer designed for a comprehensive credential-harvesting operation coupled with a long-term persistence within cloud-native environments.

Stage 1: The Harvest

Once triggered, the payload initiated an exhaustive sweep of the host file system and memory. The malware was specifically programmed to seek out the “keys to the kingdom”—credentials that would allow for further lateral movement or data theft.

System and Environment: The malware dumped all environment variables, which in AI workloads almost invariably include OPENAI_API_KEY, ANTHROPIC_API_KEY, and other LLM provider tokens.² It also captured hostnames, network routing tables, and auth logs from /var/log/auth.log.⁹
Developer Credentials: The script targeted ~/.ssh/ for private keys, ~/.gitconfig and ~/.git-credentials for repository access, and shell history files to identify sensitive commands or passwords.²
Cloud and Infrastructure: It explicitly searched for AWS credentials (via IMDSv2 and ~/.aws/), GCP service account files, Azure tokens, and Kubernetes kubeconfig files.⁹
Financial and Database Data: The payload harvested database connection strings, Docker configs, and cryptocurrency wallet files for platforms including Bitcoin, Ethereum, and Solana.²

Stage 2: Encrypted Exfiltration

To avoid detection by network monitoring tools, the harvested data was bundled into an archive named tpcp.tar.gz and encrypted using a hybrid scheme. The malware generated a random 32-byte AES-256 session key to encrypt the archive and then encrypted that key using a hardcoded 4096-bit RSA public key.⁹ This ensured that only the threat actors could decrypt the stolen data. The encrypted bundle was exfiltrated via HTTPS POST to models.litellm.cloud, a typosquatted domain registered just one day prior to the attack.⁹

As a secondary exfiltration channel, if the primary C2 server was unreachable, the malware was configured to use a stolen GitHub PAT to create a public repository named tpcp-docs in the victim’s own GitHub account, uploading the stolen credentials as release assets.⁶

Stage 3: Persistence and the Kubernetes Worm

The malware went beyond simple data theft to ensure long-term access. On local development machines, it installed a script named sysmon.py in ~/.config/sysmon/ and created a systemd user service named “System Telemetry Service” to ensure the backdoor would run persistently.⁹In environments where a Kubernetes service account token was discovered, the malware initiated a “worm” behavior. It attempted to deploy a DaemonSet or privileged pods (often named node-setup) in the kube-system namespace.⁹ These pods used hostPath mounts to escape the container environment and access the underlying node’s root filesystem, allowing the attackers to harvest SSH keys from every node in the cluster and establish a persistent foothold at the infrastructure level.⁷

The Adversary Persona: TeamPCP and the Telegram Thread

TeamPCPs’ operations are characterised by a blend of technical innovation and explicit psychological warfare. The group maintains an active presence on Telegram through channels such as @teampcp and @Persy_PCP, where they showcase their exploits and interact with the security community.⁹ Following the successful poisoning of the security and AI stacks, the group posted a chilling warning: “Many of your favourite security tools and open-source projects will be targeted in the months to come. Stay tuned”.²²

Analysis of their techniques suggests a group that is highly automated and focused on the “security-AI stack”.¹⁵ Their willingness to target vulnerability scanners like Trivy and KICS indicates a strategic choice to subvert the tools that organizations trust implicitly.² Furthermore, their “kamikaze” payload—which on Iranian systems was programmed to delete the host filesystem and force-reboot the node—suggests a geopolitical dimension to their operations that may be independent of their broader credential-harvesting goals.⁶

Structural Vulnerabilities in AI Agent Tooling

The LiteLLM incident exposes a fundamental tension in the current era of AI development. The speed with which companies are shipping AI agents, copilots, and internal tools has created a “credential dumpster fire” where thousands of packages run in environments with broad, unmonitored access.²The fact that LiteLLM entered a developer’s machine through a “dependency of a dependency of a plugin” is illustrative of the lack of visibility that currently plagues the ecosystem.² Tools like uvx and npx, while providing immense convenience for running one-off tasks, create a frictionless environment for supply chain attacks to propagate.⁹ Because these tools often default to the latest version of a package, they are the primary propagation vector for poisoned releases that stay active on PyPI for even a few hours.²³

Closing the Visibility Gap: From Recovery to Prevention

The failure of traditional security measures during the LiteLLM and Trivy attacks highlights a structural limitation in current software assurance. Standard vulnerability scanners—including the very ones compromised in this campaign—were unable to detect the threat because the malicious code was published using legitimate credentials and passed all standard integrity checks.9 Recovering from this incident requires immediate action; preventing the next one requires a fundamentally different approach to supply chain visibility.

Comprehensive Remediation Protocol

For organizations that have been affected by LiteLLM versions 1.82.7 or 1.82.8, the path to recovery must be rigorous and comprehensive. A simple upgrade to version 1.82.9 or later is insufficient, as the primary objective of the malware was the theft of long-term credentials.⁹

Moving forward, security teams should implement “dependency cooldowns” and use tools like uv or pip with the --exclude-newer flag to prevent the automatic installation of packages that have been available for less than 72 hours.²⁴ Furthermore, pinning dependencies to immutable commit SHAs rather than version tags is now a requirement for secure CI/CD pipelines, as tags can be easily force-pushed by a compromised account.¹⁰

The remediation steps above address the immediate crisis, but they do not answer a harder question: what would have caught this attack before it reached production? The LiteLLM poisoning succeeded precisely because it exploited the blind spots of CVE-based scanning. There was no vulnerability to match against; only behavioural anomalies that require a different class of analysis to detect.

Why Trace-AI Detects What Traditional Tools Miss

Trace-AI provides real-time visibility into both direct and transitive dependencies by extracting a complete SBOM directly from builds and pipelines.²⁵ Rather than relying solely on a lagging database of known vulnerabilities (NVD/CVE), Trace-AI uses five key scoring dimensions to identify risk before it is publicly disclosed.

Final Conclusion

The LiteLLM supply chain attack of 2026 was not a failure of individual developers but a failure of the current trust model of the open-source ecosystem. When a single poisoned package can reach the production environments of NASA, Netflix, and NVIDIA in hours, the “vibe coding” approach to dependency management must end.³The TeamPCP campaign has shown that attackers are moving upstream, targeting the tools that security professionals and AI researchers rely on most. The concentrated value of AI API keys and cloud credentials makes the AI orchestration layer a prime target for high-impact harvesting operations.² As organisations continue to deploy AI at scale, the only way to maintain a secure posture is to achieve deep, real-time visibility into the entire supply chain. Tools like Trace-AI by Zerberus.ai provide the necessary foundation for this new era of assurance, ensuring that the software you depend on is a source of strength, not a vector for catastrophic compromise.²⁵

References and Further Reading

litellm – PyPI, accessed on March 25, 2026, https://pypi.org/project/litellm/
The Library That Holds All Your AI Keys Was Just Backdoored: The LiteLLM Supply Chain Compromise – ARMO Platform, accessed on March 25, 2026, https://www.armosec.io/blog/litellm-supply-chain-attack-backdoor-analysis/
The LiteLLM Supply Chain Attack: A Complete Technical … – Blog, accessed on March 25, 2026, https://blog.dreamfactory.com/the-litellm-supply-chain-attack-a-complete-technical-breakdown-of-what-happened-who-is-affected-and-what-comes-next
TeamPCP Supply Chain Attacks Escalate Across Open Source – Evrim Ağacı, accessed on March 25, 2026, https://evrimagaci.org/gpt/teampcp-supply-chain-attacks-escalate-across-open-source-534993
litellm got poisoned today. Found because an MCP plugin in Cursor …, accessed on March 25, 2026, https://www.reddit.com/r/cybersecurity/comments/1s2sfbl/litellm_got_poisoned_today_found_because_an_mcp/
LiteLLM compromised on PyPI: Tracing the March 2026 TeamPCP supply chain campaign, accessed on March 25, 2026, https://securitylabs.datadoghq.com/articles/litellm-compromised-pypi-teampcp-supply-chain-campaign/
Supply Chain Attack in litellm 1.82.8 on PyPI – FutureSearch, accessed on March 25, 2026, https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack/
LiteLLM TeamPCP Supply Chain Attack: Malicious PyPI Packages …, accessed on March 25, 2026, https://www.wiz.io/blog/threes-a-crowd-teampcp-trojanizes-litellm-in-continuation-of-campaign
How a Poisoned Security Scanner Became the Key to Backdooring LiteLLM | Snyk, accessed on March 25, 2026, https://snyk.io/articles/poisoned-security-scanner-backdooring-litellm/
No Prompt Injection Required – FutureSearch, accessed on March 25, 2026, https://futuresearch.ai/blog/no-prompt-injection-required/
Don’t Let Cyber Risk Kill Your GenAI Vibe: A Developer’s Guide – mkdev, accessed on March 25, 2026, https://mkdev.me/posts/don-t-let-cyber-risk-kill-your-genai-vibe-a-developer-s-guide
LiteLLM Supply Chain Breakdown – Upwind Security, accessed on March 25, 2026, https://www.upwind.io/feed/litellm-pypi-supply-chain-attack-malicious-release
Blogmarks – Simon Willison’s Weblog, accessed on March 25, 2026, https://simonwillison.net/blogmarks/
Checkmarx KICS Code Scanner Targeted in Widening Supply Chain Hit – Dark Reading, accessed on March 25, 2026, https://www.darkreading.com/application-security/checkmarx-kics-code-scanner-widening-supply-chain
When Security Scanners Become the Weapon: Breaking Down the Trivy Supply Chain Attack – Palo Alto Networks, accessed on March 25, 2026, https://www.paloaltonetworks.com/blog/cloud-security/trivy-supply-chain-attack/
TeamPCP expands: Supply chain compromise spreads from Trivy to Checkmarx GitHub Actions | Sysdig, accessed on March 25, 2026, https://www.sysdig.com/blog/teampcp-expands-supply-chain-compromise-spreads-from-trivy-to-checkmarx-github-actions
Guidance for detecting, investigating, and defending against the Trivy supply chain compromise | Microsoft Security Blog, accessed on March 25, 2026, https://www.microsoft.com/en-us/security/blog/2026/03/24/detecting-investigating-defending-against-trivy-supply-chain-compromise/
The Trivy Supply Chain Compromise: What Happened and Playbooks to Respond, accessed on March 25, 2026, https://www.legitsecurity.com/blog/the-trivy-supply-chain-compromise-what-happened-and-playbooks-to-respond
Trivy’s March Supply Chain Attack Shows Where Secret Exposure Hurts Most, accessed on March 25, 2026, https://blog.gitguardian.com/trivys-march-supply-chain-attack-shows-where-secret-exposure-hurts-most/
From Trivy to Broad OSS Compromise: TeamPCP Hits Docker Hub, VS Code, PyPI, accessed on March 25, 2026, https://www.securityweek.com/from-trivy-to-broad-oss-compromise-teampcp-hits-docker-hub-vs-code-pypi/
Trivy Compromised by “TeamPCP” | Wiz Blog, accessed on March 25, 2026, https://www.wiz.io/blog/trivy-compromised-teampcp-supply-chain-attack
Incident Timeline // TeamPCP Supply Chain Campaign, accessed on March 25, 2026, https://ramimac.me/trivy-teampcp/
Simon Willison on generative-ai, accessed on March 25, 2026, https://simonwillison.net/tags/generative-ai/
Simon Willison on uv, accessed on March 25, 2026, https://simonwillison.net/tags/uv/
Software Supply Chain (Trace-AI) | Zerberus.ai, accessed on March 25, 2026, https://www.zerberus.ai/trace-ai
Trace-AI: Know What You Ship. Secure What You Depend On. | Product Hunt, accessed on March 25, 2026, https://www.producthunt.com/products/trace-ai-2

The Asymmetric Frontier: A Strategic Analysis of Iranian Cyber Operations and Geopolitical Resilience in the 2026 Conflict

By Ramkumar Sundarakalatharan | March 21, 2026 | Comments 0 Comment

The dawn of March 2026 marks a watershed moment in the evolution of multi-domain warfare, characterised by the total integration of offensive cyber operations into high-intensity kinetic campaigns. The initiation of Operation Epic Fury by the United States and Operation Roaring Lion by the State of Israel on February 28, 2026, has provided a definitive template for the “offensive turn” in modern military doctrine.1 From a cybersecurity practitioner’s perspective, the Iranian response and the resilience of its decentralised “mosaic” architecture offer profound insights into the future of state-sponsored digital conflict. Despite the massive degradation of traditional command structures and the reported death of Supreme Leader Ayatollah Ali Khamenei, the Iranian cyber ecosystem has demonstrated an ability to maintain operational tempo through a pre-positioned proxy ecosystem that operates with significant tactical autonomy.3 This analysis examines the strategic, technical, and geopolitical dimensions of the Iranian threat, building on the observations of General James Marks and the latest assessments from the World Economic Forum (WEF), The Soufan Centre, and major global think tanks.

The Crucible of Conflict: From Strategic Patience to Operation Epic Fury

The current state of hostilities is the culmination of two distinct phases of escalation that began in mid-2025. The first phase, characterized by the “12-day war” in June 2025, saw the United States launch Operation Midnight Hammer against Iranian nuclear facilities at Fordow, Natanz, and Isfahan in response to Tehran’s expulsion of IAEA inspectors and the termination of NPT safeguards.⁶ During this initial encounter, the information domain was already a central battleground, with the hacker group Predatory Sparrow (Gonjeshke Darande) disrupting Iranian financial institutions and cryptocurrency exchanges to undermine domestic confidence in the regime.⁹ However, the second phase, initiated on February 28, 2026, represents a fundamental shift toward regime change and the total neutralization of Iran’s asymmetric capabilities.³

General James Marks, writing in The Hill, and subsequent testimony from Director of National Intelligence Tulsi Gabbard, indicate that while the Iranian government has been severely degraded, its core apparatus remains intact and capable of striking Western interests.⁴ This resilience is attributed to the “mosaic defense” doctrine, which the Islamic Revolutionary Guard Corps (IRGC) adopted in 2005 to survive decapitation strikes. By restructuring into 31 semi-autonomous provincial commands, the regime ensured that operational capability would persist even if the central leadership in Tehran was eliminated.³ In the cyber realm, this translates to a distributed network of APT groups and hacktivist personas that can continue to execute campaigns despite a collapse in domestic internet connectivity.²

Key Milestones in the 2025-2026 Escalation	Date	Primary Operational Outcome
IAEA Safeguards Termination	Feb 10, 2026	Iran expels inspectors; 60% enrichment stockpile reaches 412kg ⁸
Operation Midnight Hammer	June 22, 2025	US B-2 bombers target Fordow and Natanz ⁷
Initiation of Epic Fury	Feb 28, 2026	Joint US-Israel strikes kill Supreme Leader Khamenei ³
Electronic Operations Room Formed	Feb 28, 2026	60+ hacktivist groups mobilize for retaliatory strikes ³
The Stryker Attack	March 11, 2026	Handala Hack wipes 200,000 devices at US medical firm ¹⁴

The Architecture of Asymmetry: Iran’s Mosaic Cyber Doctrine

The Iranian cyber program is no longer a peripheral support function but a primary tool of asymmetric leverage. The Soufan Center and RUSI emphasize that Tehran views cyber operations as a means to impose psychological costs far from the battlefield, exhausting the resources of superior foes through a war of attrition.³ This strategy relies on a “melange” of state-sponsored actors and patriotic hackers who provide the regime with plausible deniability.¹⁰

The Command Structure: IRGC and MOIS

Cyber operations are primarily distributed across two powerful organizations: the Islamic Revolutionary Guard Corps (IRGC) and the Ministry of Intelligence and Security (MOIS). The IRGC typically manages APTs focused on military targets and regional stability, such as APT33 and APT35, while the MOIS houses groups like APT34 (OilRig) and MuddyWater, which specialize in long-term espionage and infrastructure mapping.¹⁶Following the February 28 strikes, which targeted the MOIS headquarters in eastern Tehran and reportedly eliminated deputy intelligence minister Seyed Yahya Hosseini Panjaki, these units have transitioned into a state of “operational isolation”.² This isolation has led to a surge in tactical autonomy for cells based outside of Iran, which are now acting as the regime’s primary retaliatory arm while domestic internet connectivity remains between 1% and 4% of normal levels.²

The Proxy Ecosystem and the Electronic Operations Room

A critical development in the March 2026 conflict is the formalization of the “Electronic Operations Room.” Established within 24 hours of the initial strikes, this entity serves as a centralized coordination hub for over 60 hacktivist groups, ranging from pro-regime actors to regional nationalists.¹³ This ecosystem allows the state to amplify its messaging and conduct large-scale disruptive operations without the immediate risk of overt attribution.³

Prominent entities within this ecosystem include:

Handala Hack: A persona linked to the MOIS (Void Manticore) that combines high-end destructive capabilities with propaganda.²
Cyber Islamic Resistance: An umbrella collective coordinating synchronized DDoS attacks against Western and Israeli infrastructure.²
FAD Team (Fatimiyoun Cyber Team): A group specializing in wiper malware and the permanent destruction of industrial control systems (ICS).²

Sylhet Gang: A recruitment and message-amplification engine focused on targeting Saudi and Gulf state management systems.²

Technical Deep Dive: The Stryker Breach and “Living-off-the-Cloud” Warfare

On March 11, 2026, the Iranian-linked group Handala (Void Manticore) executed what is considered the most significant wartime cyberattack against a U.S. commercial entity: the breach and subsequent wiping of the Stryker Corporation.³ This incident is a case study in the evolution of Iranian TTPs (Tactics, Techniques, and Procedures), moving away from custom malware toward the weaponization of legitimate cloud infrastructure.¹⁵

The Weaponization of Microsoft Intune

The Stryker attack bypassed traditional Endpoint Detection and Response (EDR) and antivirus solutions entirely by utilizing the company’s own Microsoft Intune platform to issue mass-wipe commands.¹⁵ This “Living-off-the-Cloud” (LotC) strategy began with the theft of administrative credentials through AitM (Adversary-in-the-Middle) phishing, which allowed the attackers to bypass multi-factor authentication (MFA) and capture session tokens.¹⁴

Once inside the internal Microsoft environment, the attackers used Graph API calls to target the organization’s device management tenant. Approximately 200,000 devices—including servers, managed laptops, and mobile phones across 61 countries—were wiped.⁸ The attackers also claimed to have exfiltrated 50 terabytes of sensitive data before executing the wipe, using the destruction of systems to mask the theft and create a catastrophic business continuity event.⁸

Technical Components of the Stryker Wipe	Description	Practitioner Implication
Initial Access Vector	Phishing/AitM session token theft	Legacy MFA is insufficient; move to FIDO2 ¹⁴
Primary Platform Exploited	Microsoft Intune (MDM)	MDM is a Tier-0 asset requiring extreme isolation ²²
Command Execution	Programmatic Graph API calls	Log monitoring must include MDM activity spikes ²²
Detection Status	No malware binary detected	“No malware detected” does not mean no breach ²²
Economic Impact	$6-8 billion market cap loss	Cyber risk is now a material financial solvency risk ¹⁷

Advanced Persistent Threat (APT) Evolution

The Stryker attack highlights a broader trend identified by Unit 42 and Mandiant: the convergence of state-sponsored espionage with destructive “hack-and-leak” operations. Groups like Handala Hack now operate with a sophisticated handoff model. Scarred Manticore (Storm-0861) provides initial access through long-dwell operations, which is then handed over to Void Manticore (Storm-0842) for the deployment of wipers or the execution of the MDM hijack.¹⁹

Other Iranian groups have demonstrated similar advancements:

APT42: Recently attributed by CISA for breaching the U.S. State Department, this group continues to refine its social engineering lures using GenAI to target high-value personnel.²
Serpens Constellation: Unit 42 tracks various IRGC-aligned actors under this name, noting an increased risk of wiper attacks against energy and water utilities in the U.S. and Israel.²
The RedAlert Phishing Campaign: Attackers delivered a malicious replica of the Israeli Home Front Command application through SMS phishing (smishing). This weaponized APK enabled mobile surveillance and data exfiltration from the devices of civilians and military personnel.²

Geopolitical Perspectives: RUSI, IDSA, and the Global Spillover

The conflict in Iran is not a localized event; it has profound implications for regional stability and global defense posture. Think tanks such as RUSI and MP-IDSA have provided critical analysis on how the “offensive turn” in U.S. cybersecurity strategy is being perceived globally and the lessons other nations are drawing from the 2026 war.

The “Offensive Turn” and its Discontents

The U.S. National Cybersecurity Strategy, released on March 6, 2026, formalizes the deployment of offensive cyber operations as a standard tool of statecraft. MP-IDSA notes that this shift moves beyond “defend forward” to the active imposition of costs on adversaries, utilizing “agentic AI” to scale disruption capabilities.¹ During Operation Epic Fury, USCYBERCOM delivered “synchronised and layered effects” that blinded Iranian sensor networks prior to the kinetic strikes. This pattern confirms that cyber is now a “first-mover” asset, providing the intelligence and environment-shaping necessary for precision kinetic action.¹

However, this strategy has raised concerns regarding international norms. By encouraging the private sector to adopt “active defense” (or “hack back”) and institutionalizing the use of cyber for regime change, the U.S. may be setting a precedent that adversaries will exploit.¹ RUSI scholars warn that the “Great Liquidation” of the Moscow-Tehran axis has left Iran feeling it is in an existential fight, making it difficult to coerce through threats of violence alone.²⁵

Regional Spillover and GCC Vulnerability

The conflict has rapidly expanded to target GCC member states perceived as supporting the U.S.-Israel coalition. Iranian retaliatory strikes—both kinetic and digital—have targeted energy infrastructure, ports, and data centers in the UAE, Bahrain, Qatar, Kuwait, and Saudi Arabia.³

Kuwait and Jordan: These nations have faced the brunt of hacktivist activity. Between February 28 and March 2, 76% of all hacktivist DDoS claims in the region targeted Kuwait, Israel, and Jordan.²⁰
Maritime and Logistics: Iran has focused on disrupting logistics companies and shipping routes in the Persian Gulf, aiming to force the world to bear the economic cost of the war.³

The “Zeitenwende” for the Gulf: RUSI analysts suggest this conflict is a “warning about the effects of a Taiwan Straits War,” as the economic ripples of the Iran conflict demonstrate the fragility of global supply chains when faced with multi-domain state conflict.²⁵

Lessons for Global Defense: The Indian Perspective

MP-IDSA has drawn specific lessons for India from the war in West Asia, focusing on the protection of the defense-industrial ecosystem. The vulnerability of static targets to unmanned systems and cyber-sabotage has led to a call for the integration of “Mission Sudarshan Chakra”—India’s planned shield and sword—to protect production hubs.¹⁷ The report emphasizes the need for:

Dispersal and Hardening: Moving production nodes and reinforcing critical infrastructure with concrete capable of resisting 500-kg bombs.¹⁷
Cyber-Active Air Defense: Integrating cyber defenses directly into air defense networks to prevent the “blinding” of sensors seen in the early phases of Operation Epic Fury.¹
Workforce Resilience: Protecting a skilled workforce that is “nearly irreplaceable in times of war” from digital harassment and kinetic strikes.¹⁷

Technological Trends and Future Threats: AI, OT, and Quantum

The 2026 threat landscape is defined by the emergence of new technologies that serve as “force multipliers” for both attackers and defenders. The World Economic Forum’s Global Cybersecurity Outlook 2026 notes that 64% of organizations are now accounting for geopolitically motivated cyberattacks, a significant increase from previous years.²⁹

The AI Arms Race

AI has become a core component of the cyber-kinetic integration in 2026. Iranian actors are using GenAI to scale influence operations, spreading disinformation about U.S. casualties and false claims of successful retaliatory strikes against the Navy.³⁰ Simultaneously, the U.S. and Israel have blurred ethical lines by using AI to assist in targeting and to accelerate the “offensive turn” in cyberspace.¹

The rise of “agentic AI”—autonomous agents capable of planning and executing cyber operations—presents a double-edged sword. While it allows defenders to scale network monitoring, it also compresses the attack lifecycle. In 2025, exfiltration speeds for the fastest attacks quadrupled due to AI-enabled tradecraft.³²

Operational Technology (OT) and the Visibility Gap

Unit 42 research highlights a staggering 332% year-over-year increase in internet-exposed OT devices.²⁴ This exposure is a primary target for Iranian groups like the Fatimiyoun Cyber Team, which target SCADA and PLC systems to cause physical damage.² The integration of IT, OT, and IoT for visibility has unintentionally created pathways for attackers to move from the corporate cloud (as seen in the Stryker attack) into the industrial control layer.¹³

The Quantum Imperative

As the world transitions through 2026, the progress of quantum computing is prompting an urgent shift toward quantum-safe cryptography. IDSA reports suggest that organizations slow to adapt will find themselves exposed to “harvest now, decrypt later” strategies, where state actors exfiltrate encrypted data today to be decrypted once quantum systems reach maturity.¹¹

2026 Technological Trends	Impact on Iranian Cyber Strategy	Defensive Priority
Agentic AI	Scaling of disruption and influence missions	Automated, AI-driven SOC response ¹
OT Connectivity	Increased targeting of water and energy SCADA	Hardened segmentation; OT-SOC framework ²⁴
Quantum Computing	“Harvest now, decrypt later” espionage	Implementation of post-quantum algorithms ¹¹
Living-off-the-Cloud	Weaponization of MDM (Intune)	Identity-first security; Zero Trust ²²

Strategic Recommendations for Cybersecurity Practitioners

The Iranian threat in 2026 requires a departure from traditional, perimeter-based security models. Practitioners must adopt a mindset of “Intelligence-Driven Active Defense” to survive a persistent state-sponsored adversary.²⁴

1. Identity-First Security and Zero Trust

The Stryker breach proves that identity is the new perimeter. Organizations must eliminate “standing privileges” and move toward an environment where administrative access is provided only when needed and strictly verified.²⁴

FIDO2 MFA: Move beyond push-based notifications to phishing-resistant hardware keys.¹⁵
MDM Isolation: Secure Intune and other MDM platforms as Tier-0 assets. Implement “out-of-band” verification for mass-wipe or retire commands.²

2. Resilience and Data Integrity

In a conflict characterized by wiper malware, backups are a primary target.

Air-Gapped Backups: Maintain at least one copy of critical data offline and air-gapped to prevent the deletion of network-stored backups.²
Incident Response Readiness: Shift from “if” to “when.” Rehearse response motions specifically for LotC attacks where no malware is detected.¹⁵

3. Geopolitical Risk Management

Organizations must recognize that their security posture is inextricably linked to their geographical and geopolitical footprint.⁶

Supply Chain Exposure: Monitor for disruptions in shipping, energy, and regional services that could lead to “operational shortcuts” and increased vulnerability.⁶

Geographic IP Blocking: Consider blocking IP addresses from high-risk regions where legitimate business is not conducted to reduce the attack surface.²

Conclusion: Toward a Permanent State of Hybridity

The conflict of 2026 has demonstrated that cyber is no longer a silent “shadow war” but a foundational pillar of modern conflict. The Iranian “mosaic” has proven remarkably resilient, adapting to the death of the Supreme Leader and the degradation of its physical infrastructure by empowering a decentralized network of proxies and leveraging the vulnerabilities of the global cloud.³

For the cybersecurity practitioner, the lessons of March 2026 are clear: the era of protecting against “malware” is over; the new challenge is protecting the identity and the infrastructure that manages the digital estate.¹⁵ As General Marks and the reports from WEF and The Soufan Center indicate, the Iranian regime will continue to use cyber as its primary asymmetric leverage for years to come.³ Success in this environment requires a synthesis of technical excellence, geopolitical foresight, and an unwavering commitment to the principles of Zero Trust. The frontier of this conflict is no longer in the streets of Tehran or the deserts of the Middle East; it is in the administrative consoles of the world’s global enterprises.

References and Further Reading

Beyond Defence: The Offensive Turn in US Cybersecurity Strategy – MP-IDSA, accessed on March 21, 2026, https://idsa.in/publisher/comments/beyond-defence-the-offensive-turn-in-us-cybersecurity-strategy
Threat Brief: March 2026 Escalation of Cyber Risk Related to Iran – Unit 42, accessed on March 21, 2026, https://unit42.paloaltonetworks.com/iranian-cyberattacks-2026/
Cyber Operations as Iran’s Asymmetric Leverage – The Soufan Center, accessed on March 21, 2026, https://thesoufancenter.org/intelbrief-2026-march-17/
Iran’s government degraded but appears intact, top US spy says, accessed on March 21, 2026, https://www.tbsnews.net/world/irans-government-degraded-appears-intact-top-us-spy-says-1390421
Threat Advisory: Iran-Aligned Cyber Actors Respond to Operation Epic Fury – BeyondTrust, accessed on March 21, 2026, https://www.beyondtrust.com/blog/entry/threat-advisory-operation-epic-fury
Iran Cyber Threat 2026: What SMBs and MSPs Need to Know | Todyl, accessed on March 21, 2026, https://www.todyl.com/blog/iran-conflict-cyber-threat-smb-msp-risk
The Israel–Iran War and the Nuclear Factor – MP-IDSA, accessed on March 21, 2026, https://idsa.in/publisher/issuebrief/the-israel-iran-war-and-the-nuclear-factor
Threat Intelligence Report March 10 to March 16, 2026, accessed on March 21, 2026, https://redpiranha.net/news/threat-intelligence-report-march-10-march-16-2026
The Invisible Battlefield: Information Operations in the 12-Day Israel–Iran War – MP-IDSA, accessed on March 21, 2026, https://idsa.in/publisher/issuebrief/the-invisible-battlefield-information-operations-in-the-12-day-israel-iran-war
Fog, Proxies and Uncertainty: Cyber in US-Israeli Operations in Iran …, accessed on March 21, 2026, https://www.rusi.org/explore-our-research/publications/commentary/fog-proxies-and-uncertainty-cyber-us-israeli-operations-iran
CyberSecurity Centre of Excellence – IDSA, accessed on March 21, 2026, https://idsa.in/wp-content/uploads/2026/02/ICCOE_Report_2025.pdf
Cyber Command disrupted Iranian comms, sensors, top general says, accessed on March 21, 2026, https://therecord.media/iran-cyber-us-command-attack
Cyber Threat Advisory on Middle East Conflict – Data Security Council of India (DSCI), accessed on March 21, 2026, https://www.dsci.in/files/content/advisory/2026/cyber_threat_advisory-middle_east_conflict.pdf
The New Battlefield: How Iran’s Handala Group Crippled Stryker Corporation – Thrive, accessed on March 21, 2026, https://thrivenextgen.com/the-new-battlefield-how-irans-handala-group-crippled-stryker-corporation/
intel-Hub | Critical Start, accessed on March 21, 2026, https://www.criticalstart.com/intel-hub
Beyond Hacktivism: Iran’s Coordinated Cyber Threat Landscape …, accessed on March 21, 2026, https://www.csis.org/blogs/strategic-technologies-blog/beyond-hacktivism-irans-coordinated-cyber-threat-landscape
Cyber Operations in the Israel–US Conflict with Iran – MP-IDSA, accessed on March 21, 2026, https://idsa.in/publisher/comments/cyber-operations-in-the-israel-us-conflict-with-iran
Iran Readied Cyberattack Capabilities for Response Prior to Epic Fury – SecurityWeek, accessed on March 21, 2026, https://www.securityweek.com/iran-readied-cyberattack-capabilities-for-response-prior-to-epic-fury/
Epic Fury Update: Stryker Attack Highlights Handala’s Shift from Espionage to Disruption, accessed on March 21, 2026, https://www.levelblue.com/blogs/spiderlabs-blog/epic-fury-update-stryker-attack-highlights-handalas-shift-from-espionage-to-disruption
Global Surge: 149 Hacktivist DDoS Attacks Target SCADA and Critical Infrastructure Across 16 Countries After Middle East Conflict – Rescana, accessed on March 21, 2026, https://www.rescana.com/post/global-surge-149-hacktivist-ddos-attacks-target-scada-and-critical-infrastructure-across-16-countri
Iran War: Kinetic, Cyber, Electronic and Psychological Warfare Convergence – Resecurity, accessed on March 21, 2026, https://www.resecurity.com/blog/article/iran-war-kinetic-cyber-electronic-and-psychological-warfare-convergence
When the Wiper Is the Product: Nation-state MDM Attacks and What …, accessed on March 21, 2026, https://www.presidio.com/blogs/when-the-wiper-is-the-product-nation-state-mdm-attacks-and-what-every-enterprise-needs-to-know/
Black Arrow Cyber Threat Intel Briefing 13 March 2026, accessed on March 21, 2026, https://www.blackarrowcyber.com/blog/threat-briefing-13-march-2026
Unit 42 Threat Bulletin – March 2026, accessed on March 21, 2026, https://unit42.paloaltonetworks.com/threat-bulletin/march-2026/
RUSI, accessed on March 21, 2026, https://www.rusi.org/
Resource library search – RUSI, accessed on March 21, 2026, https://my.rusi.org/resource-library-search.html?sortBy=recent®ion=israel-and-the-occupied-palestinian-territories,middle-east-and-north-africa
Threat Intelligence Snapshot: Week 10, 2026 – QuoIntelligence, accessed on March 21, 2026, https://quointelligence.eu/2026/03/threat-intelligence-snapshot-week-10-2026/
Cyber threat bulletin: Iranian Cyber Threat Response to US/Israel strikes, February 2026 – Canadian Centre for Cyber Security, accessed on March 21, 2026, https://www.cyber.gc.ca/en/guidance/cyber-threat-bulletin-iranian-cyber-threat-response-usisrael-strikes-february-2026
Cyber impact of conflict in the Middle East, and other cybersecurity news, accessed on March 21, 2026, https://www.weforum.org/stories/2026/03/cyber-impact-conflict-middle-east-other-cybersecurity-news-march-2026/
Iran Cyber Attacks 2026: Threats, APT Tactics & How Organisations Should Respond | Ekco, accessed on March 21, 2026, https://www.ek.co/publications/iran-cyber-attacks-2026-threats-apt-tactics-how-organisations-should-respond/
IDSA: Home Page – MP, accessed on March 21, 2026, https://idsa.in/
2026 Unit 42 Global Incident Response Report – RH-ISAC, accessed on March 21, 2026, https://rhisac.org/threat-intelligence/2026-unit-42-ir-report/

Governance by Design: Real-Time Policy Enforcement for Edge AI Systems

By Ramkumar Sundarakalatharan | March 8, 2026 | Comments 0 Comment

The Emerging Problem of Autonomous Drift

For most of the past decade, AI governance relied on a comfortable assumption: the system was always connected.

Logs flowed to the cloud.
Monitoring systems analysed behaviour.
Security teams reviewed anomalies after deployment.

That assumption is increasingly invalid.

By 2026, AI systems are moving rapidly from the cloud to the edge. Autonomous drones, warehouse robots, inspection vehicles, agricultural systems, and industrial machines now execute sophisticated models locally. These systems frequently operate in environments where connectivity is intermittent, degraded, or intentionally disabled.

Traditional governance models break down under these conditions.

Cloud-based monitoring pipelines were designed to detect violations, not prevent them. If a warehouse robot crosses a restricted safety zone, the cloud log may capture the event seconds later. The physical consequence has already occurred.

This gap introduces a new operational risk: autonomous drift.

Autonomous drift occurs when the operational behaviour of an AI system gradually diverges from the safety assumptions embedded in its original training or certification.

Consider a warehouse robot tasked with optimising throughput.

Over time, reinforcement signals favour shorter routes between shelves. The system begins to treat a marked safety corridor, reserved for human operators, as a shortcut during low-traffic periods. The robot’s navigation model still behaves rationally according to its optimisation objective. However, the behaviour now violates safety policy.

If governance relies solely on cloud logging, the violation is recorded after the robot has already entered the human safety corridor.

The real governance challenge is therefore not visibility.

It is control at the moment of decision.

Governance by Design

Governance by Design addresses this challenge by embedding enforceable policy constraints directly into the operational architecture of autonomous systems.

Traditional governance frameworks rely heavily on documentation artefacts:

compliance policies
acceptable use guidelines
model cards
post-incident audit reports

These artefacts guide behaviour but do not actively control it.

Governance by Design introduces a different model.

Safety constraints are implemented as runtime enforcement mechanisms that intercept system actions before execution.

When an AI agent proposes an action, a policy enforcement layer evaluates that action against predefined operational rules. Only actions that satisfy these rules are allowed to proceed.

This architectural approach converts governance from an advisory process into a deterministic control mechanism.

Architecture of the Lightweight Enforcement Engine

A runtime enforcement engine must meet three critical requirements:

Sub-millisecond policy evaluation
Isolation from the AI model
Deterministic fail-safe behaviour

To achieve this, most edge governance architectures introduce a policy enforcement layer between the AI model and the system actuators.

Action Interception Layer

The enforcement engine intercepts decision outputs before they reach the execution layer.

This interception can occur at several architectural levels:

Interception Layer	Example Implementation
Application API Gateway	policy checks applied before commands reach device APIs
Service Mesh Sidecar	policy enforcement injected between microservices
Hardware Abstraction Layer	command filtering before motor or actuator signals
Trusted Execution Environment	policy module executed within secure enclave

In robotics platforms, this often appears as a command arbitration layer that sits between the decision engine and the control system.

Policy Evaluation Engine

The policy engine evaluates incoming actions against operational rules such as:

geofencing restrictions
physical safety limits
operational permissions
environmental constraints

To keep the system lightweight, policy modules are commonly executed using WebAssembly runtimes or minimal micro-kernel enforcement modules.

These runtimes provide:

deterministic execution
hardware portability
sandbox isolation
cryptographic policy verification

Policy Conflict Resolution

One practical challenge in runtime governance is policy conflict.

For example:

A mission policy may instruct a drone to reach a target location.
A safety policy may prohibit entry into restricted airspace.

The enforcement engine resolves these conflicts through a hierarchical precedence model.

A typical hierarchy might be:

Human safety policies
Regulatory compliance policies
Operational safety constraints
Mission objectives
Performance optimisation rules

Under this hierarchy, mission commands cannot override safety rules.

The system therefore fails safely by design.

Local-First Verification

Edge systems cannot rely on remote governance.

Safety decisions must occur locally.

Local-first verification ensures that autonomous systems remain safe even when network connectivity is lost. The enforcement engine runs directly on the device, evaluating actions against policy rules using locally available context.

This architecture allows devices to respond to unsafe conditions within milliseconds.

If a drone approaches restricted airspace, the policy engine can override navigation commands immediately. If sensor inconsistencies indicate possible spoofing or mechanical failure, the enforcement layer can halt operations.

Cloud connectivity becomes secondary and is used primarily for:

audit logging
behavioural analytics
policy distribution

Situationally Adaptive Enforcement

Autonomous systems frequently operate across environments with different risk profiles.

A drone operating in open farmland faces different safety requirements than one operating in dense urban airspace.

Situationally adaptive enforcement allows the policy engine to adjust operational constraints based on trusted environmental signals.

Environmental context can be determined using:

GPS coordinates signed by trusted navigation modules
sensor fusion from cameras, lidar, and radar
geofencing databases
broadcast environment beacons
infrastructure proximity detection

These signals allow the enforcement engine to activate different policy profiles.

For example:

Environment	Enforcement Profile
Industrial warehouse	equipment safety policies
Urban environment	strict collision avoidance + geofence
Agricultural field	reduced proximity restrictions

Importantly, the AI system does not generate these rules.

It simply operates within them.

Governance Lessons from the Frontier AI Debate

Recent debates around the deployment of frontier AI models illustrate the limitations of policy-driven governance.

In early 2026, Anthropic reiterated restrictions preventing its models from being used in fully autonomous weapons systems, reportedly complicating collaboration with defence organisations seeking greater operational autonomy from AI platforms.

The debate highlights a structural issue.

Once AI capabilities are embedded into downstream systems, the original developer no longer controls how those systems are used. Acceptable-use policies and contractual restrictions are difficult to enforce once models are integrated into operational environments.

Governance therefore becomes an architectural problem.

If safety constraints exist only as policy statements, they can be bypassed. If they exist as enforceable runtime controls, the system becomes structurally incapable of violating those constraints.

Regulatory Alignment

This architectural shift aligns closely with emerging regulatory expectations.

The EU AI Act requires high-risk AI systems to demonstrate:

robustness and reliability
effective risk management
human oversight
cybersecurity protections

Runtime policy enforcement directly supports these requirements.

Regulatory Requirement	Governance by Design Feature
Human oversight	policy engine enforces supervisory constraints
Robustness	deterministic safety guardrails
Cybersecurity	isolated enforcement runtime
Risk mitigation	local policy enforcement

Similarly, the Cyber Resilience Act requires digital products to incorporate security controls throughout their lifecycle.

Runtime enforcement architectures fulfil this expectation by ensuring safety constraints remain active even after deployment.

Implementing Governance Layers in Practice

Several emerging platforms implement elements of this architecture today.

For example, within the Zerberus security architecture, governance operates as an active runtime layer rather than a passive compliance artefact.

RAGuard-AI enforces policy boundaries in retrieval-augmented AI pipelines, preventing unsafe or adversarial data from entering model decision processes.
Judge-AI evaluates agent behaviour continuously against operational policies, providing behavioural verification for autonomous systems.

These systems illustrate how governance mechanisms can operate directly within AI runtime environments rather than relying solely on external monitoring.

Traditional Governance vs Governance by Design

Feature	Traditional AI Governance	Governance by Design
Enforcement timing	Post-incident	Real time
Connectivity requirement	Continuous cloud connection	Local first
Policy location	Documentation	Executable policy modules
Response latency	Seconds to minutes	Milliseconds
Control model	Audit and review	Deterministic enforcement

Conclusion

As AI systems increasingly interact with the physical world, governance cannot remain purely procedural.

Monitoring dashboards and compliance documentation remain necessary. However, they are insufficient when autonomous systems operate at machine speed in distributed environments.

Trustworthy AI will depend on architectures that enforce safety constraints directly within operational systems.

In other words, the future of AI governance will not be determined solely by policies or promises.

It will be determined by what autonomous systems are technically prevented from doing.