Intelligence as Infrastructure: The Architecture of AI-Enabled Trust Failures

Two crises arrived this week wearing different clothes — a geopolitical assassination and an AI capability theft operation. The connecting thread: AI systems built to generate insight are now the primary targets of intelligence operations.
Share

7 March 2026


Executive Summary

  • The US-Israeli assassination of Iran’s Supreme Leader triggered coordinated cyber operations from ~60 state-aligned threat groups within hours — establishing geopolitical-to-cyber escalation as the new normal tempo for any organisation in coalition-adjacent infrastructure sectors.
  • Anthropic’s disclosure of industrial-scale AI distillation attacks by DeepSeek, Moonshot AI, and MiniMax — 16 million fraudulent API queries across 24,000 accounts — demonstrates that frontier AI capability is now explicitly targeted by state-affiliated actors through the same strategic logic applied to weapons programmes.
  • Israeli intelligence’s use of machine learning against Tehran’s traffic camera network to predict Khamenei’s location is the first confirmed public case of AI-powered pattern-of-life analysis enabling a high-value-target assassination — establishing urban IoT infrastructure as an active component of national security operations.
  • The convergence across all three events is structural: AI systems built to generate insight are now the primary targets of intelligence extraction operations, and most enterprise security architectures are not designed to defend against this threat model.
  • The immediate enterprise priority is twofold: audit what proprietary intelligence your organisation is generating through AI queries, and verify whether your detection capability extends to behavioural analysis — not just signature-based or threshold-based alerting.

Operation Epic Fury

What happened:

On 28 February, the United States and Israel executed Operation Epic Fury (US designation) / Operation Roaring Lion (Israeli designation), resulting in precision strikes that killed Iran’s Supreme Leader Ali Khamenei and senior Revolutionary Guards leadership. Within hours, the cyber counter-offensive had begun.

Palo Alto Networks’ Unit 42 documented approximately 60 politically motivated threat groups — aligned with Iran or Russia — coordinating attacks on Israeli energy companies, Jordanian fuel systems, and Gulf critical infrastructure. Key actors include Handala Hack (linked to Iran’s Ministry of Intelligence and Security), FAD Team (specialising in wiper malware), and the newly established “Electronic Operations Room” collective, formed on the day of the assassination. AWS data facilities in the UAE and Bahrain suffered disruptions that drove global service outages. The Center for Internet Security warned state and local governments to prepare for sustained DDoS attacks and website defacements, whilst anticipating Russia will deploy AI-generated deepfakes to erode coalition support.

The mechanism:

This is not a new threat type. It is a new tempo. State-aligned cyber actors have long coordinated responses to geopolitical events, but the compression from hours to simultaneous — physical strike and cyber operation launching within the same operational window — represents a structural shift in how hybrid warfare happens.

The pre-positioning is the key Groups like the Electronic Operations Room do not form in hours; they were waiting for a trigger event. The operational playbook had already been built. What the assassination provided was the authorisation.

Three actions:

  1. Identify your coalition-adjacent exposure. If your organisation provides cloud infrastructure, financial clearing, logistics, or energy services across GCC countries, UAE, or Israel, you are in the operational blast radius of this conflict — regardless of direct business relationships with any party, it’s worth mapoing your exposure now.
  2. Pressure-test your DDoS response posture. The sustained nature of post-Epic Fury operations means the threat is not episodic. Engage your upstream providers to confirm scrubbing capacity and failover routing. Test, don’t assume.
  3. Watch for deepfake-driven influence operations targeting your supplier relationships. Russia’s playbook in previous conflicts has included disinformation designed to fracture coalition supply chains by manufacturing false communications from partner organisations. Brief your leadership team on authentication processes lfor critical supplier communications.

The Distillation Attack

What happened:

On 24 February, Anthropic disclosed that DeepSeek, Moonshot AI, and MiniMax had orchestrated industrial-scale distillation attacks against Claude, using approximately 24,000 fraudulent accounts to generate over 16 million exchanges in violation of terms of service and regional access restrictions.

The targets were not random. Proxy services maintained “hydra cluster” architectures specifically designed to distribute traffic and evade detection. The targeted capabilities — agentic reasoning, tool use, advanced coding — represent Claude’s most commercially differentiated competencies. This was a precision extraction operation, not opportunistic scraping.

