The Watch

What Happened

Iran's Islamic Revolutionary Guard Corps (IRGC) designated 18 US technology companies as military targets, set a specific deadline of April 1 at 8:00 PM Iran Standard Time, and followed through. AWS's Bahrain region (me-south-1) was physically attacked, with AWS now scrambling to recover capacity. Reports that an Oracle facility in the UAE was also struck remain disputed but unrefuted.

This is not a DDoS campaign, not a data exfiltration operation, not ransomware. This is a state military actor physically destroying commercial cloud data center infrastructure. Your disaster recovery playbooks assumed hardware failures, availability zone outages, even region-level service disruptions. They almost certainly did not model missile strikes.

Why This Is Different

Traditional cloud resilience architectures provide redundancy against correlated failures within a region — power grid issues, network backbone cuts, even natural disasters. Military targeting introduces a fundamentally different risk profile:

• Multi-site targeting — a military actor can strike multiple data centers simultaneously, defeating geographic redundancy within a theater
• Sustained denial — unlike DDoS, physical destruction creates recovery timelines measured in weeks or months, not hours
• Data residency traps — organizations with Middle East data residency requirements may have no legal path to failover outside the region
• Insurance gaps — standard cyber insurance and business continuity coverage likely excludes acts of war

Your cloud provider's 99.99% SLA doesn't include a force majeure clause for the scenario that just happened. Read it today.

Immediate Actions

If you operate any workloads in AWS me-south-1, Azure UAE North/Qatar, or GCP me-central1, the following are not optional:

1. Activate cross-region failover testing today. Don't wait for the next attack. Validate that your data, applications, and access controls can function from an alternate region. Document what breaks.
2. Review data residency constraints. If regulatory requirements mandate Middle East processing, brief your legal team on the conflict between residency obligations and physical infrastructure risk. Prepare waiver requests or alternative compliance paths.
3. Brief your executive team and board. Kinetic attacks on cloud infrastructure are boardroom-level risk. Ensure leadership understands that this category of threat exists, that it has already materialized, and that traditional DR may be insufficient.
4. Contact your cloud provider's account team. Request specific information about their physical security posture, recovery timeline for me-south-1, and what contractual protections apply in acts-of-war scenarios.

Cross-Reference: Compute Scarcity Compounds the Problem

This comes at the worst possible time. Separately, AWS lost a $10M Fortnite hosting contract because it couldn't guarantee compute capacity, Microsoft is turning away business, and H100 GPU rental prices hit an 18-month high. Cloud providers facing capacity constraints are less likely to absorb the burst demand from organizations scrambling to fail over out of the Middle East region. The recovery queue may be longer than you expect.

The Capability Shift

Three releases this week collectively represent the most significant expansion of freely available offensive AI tooling since ChatGPT went public. Unlike the vendor-shipped AI agents covered in recent briefings (Copilot, Siri, Slack AI), these are open-source, Apache 2.0-licensed models anyone can download — including threat actors.

Why Your Defenses Won't Catch This

Holo3 scored 78.85% on OSWorld-Verified, outperforming GPT-5.4 and Opus 4.6 on computer-use tasks. It doesn't script clicks — it sees the screen and reasons about what to click next. Your current defensive stack was calibrated against scripted automation: deterministic timing, predictable interaction patterns, absence of mouse jitter. A vision-language model produces interaction patterns qualitatively different from traditional bots and far closer to human behavior.

Meanwhile, Gemma 4's edge models run on $60 Raspberry Pis with full multimodal input and native function-calling — entirely offline, with zero cloud API calls your CASB would intercept. For OT/IoT environments, a compromised edge device is no longer just an entry point — it's a self-contained autonomous operator.

Separately, ServiceNow, Mila Quebec AI Institute, and Université de Montréal published research validating that terminal-only AI agents outperform complex tool-augmented agents for enterprise tasks. The implication: vendors will ship the simpler architecture — agents with direct shell access and API credentials as the default design.

Your bot detection was designed for bots. These aren't bots — they're autonomous users that happen to be software.

Supply Chain Concern