The distilled models, per Anthropic, lack the safety guardrails embedded in Claude through RLHF and Constitutional AI training. Capability without safety training is a secondary risk that has not received adequate attention in public coverage of this disclosure.

The mechanism:

Distillation attacks exploit the fundamental commercial tension in frontier AI: broad API access is both the business model and the attack surface. Anthropic cannot limit access without destroying the product. The access controls that exist — terms of service, regional restrictions, rate limits — are obstacles an adversary with sufficient resources and motivation can engineer around. The hydra cluster architecture existed specifically because Anthropic was detecting and blocking individual accounts; the adversaries planned for that control.

The OpenAI insider incident — an employee fired for trading on confidential model capability information via Polymarket — reveals the human dimension of the same problem. When knowledge about future AI capabilities is valuable enough to trade on prediction markets, insider threat risk at AI laboratories increases exponentially. The attack surface includes the humans who hold the information, not just the systems that generate it.

The second-order risk for enterprises: the same structural logic applies at smaller scale to any organisation using frontier AI to analyse proprietary data. Every sensitive query generates outputs informed by that data. Those outputs, in aggregate, reveal patterns about how your organisation thinks, what it prioritises, what it fears. You do not need your database breached. You need your questions to be studied.

What you can do:

  1. Classify your AI query types by sensitivity. Segment prompts into categories: public-safe (questions anyone could ask), sensitive (competitive or strategic context), and restricted (financial modelling, M&A analysis, litigation preparation). Apply different tooling and access controls to each category.
  2. Review your AI vendor agreements for training data provisions. Most enterprise AI agreements explicitly prohibit vendors from training on customer data, but few specify what happens if API responses are exfiltrated through third-party distillation. Understand what your agreement actually covers.
  3. Evaluate model deployment options. For the most sensitive use cases, evaluate whether locally deployed models (small language models, on-premise inference) better fit your risk profile than frontier API access, even at a capability trade-off.

Tehran Traffic Cameras

What happened:

Israeli intelligence hacked Tehran’s traffic camera network and applied machine learning to interpret the resulting data, building pattern-of-life models for Khamenei’s bodyguards and predicting his location and movements with sufficient precision for a precision strike. CIA human intelligence provided complementary confirmation of the location. The camera network was not a surveillance system designed to track the Supreme Leader. It was ordinary civilian infrastructure that happened to generate sufficient behavioural data, at sufficient resolution, for an adversary with a capable model to extract targeting intelligence.

The mechanism:

The structural vulnerability here is architectural, not procedural. The cameras were deployed for what could be described as legitimate purposes — traffic management, city operations. The risk was created through the by the combination of three things: networked infrastructure, behavioural data generation, and an adversary with the ML skills to model the data.

That with camera and ML now so widelyavailable, smart cities IoT deployments, building management systems, access control platforms, logistics networks — are all generating the raw material for pattern-of-life modelling. The Tehran operation is the public proof-of-concept. Every major defence and intelligence service has now observed it. The race to replicate AI-powered pattern-of-life targeting across equivalent civilian infrastructure has already begun.

For enterprise security architects, the structural implication extends beyond physical security. Corporate campuses, vehicle fleets, access control systems, and building management platforms generate the same categories of data. A sufficiently motivated adversary — state-sponsored or otherwise — could apply the Tehran model at commercial scale.

What you can do:

  1. Map your IoT data generation footprint. Identify every networked device on corporate premises that generates behavioural data: cameras, access control, vehicle telematics, building management systems. Understand what data is generated, where it flows, and who has access to the management systems.
  2. Apply leadership pattern-of-life awareness. Executives whose schedules, locations, and routines are predictable represent an elevated physical and digital security risk in the current environment. Review VIP security protocols with the assumption that location prediction through networked infrastructure is now an adversary capability, not a theoretical risk.
  3. Audit management system access controls. The entry point for the Tehran operation was access to the camera management system, not the cameras themselves. Treat infrastructure management platforms as critical assets with equivalent access controls to your core systems.

Spotlight on: The Architecture of AI-Enabled Trust Failures

There are two ways to steal the future. The first is to take it by force. The second is to simply ask for it, systematically, until you have what you need.

This week delivered both simultaneously.

The Tehran traffic camera operation and the Claude distillation campaign are structurally identical operations operating on different substrates. Both identified a system that generates valuable intelligence. Both exploited the fact that the system was not designed to prevent that particular form of extraction. Both succeeded without requiring the adversary to breach anything in the traditional sense of the word.

What this is:

This is not a cybersecurity problem in the conventional sense. It is a trust architecture problem. Trust architectures define which actors are authorised to access which information under which conditions. The security controls we build are expressions of our trust model. The distillation attacks and the Tehran operation both succeed because the adversary operated within the access model — they used the API as designed, they accessed the cameras as designed — but extracted value the trust model was not built to prevent.

Why now:

The cause is the convergence of three developments maturing together: frontier AI model capability (sufficient to extract meaningful intelligence from raw data), distributed adversary access to that capability (via open APIs, stolen credentials, or independent model development), and the proliferation of networked systems generating behavioural data at industrial scale.

This is not a future risk. This is the current state of the threat environment as of March 2026.

Failure modes:

The characteristic failure mode is designing controls around what attackers have done, not what they are capable of doing. Our intrusion detection systems are tuned for signatures of known attacks. Our DLP solutions are tuned for known data categories leaving known perimeters. Neither is designed for an adversary who queries your AI system repeatedly to reconstruct your proprietary model of the world, or who analyses your network’s behavioural patterns over months to optimise attack timing.

This is precisely what silent probing campaigns exploit: the gap between signature-based detection (what we see) and behavioural analysis (what we could see if we looked differently).

Control model:

The required shift is from access-based control to behavioural control. Access-based control asks: is this actor authorised to be here? Behavioural control asks: is this actor’s pattern of behaviour consistent with legitimate use?

Applied to AI system protection:

  • Monitor query patterns for systematic probing (high volume, narrow capability focus, unusual geographic distribution)
  • Implement rate limiting calibrated to legitimate use cases, not technical maximum throughput
  • Apply anomaly detection to API usage, not just content filtering

Applied to IoT infrastructure:

  • Treat management system access as a security-critical action requiring the same controls as core systems access
  • Monitor for unusual data export or access pattern changes in building management and surveillance platforms
  • Apply zero trust principles to infrastructure management: no implicit trust based on network location

30-day move:

Conduct a trust architecture review for your two highest-risk AI systems and your two highest-risk IoT management platforms. Document: what intelligence could an adversary extract by operating within the intended access model? What controls currently exist to detect that extraction? Where are the gaps?

90-day move:

Implement behavioural monitoring for frontier AI API usage across your organisation. Establish query classification, usage baseline, and anomaly detection. This is not a product you can buy off the shelf in mature form — it requires integration between your AI tooling and your security operations capability. Begin that integration now.


From the Pods

What the practitioners heard first.

“The rule book’s out… they may feel like this is a gloves-off situation and those red lines don’t exist anymore.”

— Andy Piazza, Senior Director of Threat Intelligence, Unit 42 CyberWire Daily, 5 March 2026

Three mechanisms matter for operators. First, disruption pressure compresses decision windows: when geopolitical triggers fire, campaigns shift from planned espionage timelines to immediate impact operations. Second, attribution noise rises in parallel with activity: self-identified groups, recycled claims, and opportunistic actors mean verification speed becomes an operational priority, not just an intel task. Third, response teams become a latent failure point: analyst fatigue degrades detection quality, which increases missed signals precisely during the highest-risk window. That is why resilience, verification discipline, and human rotation are now one operating model, not separate workstreams.


Operating Model Translation

Who owns this:

The threat model described here sits across three functions that do not currently share accountability. Security owns perimeter and access controls. AI/Data owns model deployment and API governance. Physical/Executive Security owns leadership protection. The Tehran operation, the distillation attacks, and the silent probing campaigns all exploit the gaps between these functions.

The immediate ownership question: who in your organisation is accountable for the risk created by the intersection of AI usage and competitive intelligence? If the answer is unclear, that ambiguity is itself a risk.