Holo3 is built on Alibaba's Qwen3.5 architecture. Organizations adopting it are implicitly trusting Chinese-origin foundation weights. With Alibaba simultaneously pivoting from open-source to proprietary monetization and targeting $100B in AI revenue over five years, licensing terms and model access could shift without warning. No organization is currently tracking model provenance in their SBOMs.

Your Defense Playbook

1. Purple-team your bot defenses against Holo3 this sprint. Download the 35B variant from Hugging Face and point it at your login flows, admin panels, and customer-facing apps. Document where CAPTCHAs, WAF behavioral rules, and rate limiters fail. This is the single highest-ROI action from this briefing.
2. Monitor for shadow model deployments on corporate endpoints. Watch for large file downloads (model weights are 10-70GB), AI inference processes (ollama, vllm, llama.cpp), and GPU utilization spikes. Developers will run these locally.
3. Brief your OT/IoT security team on Gemma 4 edge capabilities. Update threat models to include locally-hosted autonomous agents with vision and function-calling on edge hardware.
4. Start tracking AI model provenance in software supply chain. If teams or vendors use Qwen-derived models, document the dependency. Add model origin and licensing to your SBOM process.

Two Distinct Risks, One Theme: Your AI Tooling Trust Boundaries Are Illusory

Two developments this week expose that the trust boundaries organizations assume exist around AI tooling don't actually enforce what you think they do.

Risk 1: The Invisible API Provider Swap

Alibaba released QWEN-3.6-Plus with a 1-million-token context window, agentic coding capabilities, and — critically — full OpenAI and Anthropic API compatibility. Any developer using the standard openai Python client can reroute traffic to Alibaba's Model Studio with nothing more than a URL change. No code refactor. No procurement review. No security assessment.

Your DLP and API gateway likely inspect request format, not destination provider. The same API call format that routes to OpenAI routes identically to Alibaba Cloud infrastructure — subject to Chinese data governance laws, not your compliance framework. With a 1M-token context window, a single prompt can contain entire codebases, document repositories, or customer datasets.

This has direct implications for SOC 2 (CC6.1), GDPR (Articles 44-49 on international transfers), and ITAR/EAR (routing controlled technical data through Chinese infrastructure is a potential export violation regardless of intent).

The biggest AI security risk in 2026 isn't a model vulnerability — it's that any developer can reroute your data to a different country's infrastructure with a one-line config change.

Risk 2: The SDLC Write-Path Is Proven

GitHub Copilot injected promotional content directly into developer code reviews — not a sidebar, not a notification, but the code review workflow itself. After backlash, the feature was pulled. The security story isn't ads. It's proof of concept: your AI code assistant has a demonstrated write-path to inject non-developer-authored content into your SDLC at the review stage.

Map this to MITRE ATT&CK: T1195.002 (Compromise Software Supply Chain) — not as a current attack, but as a demonstrated capability. If GitHub can inject ads via this mechanism, a compromised model update, prompt injection, or malicious insider could use the identical path to introduce vulnerable code patterns or subtle backdoors. Meanwhile, OpenAI's Codex grew from 100,000 to 2 million developers in three months, and Google announced tools to import full chat histories from competitor AI assistants into Gemini — creating yet another unmonitored data migration vector.

Sources Converge on the Same Gap

Four independent sources this week identified the same structural problem: AI tool controls operate at the wrong layer. API gateways check format, not destination. App store reviews check submission, not runtime. DLP monitors traditional exfil paths, not AI platform migrations. SDLC gates validate human commits, not AI-injected content.

Your Defense Playbook

1. Enforce AI API allowlisting at the network/proxy layer, not the API format layer. Block or alert on outbound connections to unauthorized LLM endpoints including Alibaba Model Studio. This is immediate.
2. Audit Copilot and Codex write-access in your SDLC. Document exactly what these tools can modify in your repos, PRs, and CI/CD pipelines. Establish explicit trust boundaries. If an AI tool can inject content into code reviews without a human gate, fix that this sprint.
3. Update DLP for AI data migration. Google's Gemini import tools and similar cross-platform transfer mechanisms are live. Add monitoring for bulk data transfers to and from AI assistant platforms.
4. Publish an AI acceptable use policy for multi-model platforms. Perplexity's Model Council sends every query to three providers simultaneously. If your policy approves one provider, it doesn't cover orchestration layers that route to multiple.