What changes:

AI governance must expand its scope from “what can our AI do” to “what intelligence does our AI usage generate.” The query patterns your organisation sends to frontier models are themselves a form of disclosure. Governance frameworks that treat AI as a tool but not as a disclosure channel are structurally incomplete.

Security architecture must incorporate IoT and building management infrastructure as security-critical systems, not operational technology managed separately from the security programme. The Tehran operation established that this distinction is a security fiction.

How it fails:

The characteristic failure mode is assigning ownership without authority. Security teams that flag AI query risks but cannot enforce controls on business-unit AI usage create the appearance of governance without the substance. Physical security teams that lack visibility into IoT management system access cannot protect against the threat the Tehran operation has demonstrated.

Ownership without authority is not ownership. It is liability without control.


Threat round up

Zero-day exploitation compresses toward simultaneity.

Google Threat Intelligence documented that nearly a third of the 884 vulnerabilities known to be exploited in 2025 were attacked on or before the day of public disclosure — up from approximately a quarter in 2024. Chinese state-linked groups doubled their zero-day exploitation count year-on-year, and commercial surveillance vendors have overtaken state-sponsored actors as the leading source of zero-day exploits.

The critical detail: nearly half of observed zero-days targeted enterprise access technologies — VPNs, security appliances, networking devices. The adversary is attacking the mechanisms of access, not the assets behind them. If your perimeter technology contains unpatched vulnerabilities, you have handed the attacker a key to every protected system behind it.

Why controls fail: Patch management programs that operate on monthly cycles cannot close zero-day exposure gaps that compress toward hours. The assumption that “patch Tuesday resolves it” has become structurally false for enterprise-critical access technologies.

Quarterly action: Implement continuous vulnerability exposure management for your internet-facing access technology. The appropriate posture is hours-to-patch for critical access systems, not weeks.


Coruna: the nation-state-to-criminal pipeline in practice.

Google’s disclosure of Coruna — an iOS exploit kit containing 23 separate exploits targeting devices running iOS 13.0 through 17.2.1 — confirms a pipeline that security practitioners have theorised but rarely seen documented this clearly. A government actor acquired or developed the kit. A cybercriminal group acquired the kit from that government actor, likely through a broker or through direct recruitment. The kit is now deployed at criminal scale against Ukrainian users.

The weaponisation timeline from government use to criminal deployment is measured in months, not years.

Why controls fail: Mobile device management programmes calibrated to update devices within 30–60 days of a patch release are not adequate for an exploit kit covering four years of iOS versions. Device management is a table stakes control, not a sufficient one.

Quarterly action: Review the iOS version distribution across your managed device fleet. Identify the percentage of devices running iOS 17.2.1 or earlier. Any device in that cohort is within Coruna’s stated target range.


Silent probing: the adversary is studying your playbook.

Adversaries are conducting long-term, low-intensity campaigns designed not to exploit vulnerabilities but to map defensive behaviour: which alerts get ignored, how quickly teams respond, whether shift changes create detection gaps. Machine learning models then analyse millions of security events, identify statistical patterns in detection and response, and optimise attack timing accordingly.

This is not a new technique. It is a newly scalable one. Manual behavioural reconnaissance has always been part of sophisticated adversary playbooks. AI makes it scalable, automated, and available to actors who previously lacked the resources for extended manual operations.

Why controls fail: Standard alert thresholds are calibrated to catch noisy attacks. Silent probing campaigns are explicitly designed to remain below those thresholds. An alert system that catches what it was configured to catch will not catch what it was configured not to.

Quarterly action: Run a red team exercise simulating six weeks of low-intensity silent probing. Provide your SOC team with the behavioural profile of a typical reconnaissance campaign and ask them to identify it in your telemetry. If they cannot, your detection architecture has a systematic blind spot.


Controls in Practice

The primary control for this week’s threat landscape is behavioural visibility.

Signature-based detection, threshold-based alerting, and access-control frameworks are necessary but insufficient against the threat patterns documented this week. What they share — zero-day exploitation, distillation attacks, silent probing — is that all three operate within or just below the boundaries of your existing control framework. The attacker is not breaking your controls. They are studying them, or operating through them.

Where it breaks:

Behavioural monitoring is data-intensive, computationally expensive, and generates significant false positives if not properly calibrated. Most security operations teams do not have the capacity to investigate the volume of anomalies that an uncalibrated behavioural system produces. The result is alert fatigue applied to a new category of alert — which is the same failure mode the adversary is already exploiting.

Implementation:

Begin with the highest-value, highest-risk systems: frontier AI API access and internet-facing access technologies. Establish a usage baseline for legitimate behaviour. Define the anomaly patterns that would indicate reconnaissance or extraction activity. Implement automated flagging for those patterns with a review workflow that does not overwhelm your SOC.

30-day version:

Instrument your frontier AI API usage. You need to know, at minimum: which teams are querying which models, at what volume, with what category of data. If you cannot answer those questions today, the 30-day goal is instrumentation, not control. You cannot control what you cannot see.

90-day version:

Implement anomaly detection on your AI API usage telemetry and integrate it into your SIEM. Define three alert categories: volume anomalies (sudden spikes inconsistent with legitimate use), pattern anomalies (systematic narrow-focus querying inconsistent with exploratory use), and data category anomalies (proprietary data categories appearing in prompts that your policy does not permit). Route alerts to a defined owner with clear escalation criteria.


Board Questions

The following questions are designed to be asked verbatim. They reveal gaps without implying the asker knows the answer.

  1. “If a sophisticated adversary spent six months systematically querying our AI systems to reconstruct our strategic planning assumptions, would we detect it? How?”
  1. “Which of our networked building management or IoT systems generate data that could be used to build a behavioural profile of our executive team? Who has access to those management platforms?”
  2. “What categories of proprietary data are our employees currently submitting to third-party AI APIs? What controls govern that? Who is accountable for enforcing them?”
  3. “Our zero-day patch window for internet-facing access technology — what is it actually, and how do we know?”
  4. “When a geopolitical event occurs that is relevant to our threat landscape, what is our process for updating our threat model? Who owns that decision, and in what timeframe?”
  5. “If our security operations team’s detection thresholds and response patterns were observable to an adversary over a six-week period, what would they learn about how to attack us?”
  6. “What does our AI governance framework say about using frontier AI APIs for sensitive analysis? Is that policy enforced technically, or only in writing?”

Close

This weekse looked at, two different actors — one conducting a geopolitical operation, one conducting an intelligence extraction campaign — used AI to extract value from systems that were never designed to prevent that form of extraction. Neither method required breaking anything. Both methods worked.

The lesson I for me is that we have spent a decades building security around the assumption that the attacker wants to get in. The more sophisticated threat models that are appearing now assume the attacker wants to understand you — your patterns, your rhythms, your predictable gaps.

Presence detection is not enough. The camera on the corner of a government building, the API endpoint that serves millions of legitimate requests, the query your analyst sends to a frontier model at 11pm: all of these are, from the right adversary’s perspective, not targets to be breached but sources to be studied.

Behavioural defence is the harder problem. Most organisations have not started.

The first step is being willing to ask the question: if an adversary were studying us, what would they learn?


Curated Assets

Toolkit: AI Query Classification and Governance A working framework for classifying enterprise AI queries by sensitivity, with a minimum viable governance model and technical control options by category. [[toolkit-ai-query-governance_2026_03_07]]

Executive Briefing: AI-Enabled Pattern-of-Life Targeting What the Tehran operation means for executive physical security and enterprise IoT risk. One-page briefing for board and C-suite distribution. [[executive-briefing-pattern-of-life-targeting_2026_03_07]]

Deep Dive: Model Distillation Attacks and Enterprise AI Supply Chain Risk How distillation attacks work, why enterprise AI supply chains are structurally exposed, and what a governance response looks like at each maturity level. [[deep-dive-model-distillation-attacks_2026_03_07]]


References

The Architecture of Concentrated Risk

Prev
Comments
Add a comment

Leave a Reply

Updates, No Noise
Updates, No Noise
Updates, No Noise
Stay in the Loop
Updates, No Noise
Regular essays and notes published via Prompting Trust.

Stay in the Loop to receive the latest insights, updates and analysis