The enterprise AI conversation has been dominated by a single question for two years: which model is the most capable? The data from 2026 points elsewhere. Only 12% of enterprise AI agent pilots ever reach production. Seventy-four per cent of enterprises have already rolled agents back after going live. Gartner now forecasts that 40% of enterprises will demote or decommission autonomous AI agents by 2027, not because the models are not smart enough, but because the governance, observability, and operational infrastructure was not in place before deployment.
Microsoft’s response at Build 2026, a platform called Foundry, is not a model launch. It is a bet that the next phase of enterprise AI competition will be won on reliability, not benchmark scores. This pillar page frames the argument, examines the evidence, and routes you to the deep-dive articles that explore each dimension in detail across this four-part series.
Why Most Enterprise AI Agents Never Reach Production covers the adoption statistics, the 7-gap production stack, and what separates the agents that succeed from those that do not.
Microsoft Foundry and the Infrastructure Bet Behind Enterprise AI unpacks Foundry’s architecture: the agent service, vendor-agnostic model marketplace, and CI/CD tooling.
The Governance Infrastructure Enterprise AI Agents Actually Need covers MCP security, ACS runtime enforcement, ASSERT evaluation, and the regulatory compliance layer.
How to Choose Between Microsoft Foundry and Building Your Own Agent Infrastructure is the decision-support synthesis: Foundry versus AWS Bedrock versus Google Vertex AI, single-model versus multi-model strategy, and the build-vs-adopt framework.
Model capability, how well an LLM performs on benchmarks, has ceased to be the binding constraint on enterprise AI adoption. The constraint is now reliability: whether an agent can run in production without silent failures, cost overruns, governance breaches, or outputs that cannot be audited. Gartner’s May 2026 forecast identifies governance gaps discovered only after deployment, not model performance, as the trigger. The infrastructure that surrounds the model has become the product.
Models are commoditising rapidly. Anthropic‘s Claude, OpenAI‘s GPT, and Microsoft’s own MAI models all deliver frontier performance, and the differences between them shrink with each release. The strategic question has therefore shifted: not “which model is best?” but “which infrastructure keeps the model safe, auditable, and cost-controlled in production?” The 74% rollback rate and the 88% pilot failure rate are data points that demonstrate capability is not the bottleneck — and the full statistical breakdown confirms the pattern is structural, not transient. Fifty-nine per cent of companies are now meaningfully adopting generative AI, yet only 43% have formal AI governance policies in place. The gap is operational, not algorithmic.
Models change every quarter; governance, identity, observability, and CI/CD pipelines persist across model generations. Foundry’s announcement at Build 2026, releasing ACS, ASSERT, Guided Guardrails, and the vendor-agnostic marketplace, represents a bet that the enterprise customer wants infrastructure portability and operational dependability, not model lock-in. As one industry analysis put it, the orchestration layer could become the moat, not the model. That is the reliability-first thesis, and it is the central argument every article in this cluster examines from a different angle.
Why Most Enterprise AI Agents Never Reach Production digs into the evidence behind this shift, including the statistics, the structural gaps, and what production-readiness actually means.
The headline statistics tell the story. Only 12% of enterprise AI agent pilots convert to production within 12 months. Seventy-four per cent of enterprises have rolled agents back after going live. IDC and McKinsey data place the enterprise AI agent market at roughly $10.9 to $12 billion, yet the pilot-to-production conversion rate has not materially improved since 2024. The gap is rooted in infrastructure and operational maturity, and it affects every industry.
The spread between the 80% of applications that now embed an AI agent, per Gartner, and the 31% of organisations actually running one in production is a 49-point gap. That is where most enterprise AI dollars are being spent, and also where most of the year’s quiet write-offs are happening. Gartner’s CIO survey puts deployed-agent adoption at just 17% in 2026, while the Cisco AI Readiness Index shows 83% of organisations plan to deploy autonomous agents but only one in three says their infrastructure is ready. The investment is high. The outcomes are not matching.
These numbers are a structural signal, not a transient phase. The consistency of the pattern across industries, regions, and model providers suggests the issue is not model quality but operational readiness. Gartner’s 40% decommissioning forecast is the forward-looking indicator: the wave of rollbacks visible today will become a wave of formal decommissioning within 18 months. Gartner’s analysis identifies the root causes explicitly: absence of autonomous agent lifecycle management, uniform-governance failures where identical controls are applied to high-risk and low-risk agents, and lack of named agent ownership. Each of those is an operational gap, not a model capability gap.
Why Most Enterprise AI Agents Never Reach Production provides the full statistical picture, including adoption rates by industry and region and the production-ready agent profile.
The 7-gap production stack is a diagnostic framework identifying the seven operational layers that must exist before an AI agent can run reliably in production: (1) observability and tracing, (2) evaluation and testing, (3) non-deterministic output management, (4) governance and compliance, (5) tool safety and MCP governance, (6) identity and access, and (7) cost and ROI measurement. Each missing layer compounds the risk of silent, expensive, or irreversible failure. The production readiness gap represented by the 88% pilot failure rate is not a single-gap problem. It is the cumulative weight of multiple missing layers.
Here is what each gap means in practice. Gap 1, observability: can you trace every agent decision to its source? Gap 2, evaluation: do you run automated test suites on every prompt and model change? Gap 3, non-deterministic outputs: how do you handle same-input-different-output behaviour in regulated workflows? Gap 4, governance: do you have runtime policy enforcement, or only pre-deployment checklists? Gap 5, tool safety: is every MCP server connection vetted, authenticated, and monitored? Gap 6, identity: do agents operate as scoped workload identities or user proxies? Gap 7, cost: can you attribute and cap spend per agent, per task, per model?
These gaps compound. Each individual gap is a 1.5x to 3x risk multiplier, and they stack. An agent with no evaluation coverage, no governance enforcement, and no cost attribution can silently run up thousands of dollars in a single weekend loop while producing outputs that cannot be audited. The numbers bear this out. Only 38% of production agents have automated evaluations running on every prompt change.
Why Most Enterprise AI Agents Never Reach Production walks through each gap in detail and provides the maturity model for self-assessment.
Microsoft Foundry is a production infrastructure layer for deploying, governing, and operating AI agents at enterprise scale. It is not an experimentation environment. Azure AI Studio, its predecessor, was built for model exploration, fine-tuning, and prototyping. Foundry is built for running agents in production: it provides managed agent hosting with memory persistence, CI/CD pipelines with evaluation gates, a vendor-agnostic model marketplace, integrated governance through ACS and ASSERT, and identity management via Microsoft Entra ID. The analogy is the difference between a development environment and a Kubernetes cluster.
Foundry is Microsoft’s response to the production crisis documented in the adoption statistics. Azure AI Studio answered the question “can we build an AI agent?” Foundry answers the question “can we run that agent safely, audibly, and cost-effectively across an enterprise?” The Build 2026 launch positioned Foundry as an AI app and agent factory, standing alongside Microsoft 365 and Microsoft Fabric as the third pillar of Microsoft’s enterprise platform. Foundry consolidates several previous Azure AI services: the Assistants API is replaced by the Responses API, and a unified project client replaces multiple packages.
The strategic stakes matter for enterprise decision-making. If you evaluate Foundry as a model experimentation platform, you miss the point entirely. If you evaluate it as a production operations layer that treats AI agents like real software systems, with CI/CD, canary deployments, rollback, cost management, and runtime governance, you see the strategic bet. Foundry’s production architecture assumes models will change and builds the governance and operations layers to persist across model generations. It inherits Azure’s certification stack, the broadest in the industry for regulated verticals, with private endpoints, customer-managed keys, and data residency all standard.
Microsoft Foundry and the Infrastructure Bet Behind Enterprise AI provides the full architectural walkthrough and the enterprise deployment evidence.
Foundry’s Agent Service provides a managed runtime for deploying AI agents with persistent memory, automated scaling, and integrated governance. It offers two agent types: hosted agents, which are stateful with procedural, user, and session memory for complex production workloads, and prompt agents, which are stateless and lightweight for simpler, single-turn tasks. The three memory types each serve a distinct function: procedural memory retains how the agent should work across runs, user memory stores preferences across sessions, and session memory holds context within a single conversation thread. The service also includes Foundry IQ for knowledge grounding against enterprise data, the Responses API for model-agnostic routing, CI/CD blueprints with evaluation gates, and identity integration through Microsoft Entra ID where agents authenticate as scoped workload identities.
Hosted agents are the fully managed, stateful option. Each agent session runs in its own isolated execution sandbox with no shared state between sessions, no cross-session data leakage, and strong compute boundaries. They support VNET isolation and zero idle cost, meaning you pay only for active execution. Foundry IQ reimagines RAG as a dynamic reasoning process, powered by Azure AI Search and centralising RAG workflows into a single grounding API.
The operational surface is what makes Foundry a production platform rather than a model playground. The VS Code Foundry Toolkit and GitHub Copilot SDK integration provide the developer experience. CI/CD blueprints include evaluation gates that run automated test suites on every prompt, model, or tool change, along with canary deployments and rollback mechanisms. The enterprise deployments validate the scale. KPMG deployed Agent 365 across 276,000 professionals. Deloitte deployed Claude to over 470,000 employees. Standard Chartered, SoftBank, and Nasdaq are running production workloads on the platform as well. These are not pilot programmes. They are production operations running on the Foundry stack.
Microsoft Foundry and the Infrastructure Bet Behind Enterprise AI covers the agent service architecture in detail, including the hosted-versus-prompt agent decision framework and the full memory architecture.
Foundry’s model marketplace hosts frontier models from Anthropic, OpenAI, Fireworks AI, DeepSeek, Meta, Mistral, and xAI alongside Microsoft’s own MAI models, all behind a single Responses API that abstracts model selection from agent logic. The strategic logic is that models are commoditising, so the durable enterprise product is the infrastructure layer that persists across them: governance, identity, routing, and cost management. The marketplace is the architectural expression of the reliability-first thesis.
The marketplace is an architectural bet on infrastructure portability. When an enterprise builds agents on Foundry, the governance layer, ACS, ASSERT, Entra ID, Azure API Management, applies regardless of which model runs underneath. If Anthropic releases a breakthrough model next quarter, you can route to it without rebuilding your governance stack. If a model provider changes pricing or deprecates a version, the Responses API absorbs the change. The infrastructure, not the model, is the enduring investment. Over 10,000 customers have used more than one model on Foundry, and the number using both Anthropic and OpenAI models increased 2x quarter over quarter.
Foundry’s catalog includes over 11,000 models, the broadest selection on any cloud. Competitors’ frontier models are first-class citizens, not second-tier integrations. This signals that Microsoft’s bet is on the platform layer, not on winning the model war. Thirty-seven per cent of enterprises already use five or more models in production. The marketplace architecture makes that operationally viable at scale. For the full competitive context, see how Foundry’s model strategy stacks up against AWS Bedrock and Google Vertex AI.
Microsoft Foundry and the Infrastructure Bet Behind Enterprise AI provides the full model roster and the competitive comparison against AWS Bedrock and Google Vertex AI Model Garden.
The Model Context Protocol, or MCP, is Anthropic’s open standard that lets AI agents connect to external tools and data sources. It has over 150 million package downloads and thousands of community-built servers. But alongside that adoption comes a significant security surface. Researchers have documented STDIO command injection, tool poisoning, and cross-server tool shadowing attacks. Over 1,800 MCP servers are exposed to the internet without authentication. Every MCP server connection is a potential data exfiltration vector, privilege escalation path, or compliance violation.
MCP was designed for capability, not security. The specification leaves authentication optional and tool description trust implicit. Tool descriptions are the interface, loaded directly into the AI model’s reasoning. An attacker who controls a tool description controls the model’s behaviour. The Cloud Security Alliance’s MAESTRO threat modelling framework has catalogued over 200,000 vulnerable MCP instances and at least seven confirmed high-severity CVEs spanning MCP Inspector, LiteLLM, Cursor IDE, and LibreChat. Nation-state actors have already weaponised MCP: Anthropic disclosed a Chinese state-sponsored campaign that used Claude Code plus MCP tools to run AI-orchestrated intrusions against roughly 30 organisations. Only 8% of MCP servers support OAuth, and nearly half of those have material implementation flaws.
What enterprise governance of MCP requires is a four-layer security model: transport security with TLS and mTLS, authentication and authorisation, input/output validation and content filtering, and behavioural monitoring. Foundry’s Toolboxes provide the management construct, grouping MCP tools, applying policies at the group level, and managing the full lifecycle from registration through vetting to deprecation. The unifying principle is simple: treat tool descriptions as code. Code gets reviewed, versioned, tested, and monitored. MCP tool descriptions need the same rigour.
The Governance Infrastructure Enterprise AI Agents Actually Need provides the complete MCP governance assessment framework and the secure-by-default strategy.
The Agent Control Specification, ACS, is an open industry specification and part of Microsoft’s Agent Governance Toolkit that enforces safety controls at five checkpoints in an agent’s execution lifecycle: input, LLM processing, state changes, tool execution, and output. Unlike pre-deployment testing, which catches known failure modes, ACS enforces policy continuously at runtime, blocking, allowing, or escalating agent actions based on deterministic YAML contracts. It is designed to work across any agent framework and is endorsed by KPMG, IBM, Arize AI, CrewAI, and Zscaler.
Each of the five checkpoints addresses a specific failure point. The input checkpoint checks whether the user prompt contains injection attempts or policy-violating instructions. The LLM checkpoint verifies that the model’s internal reasoning complies with content safety and domain constraints. The state checkpoint catches attempts to modify state the agent should not access. The tool execution checkpoint ensures the proposed tool call is authorised, rate-limited, and within scope. The output checkpoint checks for PII, toxic content, or policy violations before the response reaches the user. Each checkpoint produces an attestation, cryptographic proof that creates an audit trail for regulatory compliance.
ACS is the runtime complement to pre-deployment evaluation. Static testing, through ASSERT, Rubric, or manual QA, catches known failure modes before deployment. ACS catches novel failure modes at runtime: the unexpected tool combination, the adversarial prompt variant, the edge case that no test suite anticipated. Both are necessary; neither is sufficient alone. ASSERT converts written governance documents into executable evaluations that feed into ACS checkpoints, creating the evaluate, control, re-evaluate closed loop. ACS has been released as open source under the MIT license and is intended to remain vendor-neutral and community-driven. As Michael Bargury, co-creator of ACS, put it: “Governance cannot rely on soft guardrails or wishful system prompts.”
The Governance Infrastructure Enterprise AI Agents Actually Need provides the full five-checkpoint architectural detail and the ACS-versus-static-testing comparison.
A production-grade governance framework needs six integrated layers: (1) agent identity, where agents authenticate as scoped workload identities via Microsoft Entra, not user proxies; (2) content safety, covering input filtering, output filtering, and abuse monitoring; (3) runtime enforcement, with ACS checkpoints that block policy-violating actions at execution time; (4) provider caps and kill switches, meaning rate limiting per agent, per model, per tool, plus emergency halts at the infrastructure level; (5) attestation and audit, providing cryptographic proof of compliance at each checkpoint; and (6) regulatory alignment, addressing EU AI Act high-risk system requirements and NIST AI RMF alignment.
Governance is an operational concern, not a compliance checkbox. Each of the six layers addresses a specific failure mode. Identity prevents privilege escalation. Content safety prevents toxic or PII-leaking outputs. ACS prevents policy violations at runtime. Caps and kill switches prevent cost runaway and large-scale failures. Attestation provides the evidence chain for auditors and regulators. Regulatory alignment ensures the framework meets the EU AI Act’s requirements for transparency, human oversight, accuracy, and robustness, with high-risk provisions effective August 2026. Non-compliance can result in fines up to 35 million euros or 7% of global annual turnover. The operational governance framework that addresses these requirements is covered in depth in the governance article.
Governance controls should be calibrated to agent risk. A document summarisation agent and a transaction-executing agent carry different risk profiles and should not be governed identically. Gartner’s four-level autonomy classification, Observe, Advise, Act with Approval, and Fully Autonomous, provides the framework for assigning governance controls proportionate to risk. Every agent should be classified by autonomy level before deployment, with circuit breakers in place and a named human owner assigned to each agent’s authority boundary. Yet only 21% of organisations have a mature governance model for autonomous AI agents, and 83% of security leaders say business units are deploying agents faster than security teams can assess them.
The Governance Infrastructure Enterprise AI Agents Actually Need provides the governance maturity self-assessment and the full six-layer framework with regulatory mapping.
The build-versus-adopt decision turns on five factors: agent fleet size and diversity, governance requirements, model strategy, platform team capacity, and cloud lock-in tolerance. A handful of homogenous agents with minimal governance requirements can be managed with custom infrastructure built on the Anthropic Agent SDK or OpenAI Agents SDK. Hundreds of agents across dozens of teams, with EU AI Act compliance requirements, multi-model strategies, and auditable attestation trails, demand a platform. Foundry’s integrated governance stack reduces the integration burden that custom builds must assemble from open-source and vendor components.
Each factor deserves honest evaluation. Agent fleet size: are you managing five agents or five hundred? Governance requirements: do you need EU AI Act-compliant attestation trails, or is internal policy sufficient? Model strategy: are you committed to a single model provider, or do you need optionality across Anthropic, OpenAI, and others? Platform team capacity: do you have the engineering resources to maintain the orchestration layer, governance layer, observability layer, and CI/CD pipeline yourself? Cloud lock-in tolerance: does adopting Foundry, which runs on Azure, align with or constrain your cloud strategy?
What “building your own” actually means in practice is worth understanding. You will need to assemble an MCP governance layer equivalent to Toolboxes, a runtime enforcement layer equivalent to ACS, a policy-to-evaluation compiler equivalent to ASSERT, an identity layer equivalent to Entra ID, a gateway layer equivalent to Azure API Management, and a model routing layer equivalent to the Responses API, likely using LiteLLM or Portkey. Each of these integrates with the others. Each new model provider, tool, or deployment adds integration debt. The build-versus-adopt comparison is a bet on whether your organisation’s integration capacity exceeds the platform’s integration surface. Teams underestimate time-to-value by six to twelve months on custom builds and face ongoing maintenance burden.
How to Choose Between Microsoft Foundry and Building Your Own Agent Infrastructure provides the complete evaluation framework, including the competitive comparison against AWS Bedrock and Google Vertex AI.
A single-model strategy, committing to OpenAI, Anthropic, or another provider, simplifies development, testing, and cost management but creates vendor lock-in and limits your ability to adopt new models as frontier capabilities shift. A multi-model strategy, using Foundry’s marketplace or a routing layer like LiteLLM, preserves optionality, allows workload-specific model selection, and insulates against deprecation or pricing changes, but adds complexity in evaluation, routing, and cost management. The better bet depends on workload diversity and how much you value model portability over integration simplicity.
Both strategies come with their costs. Single-model: you optimise deeply around one provider’s APIs, evaluation tooling, and cost structure. Your integration surface is smaller. But you are betting that your chosen provider will remain the frontier leader, that their pricing will stay competitive, and that their model deprecation schedule will not disrupt your production agents. Companies that picked a single model provider in 2023 have started regretting the dependency. When GPT-4 Turbo underperformed on specific tasks, they had no fallback. When pricing structures changed, they had no leverage. Multi-model: you build on an abstraction layer that lets you route workloads to the best model for each task, Claude for reasoning-heavy work, GPT for code generation, and so on. Your optionality is higher, but so is your evaluation and governance overhead.
The decision is a bet on how the model market will evolve. If models continue commoditising at the current pace, with Anthropic, OpenAI, Meta, DeepSeek, and others all delivering frontier performance, the multi-model bet looks stronger because differentiation shifts to the infrastructure layer. If one provider pulls decisively ahead and sustains the lead, the single-model bet looks stronger because deep integration with the winner compounds. Foundry’s marketplace is the architectural expression of Microsoft’s bet that multi-model is the enterprise future. Not every task requires the most advanced reasoning engine, and routing simpler workloads to efficient models can materially reduce cost at scale. For the full analysis, the decision-support framework covers the economic and strategic trade-offs in detail.
How to Choose Between Microsoft Foundry and Building Your Own Agent Infrastructure provides the full economic and strategic analysis, including the MAI-versus-Claude-versus-GPT model comparison.
Why Most Enterprise AI Agents Never Reach Production covers the full statistical picture: adoption rates by industry and region, the 7-gap production stack with the integrated maturity model, and the production-ready agent profile that distinguishes the 12% that succeed. It covers Gartner’s 40% decommissioning forecast, the rollback rate differential between agents with and without evaluation coverage, and the evaluation, observability, and ROI measurement frameworks engineering leaders need.
Microsoft Foundry and the Infrastructure Bet Behind Enterprise AI covers Foundry’s complete architecture: the Agent Service with hosted and prompt agents, the three memory types, Foundry IQ for knowledge grounding, the Responses API, CI/CD blueprints, VS Code tooling, Entra ID identity integration, and the vendor-agnostic model marketplace hosting Anthropic, OpenAI, and seven other providers. Enterprise deployment evidence at scale: KPMG with 276,000 professionals and Deloitte with 470,000-plus employees.
The Governance Infrastructure Enterprise AI Agents Actually Need covers the governance layer in depth: MCP’s security surface and the four-layer assessment model, ACS’s five-checkpoint runtime enforcement architecture, ASSERT’s policy-to-evaluation compilation, Toolboxes for MCP lifecycle management, and the full six-layer governance framework. Regulatory context: EU AI Act high-risk provisions effective August 2026, NIST AI RMF alignment, and the governance maturity self-assessment.
How to Choose Between Microsoft Foundry and Building Your Own Agent Infrastructure covers the complete evaluation framework: Foundry versus AWS Bedrock versus Google Vertex AI compared across model breadth, agent service maturity, governance depth, and CI/CD tooling. Single-model versus multi-model strategy analysed with economic and strategic trade-offs. Build-versus-adopt decision criteria covering fleet size, governance requirements, platform team capacity, model strategy, and cloud lock-in tolerance.
Suggested reading order: Start with the production crisis article to understand the problem. Then read the Foundry platform article to understand Microsoft’s response. Follow with the governance article to understand the operational layer that makes production viable. Finish with the decision-support article to evaluate your own path.
Gartner’s May 2026 forecast predicts that 40% of enterprises will demote or decommission autonomous AI agents by 2027, not because of model capability failures, but because of governance gaps discovered only after production deployment. The forecast identifies the absence of autonomous agent lifecycle management, uniform-governance failures where identical controls are applied to high-risk and low-risk agents, and the lack of named agent ownership as the root causes. This transforms the current 74% rollback data from a temporary statistic into a structural trend. For detailed analysis, see Why Most Enterprise AI Agents Never Reach Production.
A production-ready agent must satisfy five conditions: automated evaluation coverage on every prompt, model, and tool change (the strongest predictive indicator, with a 47% rollback rate without it and 9% with it); scoped workload identity with least-privilege access; runtime governance enforcement through ACS or an equivalent; cost attribution and per-task budgeting; and a defined human-in-the-loop pattern appropriate to the agent’s autonomy tier. Only 12% of enterprise agents meet all five. Without them, you are running an experiment in production. The full production-ready profile is detailed in Why Most Enterprise AI Agents Never Reach Production.
Foundry provides a deeper governance stack: ACS offers five-checkpoint runtime enforcement with attestation, ASSERT compiles written policies into executable evaluations, and Toolboxes manage the full MCP server lifecycle. Bedrock Guardrails provides content filtering for PII, toxicity, and prompt injection plus topic denial, but lacks runtime enforcement checkpoints, policy-to-evaluation compilation, and MCP server lifecycle management. Both platforms integrate with their respective cloud identity providers. The full governance infrastructure comparison is covered in The Governance Infrastructure Enterprise AI Agents Actually Need and evaluated in the competitive context in How to Choose Between Microsoft Foundry and Building Your Own Agent Infrastructure.
Foundry introduces Azure as the runtime dependency, which is a form of cloud platform lock-in. However, Foundry’s vendor-agnostic model marketplace, hosting Anthropic, OpenAI, Fireworks AI, DeepSeek, Meta, Mistral, and xAI alongside Microsoft’s own MAI models, is explicitly designed to prevent model-level lock-in. The Responses API abstracts model selection, meaning you can switch model providers without rewriting agent logic. The trade-off is cloud platform lock-in on Azure in exchange for model portability across vendors. Whether that trade-off works for your organisation depends on your existing cloud commitments and model strategy. See How to Choose Between Microsoft Foundry and Building Your Own Agent Infrastructure for the full build-versus-adopt evaluation.
ASSERT, Adaptive Spec-driven Scoring for Evaluation and Regression Testing, is Microsoft’s open-source framework that converts natural-language or structured policy documents into executable evaluation scenarios. It generates targeted test cases from policy statements, scores agent behaviour against those policies, and produces inspectable judge rationale, the reasoning behind each pass or fail. It works across LangChain, CrewAI, LiteLLM, and OpenAI, making it framework-agnostic. ASSERT feeds its results into ACS checkpoints, creating the closed loop where policy violations detected in evaluation trigger runtime controls. The full architecture is covered in The Governance Infrastructure Enterprise AI Agents Actually Need.
Yes. MCP is an open specification developed by Anthropic, and you can use it independently with any agent framework that supports the protocol. However, using MCP without a governance layer, whether Foundry’s Toolboxes and ACS or a custom-built equivalent, means accepting the protocol’s documented security risks: unauthenticated tool connections, tool poisoning vulnerabilities, and cross-server attack surfaces. Only 8% of MCP servers support OAuth, and over 1,800 are exposed to the internet without authentication. The question is not whether you can use MCP without Foundry; it is whether you have built the governance infrastructure to use it safely. The four-layer MCP security assessment model in The Governance Infrastructure Enterprise AI Agents Actually Need provides the framework for evaluating your readiness.
Task completion rate is a necessary but insufficient metric. Enterprise AI ROI should be measured across four dimensions: throughput improvement, time-to-resolution reduction versus the human baseline; accuracy uplift, error-rate improvement specifically for non-deterministic outputs; cost efficiency, cost-per-task versus human cost-per-task including infrastructure, evaluation, and governance overhead; and capability expansion, new workflows enabled that were previously infeasible. Deloitte’s Return-on-Autonomy framework extends this further to capture decision quality and customer outcome improvement, dimensions that cost-based ROI models miss. Only 44% of organisations have adopted AI FinOps practices to track these metrics systematically. For the full ROI framework, see Why Most Enterprise AI Agents Never Reach Production.
There is no single best platform. The answer is conditional on your context. Foundry leads on governance depth with ACS and ASSERT plus Toolboxes, vendor-agnostic model breadth, and developer tooling including the VS Code Toolkit and CI/CD blueprints, but requires Azure commitment. Bedrock leads on maturity, AWS ecosystem integration, and FedRAMP compliance posture. Vertex AI leads on model training and MLOps integration, European regulatory posture, and Gemma 4 economics at $0.13 per million tokens. If governance is your binding constraint, Foundry has the deepest stack. If AWS is your cloud, Bedrock is the natural choice. If model training is central to your workflow, Vertex AI may lead. The full three-way comparison across model marketplace, agent service, governance, and CI/CD dimensions is in How to Choose Between Microsoft Foundry and Building Your Own Agent Infrastructure.
Enterprise AI is at an inflection point. The model capability conversation that dominated 2023 and 2024 has run its course. The question now is not whether a model can do the work. It is whether you can run that model safely, audibly, and cost-effectively at scale, across hundreds of agents, under real regulatory obligations, without becoming another entry in the 74% rollback statistic.
The four articles in this cluster walk you through that question from every angle. If your agents are not making it to production, start with the production crisis article. If you are evaluating platforms, start with the Foundry explainer and the build-versus-adopt comparison. If governance is keeping you awake at night, the governance article is where you go first. The problem is well-defined, the data is clear, and the frameworks exist. The only remaining variable is whether you put them to work before the decommissioning wave reaches your deployment.
How to Choose Between Microsoft Foundry and Building Your Own Agent Infrastructure for Enterprise AIEnterprises deploying AI agents at scale face a nested set of decisions: which platform, which model strategy, and whether to build or buy the underlying infrastructure. Get any one wrong and you are looking at stalled pilots, rising costs, and governance gaps you only discover after production deployment.
The binding constraint on enterprise AI is reliability. Capability alone will not carry a deployment into production. There is no universal best platform. But there is a structured way to answer the question for your organisation — one that tests whether the reliability-first thesis holds up against competitors.
Let us walk through it.
The leading platform depends on your existing cloud commitment, governance requirements, model diversity needs, and developer tooling preferences. None of the three hyperscalers leads across all dimensions.
Microsoft Foundry offers the widest multi-vendor model range: Anthropic, OpenAI, DeepSeek, Meta, Mistral, xAI, and Microsoft’s own MAI family, all behind Azure-native identity and governance. It leads on governance depth with ACS, ASSERT, and Toolboxes providing runtime safety enforcement, and its CI/CD tooling is the most developer-focused of the three. But Foundry Agent Service is the newest, and the platform ties you to Azure as the runtime environment.
AWS Bedrock hosts 30-plus foundation models with strong curation and the most mature agent service in the market. Its IAM plus CloudTrail plus Macie governance stack is solid, and for AWS-native enterprises it minimises data egress costs. Bedrock Guardrails provides content filtering and denied topics but offers less runtime enforcement depth than Foundry’s ACS and ASSERT combination.
Google Vertex AI Model Garden hosts Gemini alongside select third-party models but has the most constrained multi-vendor breadth. It leads on model training, MLOps, and Gemini-native multimodal workloads, and Vertex AI Agent Builder is strong on Google-native integration. But it is less mature for multi-model agent orchestration, and the Gemini dependency carries the deepest cloud lock-in of the three platforms.
The decision is partly a function of where your data already lives. Foundry for Azure shops, Bedrock for AWS, Vertex AI for GCP. But two factors cut across that: governance requirements (where Foundry leads) and model strategy (where the marketplace matters). Which brings us to the next question.
This is a strategic bet on how the model market will evolve.
A single-model strategy, picking one provider and optimising around that model family, gives you simpler integration, lower evaluation overhead, deeper platform expertise, and potentially lower cost through volume commitments. Deloitte deployed Claude to 470,000-plus employees and trained 15,000 staff on it. That scale only works with a single-model commitment.
The trade-off is lock-in. Companies that picked a single provider in 2023 have started regretting the dependency. When pricing structures changed, they had no leverage. When a particular model underperformed on specific tasks, they had no fallback.
A multi-model strategy preserves optionality. Claude for reasoning-heavy agent tasks, GPT for code generation and multimodal work, MAI for Azure-native cost optimisation with clean commercial data lineage. Foundry’s marketplace architecture is the expression of this bet: a unified model router, Responses API, and integrated governance across providers make multi-model viable at enterprise scale. Routing simple summarisations to a premium model is economically wasteful, and at scale that inefficiency compounds quickly.
The recommendation is conditional. Enterprises with homogeneous agent workloads and strong provider relationships may benefit from single-model. Enterprises with diverse workloads, regulatory requirements, or uncertainty about which models will lead in twelve months should adopt multi-model. As one industry architect put it: “The long-term advantage won’t go to the organisation that commits to the best model of the moment, but to the one that builds an architecture capable of evolving with the entire field.”
Governance is the dimension where managed platforms diverge most from DIY approaches, and it is the binding constraint that determines whether building your own infrastructure is viable.
Foundry’s governance stack combines four layers: Azure Content Safety (ACS) for prompt injection defence including cross-prompt injection attacks, ASSERT for policy-driven evaluation that converts written policies into measurable tests, Toolboxes for scoped tool access managed centrally, and Microsoft Entra ID for per-agent identity with RBAC. Every agent gets a unique Entra Agent ID, giving you visibility into all active agents across a tenant. Agent 365 extends this governance plane across AWS and GCP agents.
Bedrock Guardrails provides content filtering, denied topics, and guardrail versions. It is solid but offers less runtime enforcement depth. No SharePoint ACL mechanism. Vertex AI has safety filters and Model Armor for content safety, with VPC Service Controls for network isolation. No A2A protocol governance equivalent.
For DIY governance, you are assembling content safety (NeMo Guardrails or LlamaGuard), identity management (an Entra-equivalent), audit trails, prompt injection defences, and runtime kill switches from separate components. Each requires integration, testing, and ongoing maintenance as the agent fleet grows. Companies with governance tools get over twelve times more AI projects into production than those without. That infrastructure converts experiments into production systems.
If governance is the binding constraint that determines production readiness, then the hidden costs of building your own infrastructure are the price of closing that governance gap yourself.
The visible costs of building custom infrastructure (licensing, compute, framework selection) are overshadowed by what you do not see coming: ongoing maintenance, governance integration, observability instrumentation, and identity management. Organisations consistently underestimate these by six to twelve months.
Agent frameworks like LangGraph and CrewAI evolve rapidly. Each release may introduce breaking changes. Foundry abstracts this churn behind a managed interface. The governance integration burden described above is not a one-time cost. Each component (content safety, identity, audit trails, prompt injection defences, runtime kill switches) demands ongoing testing and maintenance as the agent fleet grows. Foundry provides built-in tracing plus Application Insights. DIY requires instrumenting every model call, tool invocation, and agent decision from day one.
Identity engineering is the sleeper cost. Each Foundry agent gets a dedicated Entra identity with scoped resource access. Building equivalent infrastructure compounds with agent count.
Then there is opportunity cost. Platform engineers maintaining infrastructure are not building agent logic, evaluating models, or optimising workflows. The most expensive line item is what your team is not doing.
Wakam‘s experience illustrates the pattern. A five-person data science team built a custom AI chatbot. Maintaining it required constant engineering effort, and every new feature took weeks. After pivoting to a platform, they achieved 70 percent employee adoption within two months and deployed 136 AI agents. Doctolib‘s DoctoGPT gained 800 active users, and within days the team was overwhelmed with feature requests. Their guiding principle became: build what is in your core business, buy what will be a side project.
The evaluation compares Foundry against the fully loaded cost of assembling and maintaining equivalent infrastructure yourself. Five dimensions matter.
Agent fleet size and diversity. A handful of agents can be managed with LiteLLM or Portkey as the model abstraction layer and the Anthropic Agent SDK or OpenAI Agents SDK for orchestration. Hundreds of agents across dozens of teams demand a platform with centralised governance, identity management, and lifecycle tooling.
Governance requirements. If you need EU AI Act compliance, NIST alignment, auditable attestation trails, and runtime safety enforcement, the integration cost of building custom governance must be weighed against Foundry’s integrated stack. The ACS partner ecosystem at launch includes Infosys, KPMG, IBM, and others, which tells you how much integration work the open standard replaces.
Model strategy. If you want multi-model optionality, Foundry’s marketplace and Responses API reduce the integration burden versus building a LiteLLM or Portkey routing layer with custom evaluation and governance per provider.
Platform team capacity. Building custom requires a dedicated team maintaining orchestration, governance, observability, and CI/CD. For a 300-developer organisation, a platform orchestrator costs approximately $2 million in year one with 14 FTEs. Foundry provides these as a managed service.
Cloud lock-in tolerance. Adopting Foundry means committing to Azure as the runtime environment. Building custom means cloud flexibility but more integration work. Neither answer is wrong. The question is which cost you prefer to pay.
After weighing all five dimensions, one pattern emerges — consistent with the reliability-first thesis shaping enterprise AI infrastructure decisions: the platform that best operationalises governance, observability, identity, and CI/CD wins, regardless of model benchmarks.
Yes, and it is worth understanding what kind of lock-in and where it bites.
Foundry’s agent runtime is Azure-coupled. The deployment pipeline, identity integration, and observability are Azure-native. Migrating agents off Foundry would require re-platforming to a different runtime and re-integrating identity, networking, and monitoring. But all three hyperscaler platforms share this structural gap. Bedrock is AWS-coupled. Vertex AI is GCP-coupled. Foundry is not unique here, and Gemini Enterprise carries deeper lock-in due to its model dependency.
Where Foundry mitigates the risk: hosted agents support multiple orchestration frameworks (Agent Framework, LangGraph, CrewAI, Anthropic Agent SDK, OpenAI Agents SDK) and use standard container packaging. Your agent code remains portable even if the runtime is not. The model router provides access to 11,000-plus models across 12-plus providers with no single-model dependency. And Agent 365 extends governance to AWS and GCP agents, so you can keep Bedrock-hosted agents on AWS while centralising governance through Foundry.
For enterprises already within the Microsoft 365 ecosystem, the integration is seamless and procurement is consolidated. For enterprises with multi-cloud mandates, the lock-in question is a trade-off between runtime flexibility and integration burden. Building cloud-agnostic with LangGraph or CrewAI avoids Azure dependency but requires engineering identity, networking, observability, and governance for each cloud you target.
If the lock-in question pushes you toward considering a custom build, the next question is whether you can achieve multi-model optionality without Foundry, and at what real cost.
Yes. But the integration cost is real, and it compounds.
You can assemble a multi-model architecture using LiteLLM (open-source) or Portkey (commercial) as the routing layer, LangGraph or CrewAI for orchestration, LangSmith or Langfuse for observability, and NeMo Guardrails or LlamaGuard for content safety. Each component requires separate deployment, monitoring, and maintenance. The integration challenge is acute because agents need real-time access to current data, not historical snapshots, and every API evolution across every provider means maintenance work.
What Foundry provides that DIY does not is unified governance across all model providers. The same ACS content safety, ASSERT runtime enforcement, and Entra identity apply regardless of which model handles the request. Audit trails span every provider. Cost management is centralised. In a DIY build, each of these must be engineered and maintained separately, and teams spend months building on frameworks before confronting the production gap.
DIY multi-model makes sense if you already have a mature platform engineering team, existing observability infrastructure, and strong opinions about cloud independence. The Claude Agent SDK paired with Temporal is identified as the strongest build-your-own reference architecture for teams that meet all five build conditions. For organisations without that foundation, Foundry’s managed integration is typically faster and cheaper over a three-year horizon.
The article opened by telling you there is no universal best platform. If the argument has done its job, you now see the real question was never “which platform?” but “do I have the platform engineering capacity to build and maintain the governance, observability, and identity infrastructure that Foundry bakes in?”
The build path is not wrong. It is right for organisations with mature platform engineering teams, existing observability infrastructure, and the capacity to maintain governance integration across a growing agent fleet. The real trap is building without accounting for what Foundry provides as a managed service, and discovering the gap six to twelve months into production.
Enterprise AI battles are won on governance, observability, and operational rigour — the broader question of how enterprises should approach AI agent infrastructure. That thesis, applied systematically, leads to the evaluation framework you now have. Every decision is conditional: if your constraints are X, then Y. The article has given you the dimensions on which the answer depends, rather than a single platform recommendation.
You do not need to migrate everything at once. Foundry’s Agent 365 governance plane is designed to overlay existing infrastructure, so you can begin by extending Entra identity and Purview compliance to a pilot set of AWS-hosted agents without relocating your core workloads. The practical starting point is a single agent fleet where governance gaps hurt most (typically customer-facing automation or regulated data processing), then expanding scope as the integration proves its value.
Mid-market organisations can benefit from Foundry, but the value proposition shifts. Large enterprises justify Foundry through governance scale (hundreds of agents, dozens of teams, multi-jurisdiction compliance). Mid-market buyers typically justify it through reduced platform engineering headcount: if your team cannot afford three dedicated platform engineers to maintain orchestration, governance, and observability layers, Foundry’s managed service replaces that full-time equivalent cost with a subscription. The threshold is operational complexity, not revenue.
Workloads with high governance exposure (customer-facing automation, regulated data processing, multi-jurisdiction compliance) gain most from Foundry’s integrated safety enforcement and audit trails. Prototype-stage agents, experimental research workflows, and internal tools with narrow blast radius are reasonable candidates for custom builds using LiteLLM and LangGraph. The dividing line is not technical complexity but the cost of getting governance wrong. If a model jailbreak or unauthorised data access would trigger a regulatory filing, Foundry’s runtime enforcement justifies the platform commitment.
You can use exclusively third-party and open-source models on Foundry. The model catalogue includes Anthropic, DeepSeek, Meta (Llama), Mistral, xAI, and others alongside Microsoft’s MAI family, and the model router treats them as first-class providers. There is no architectural preference for MAI models in the routing or governance layers. The commercial incentive toward MAI is pricing and Azure-native optimisation, not platform restrictions, and enterprises running fully on Claude or Llama on Foundry face no functional penalty.
A typical Foundry pilot reaches production in 8 to 12 weeks, assuming the enterprise already operates on Azure with Entra ID in place. A custom build with equivalent governance, observability, and identity infrastructure typically takes 6 to 12 months before reaching production readiness, though a stripped-down prototype can ship faster (at the cost of the governance gaps the article documents). The timeline difference is driven less by agent logic development and more by the infrastructure assembly custom builds require.
Agent 365 provides exactly this capability. It extends Microsoft’s governance plane (Entra identity, Purview compliance, Defender security) to agents running on AWS and GCP, so you can keep your Bedrock-hosted agents on AWS while centralising governance through Foundry. The trade-off is that runtime-level enforcement (ACS, ASSERT, Toolboxes) applies only to agents running within the Foundry Agent Service on Azure. AWS-hosted agents get identity and compliance governance but not Azure-native runtime safety enforcement without additional integration work.
Yes. Foundry’s Agent Service supports streaming responses through its hosted agents tier, and the Responses API handles real-time interaction patterns including tool-use streaming and multi-turn conversations. The architecture is designed for the latency profile enterprises expect from chat and copilot interfaces. For custom builds, equivalent streaming support requires engineering effort across the orchestration framework, model router, and observability layers, which Foundry bundles into a single managed interface.
A Foundry team primarily needs agent design skills (prompt engineering, tool definition, evaluation design) and familiarity with the Azure ecosystem. A custom LangGraph build requires those same agent design skills plus Python infrastructure engineering (graph state management, checkpointing, streaming, deployment pipelines) and operational SRE capabilities for maintaining the orchestration layer in production. Foundry abstracts the infrastructure role; custom builds demand a platform engineering function alongside the agent development team, effectively doubling the skills requirement.
Foundry lets you constrain which model providers process your data through regional deployment controls, so you can route European workloads exclusively to models hosted in Azure EU data centres while directing other regions to different providers. Each model provider in the marketplace operates under Microsoft’s data processing terms when accessed through Foundry, which simplifies the DPA management burden compared to negotiating separate agreements with each provider in a DIY multi-model setup. However, some providers may not be available in all Azure regions, limiting residency options.
Microsoft provides standard Azure deprecation timelines (typically 12 months for GA services and 90 days for preview features) with migration tooling and documentation for version transitions. The more practical risk mitigation is architectural: because Foundry’s hosted agents support multiple orchestration frameworks (Agent Framework, LangGraph, CrewAI, Anthropic Agent SDK, OpenAI Agents SDK) and use standard container packaging, your agent code remains fundamentally portable. The runtime is Foundry-coupled, but the agent logic and framework choice are not.
Yes, but with friction. If your custom build uses one of the orchestration frameworks Foundry’s hosted agents support (Agent Framework, LangGraph, CrewAI, Anthropic Agent SDK, or OpenAI Agents SDK), the agent logic migrates largely intact within container packages. The migration cost concentrates in three areas: re-integrating identity from your custom solution to Entra ID, migrating observability instrumentation to Foundry’s tracing, and adapting tool definitions where they depend on cloud-native services that differ between your custom runtime and Azure. Plan for a 4 to 8 week migration window for a moderate fleet.
The Governance Infrastructure Enterprise AI Agents Actually Need: MCP Security, ACS Enforcement, and ASSERT EvaluationThree-quarters of enterprises have already rolled back or shut down an AI agent after deployment, and ungoverned tool access is one of the primary reasons. Every time an agent connects to a new service through the Model Context Protocol, it opens a trust boundary. When you multiply that by dozens of agents and hundreds of tools, the governance surface compounds quickly. The question is whether you are managing those boundaries as infrastructure or discovering them after an incident.
By the end of this article you will understand why governance infrastructure, not model capability, is the durable enterprise product for any organisation betting on AI agents. And you will have the framework to evaluate whether your agent governance is production-ready.
The Model Context Protocol is an open standard that defines a client-server architecture for connecting AI agents to external tools, data sources, and APIs through explicit permissions. Originally developed by Anthropic, it has seen adoption accelerate from roughly 100,000 server downloads in late 2024 to over 8 million by April 2025, with more than 5,800 MCP servers now publicly available.
MCP is transformative because it standardises what was previously a bespoke integration problem. It is the USB-C for AI agents: a universal connector that any model can use to plug into any tool.
The thing is, MCP handles the connection. It does not handle who gets to connect, under what conditions, or what happens when something goes wrong. As Tray.ai’s security analysis puts it, MCP “describes how clients and servers exchange resources and tools. It does not define who gets to act, when they can act, and under what conditions.” The protocol deliberately omits governance mechanisms from its core specification, leaving security to application developers.
Why should you care? Because a February 2026 scan of over 8,000 MCP servers on the public internet found that a large portion exposed admin panels, debug endpoints, or API routes without authentication. Over half of public MCP servers use static secrets rather than proper OAuth, and tool poisoning attacks succeed at a 72.8 per cent rate in benchmark testing. On April 15 this year, SecurityWeek reported that MCP contains a “by design” weakness enabling supply chain attacks where a single compromised server can pivot across every connected resource.
Agent-to-agent communication adds another dimension. The A2A protocol enables agents to coordinate autonomously, but research has documented attack vectors including fake agent advertisement, recursive denial-of-service, transitive prompt injection, and context tampering. Unchecked, one compromised agent can cascade failure through an entire multi-agent system.
Microsoft’s own approach to MCP governance organises around a four-layer security model: transport security (TLS and mTLS on every connection), authentication and authorisation (workload identities with scoped permissions), input/output validation and content filtering (Prompt Shields, data classification), and behavioural monitoring (anomaly detection for unusual tool usage patterns). The baseline posture is secure-by-default: deny first, allow-list second. Every MCP server goes through a full lifecycle: registration, security review, integration testing, limited production deployment with monitoring, and full promotion. Every server is versioned so that tool access can be rolled back the moment something looks wrong.
Pre-deployment testing catches the failure modes you already know about. The Agent Control Specification catches the ones you do not, at runtime, before they reach production systems.
ACS is a vendor-agnostic, MIT-licensed open standard for governing AI agents through middleware hooks. It is built around three layers.
Instrument places policy hooks at five checkpoints in an agent’s lifecycle: input, LLM call, state change, tool execution, and output.
Trace extends OpenTelemetry with agent-specific semantic conventions and OCSF security event formatting.
Inspect adds CycloneDX and SPDX extensions for dynamic Agent Bills of Materials, so you know exactly what dependencies every agent carries at any moment.
The checkpoint model is where ACS differentiates itself from static testing. Pre-action checkpoints evaluate whether a proposed action is safe before execution. Post-action checkpoints evaluate whether the result violates policy. Continuous monitoring detects anomalous behavioural patterns across the entire agent fleet. When an agent receives input or calls a tool, ACS fires a hook, evaluates the action against policy, and returns a verdict, allow, deny, or modify, in single-digit milliseconds.
“Governance cannot rely on soft guardrails or wishful system prompts,” Michael Bargury, co-creator of ACS, said at launch. ACS fills that gap with deterministic enforcement that cannot be talked around or jailbroken.
Attestation is the other piece that makes ACS matter for regulated industries. At each checkpoint, ACS produces cryptographic proof that the agent’s behaviour complied with policy. This creates the evidence chain that regulations like the EU AI Act require for high-risk systems: demonstrable human oversight, real-time intervention capability, and auditable decision trails. NIST’s AI Risk Management Framework calls for the same kind of continuous monitoring. ACS provides both as infrastructure.
ASSERT converts written policies from static documents into executable agent evaluations, bridging the gap between what governance looks like on paper and what it does in practice.
ASSERT, short for Adaptive Spec-driven Scoring for Evaluation and Regression Testing, is Microsoft’s open-source framework that turns natural-language behaviour specifications into automated evaluation suites. The pipeline has four stages. First, taxonomisation converts a written policy into a structured taxonomy of permissible and impermissible behaviours. Second, test-set generation instantiates that taxonomy into executable cases, including single-turn prompts and multi-turn adversarial scenarios. Third, inference runs those cases against the target agent, recording tool calls, retrieved context, and intermediate actions. Fourth, scoring evaluates each trace against the policy, producing pass-or-flag verdicts with rationale, policy citation, and the exact turn that justified the verdict.
Here is a concrete example. Suppose your policy says “agents may not access customer PII without explicit consent.” ASSERT takes that sentence, builds a taxonomy of what counts as PII and what counts as consent, generates scenarios where an agent might try to access customer data, runs those scenarios against your agent, and flags every violation with a citation back to the original policy language. That output feeds into ACS pre-action and post-action checkpoints. The loop from governance intent to governance verification closes.
This is the paradigm shift: policy-as-eval, extending the policy-as-code discipline from infrastructure to agent behaviour. And because ASSERT works across LangChain, CrewAI, OpenAI, and more, you do not need to rebuild your evaluation pipeline every time you change model providers.
Governance is an architectural stack with five integrated layers that must be in place before the first agent reaches production.
The first layer is identity. Agents require a distinct identity class, workload identities with scoped permissions, separate from both user accounts and service accounts. Microsoft Entra Agent ID gives every agent a unique, persistent identity that you can scope, monitor, and revoke independently. As the identity industry has reached consensus: “Agents are not users. They are not service accounts.” Without identity, you cannot govern what you cannot identify.
The second layer is content safety. This means Prompt Shields against direct and indirect injection, output filtering for harmful content, and abuse monitoring across the agent fleet.
The third layer is operational controls. Provider caps apply rate limiting per agent, per model, per tool. Kill switches operate at the infrastructure level, not within the agent itself, because a compromised agent cannot be trusted to honour its own termination instruction. Deploy these through your gateway enforcement layer so that platform teams can sever connections, revoke tokens, and halt compute without vendor support.
The fourth layer is regulatory alignment. The EU AI Act, effective August 2026, imposes requirements for high-risk AI systems: transparency, human oversight, accuracy, and robustness. Non-compliance penalties reach €35 million or 7 per cent of global revenue. NIST’s AI Risk Management Framework provides the voluntary standards baseline with its Govern, Map, Measure, and Manage functions. ACS attestation creates the evidence both require.
The fifth layer is hardware trust. Confidential computing ensures data remains encrypted even during processing, which matters when agents handle sensitive workloads across multi-tenant infrastructure.
The governance gap is not theoretical. Among organisations with mature governance frameworks, the rollback rate actually increases to 81 per cent. As Daniel Morris, CPO at Sinch, observed: “The most advanced organisations aren’t failing less; they’re seeing failures sooner.” Governance infrastructure does not prevent every incident. It catches them before they reach customers.
The identity and controls layers of the governance framework need operational mechanisms to function at scale. Toolboxes are Foundry‘s answer to that problem.
Without a shared management layer, every agent team repeats the same authentication setup, re-implements the same integrations, and operates without shared governance. A Toolbox groups MCP servers, applies policies at the group level, and exposes a single MCP-compatible endpoint that any agent can consume. You define rate limiting, authentication requirements, and content filtering rules once, and every member server inherits them.
Where Toolboxes change the operational picture is in lifecycle management. Versioning is built in: create and test a new version, promote it to default, and every agent pointing to the Toolbox picks up the change with no code changes and no redeployment. Versions are immutable snapshots, which means rollback is instant when something breaks. This is the difference between managing MCP connections as infrastructure and managing them as configuration files that drift across teams.
Toolboxes handle credential injection, token refresh, and enterprise policy enforcement at runtime. Content filtering guardrails operate independently of model-level filters, so you are not relying on any single model provider to police your tool access. Azure API Management provides the gateway enforcement layer: rate limiting, authentication, and monitoring for every MCP endpoint as a managed resource.
With the framework laid out and Toolboxes demonstrating how it operates at scale, you face a practical decision: integrate or assemble.
Everything in the governance stack is available as open standards. The MCP spec is open. ACS is MIT-licensed. ASSERT is open source. You can assemble your own governance infrastructure from these components. The question is what that assembly costs over time.
Foundry provides the integrated stack: Toolboxes for MCP management, ACS for runtime enforcement, ASSERT for policy-to-evaluation, Entra ID for identity, and Azure API Management for gateway enforcement. Custom governance requires integrating these same capabilities yourself, and the integration surface compounds with each new model, each new tool, each new deployment.
The scaling argument is not about feature parity. It is about integration debt. Only 14 per cent of enterprises have scaled an agent to production-grade operation. The organisations that succeed spend proportionally more on evaluation infrastructure, monitoring tooling, and operational staffing. Custom governance adds a layer of maintenance that platform teams carry across every model, tool, and deployment they add.
That said, enterprises with small, homogeneous agent fleets and dedicated platform teams may find custom governance viable. If you are running a handful of read-only agents on a single model provider, the integration surface is manageable. If you are running a heterogeneous fleet across multiple providers with agents that modify data and trigger business processes, the platform approach scales in a way that custom assembly does not.
Start with the four-layer assessment. Transport: are all MCP connections using TLS or mTLS? Authentication: are agents operating as workload identities with scoped permissions? Validation: are content filters applied to tool inputs and outputs? Monitoring: is there anomaly detection for unusual tool usage patterns?
Then audit your posture against secure-by-default. The secure-by-default principle, deny first and allow-list second, should be your baseline. Does your current configuration actually enforce this? Who approves new MCP server connections? If the answer to any of those is “we will figure it out,” your governance is not adequate.
Finally, evaluate lifecycle maturity. Are MCP servers versioned? Is there a deprecation path? Can tool access be rolled back on incident? The MCP Security Maturity Model defines four levels, starting from token-only authentication at Level 1 up to hardware-backed identity and real-time anomaly detection at Level 4. Most production organisations sit between Levels 2 and 3. Where your organisation lands depends on your risk tolerance and the sensitivity of what your agents can access.
Governance posture shifts as new tools are added and agent fleets grow. Organisations that treat this as a continuous assessment rather than a one-time exercise are the ones that sustain production deployments. The 74 per cent rollback rate reflects what happens when governance is treated as documentation rather than infrastructure, and the path forward is an engineering discipline you now have the framework to begin.
Plan for four to eight weeks to reach minimum viable governance: workload identity configuration, MCP vetting process establishment, content safety filtering, and kill switch deployment. The longer pole is not the technical implementation but the policy decisions. What permissions should agents hold? Who approves new tool connections? What constitutes an incident requiring agent termination? Governance infrastructure deploys in weeks; governance decisions that earn platform team and compliance alignment take longer.
Start with MCP governance as your foundation. Without managed, vetted, and monitored tool connections, there is nothing for ACS to enforce. Add ACS when agents move beyond read-only operations and start taking actions that modify data, trigger business processes, or communicate with other agents. MCP governs the connections; ACS governs the behaviour. Both are necessary for production deployments, but MCP is the prerequisite: you cannot govern what you cannot connect securely.
Kill switches must operate at the infrastructure level, not within the agent itself. A compromised or misbehaving agent cannot be trusted to honour its own termination instruction. Deploy emergency kill switches through your gateway enforcement layer (Azure API Management) that sever all connections at the network level, revoke the agent’s workload identity tokens through Entra ID, and halt compute resources. These controls should be testable quarterly and executable by platform teams without requiring model-provider or vendor support.
No. ACS is an MIT-licensed, vendor-agnostic, open-source standard. It defines middleware hooks that any agent platform can implement, and it integrates with OpenTelemetry for observability and OCSF for security event formatting. Foundry provides a managed implementation, but you can build ACS-compatible enforcement with open-source toolkits. The specification, not the implementation, is the durable standard, and its governance model works across any agent runtime that adopts the checkpoint architecture.
Establish agent identity as workload identities in Microsoft Entra ID. Until every agent has a unique, verifiable identity with scoped permissions, you are governing shadows. Workload identities are the governance primitive on which every other control depends: MCP server authorisation, content safety scoping, rate limiting, kill switches, and compliance attestation all require knowing which agent is taking which action. Start with identity, then audit every existing tool connection against the secure-by-default principle.
Yes, but scope discipline matters more than resource depth. Small enterprises should limit their initial agent fleet to read-only or low-risk operations, deploy MCP governance using managed Toolboxes rather than custom integration, and focus on the two controls with the highest return: workload identity and content safety filtering. The MCP spec and ACS are open standards, so the governance architecture is accessible. What small teams lack in dedicated governance headcount they can offset by constraining the problem: fewer agents, fewer tools, tighter boundaries.
API governance controls what a system can access. Agent governance controls what an agent chooses to access, when, and in what sequence. An API gateway authenticates a caller once per request; agent governance evaluates every action at pre-action, post-action, and continuous monitoring checkpoints because agent behaviour is non-deterministic. The same API connection that is safe in one context may be dangerous in another. Agent governance adds behavioural monitoring, anomaly detection, and cryptographic attestation that API governance alone does not provide.
This is the security posture that secure-by-default MCP strategy prevents. When properly configured, every MCP server connection is denied by default and explicitly allow-listed after vetting. An agent attempting a connection to an unregistered MCP server receives a deny verdict at the gateway enforcement layer, the attempt is logged as a security event, and anomaly detection flags the agent for review. If the agent has been compromised and is probing for unapproved connections, behavioural monitoring surfaces the pattern before exfiltration occurs.
The performance impact is negligible for well-architected governance. MCP connection authentication occurs once per session, not per invocation. ACS checkpoint evaluations are policy lookups, not model inferences, and execute in single-digit milliseconds. The architecture places enforcement at the gateway layer (Azure API Management) rather than inline within the agent runtime, so governance checks do not compete with inference compute. The real performance cost in enterprise deployments comes from ungoverned tool access triggering incidents, not from governance itself.
Multi-model deployments strengthen the case for governance infrastructure, not weaken it. MCP and ACS are model-agnostic: the protocol governs tool connections regardless of which model initiated the call, and the checkpoint model evaluates actions regardless of which model generated them. Foundry’s governance stack abstracts the model layer, applying consistent identity, content safety, rate limiting, and kill switches across OpenAI, Azure, and third-party models. Homogeneous model fleets are simpler to operate; heterogeneous fleets are where governance infrastructure proves its platform value.
Microsoft Foundry and the Infrastructure Bet Behind Enterprise AIEighty-eight per cent of enterprise AI agent pilots never reach production. The models are capable enough. The bottleneck is the absence of a production surface: no governed runtime, no identity management, no deployment pipelines, no cost tracking.
Microsoft is spending $150 billion a year on AI infrastructure. Foundry is the software surface designed to make that infrastructure consumable for enterprise workloads. Announced at Build 2026, it is a production infrastructure layer for deploying, governing, and scaling enterprise AI agents, a different category from AI studios and model training platforms.
At the centre of its design is the reliability-first thesis: the strategic asset that persists is the governance and operations layer, not any individual model.
Microsoft Foundry is a production infrastructure layer for deploying, governing, and scaling enterprise AI agents. Azure AI Studio was a prototyping and experimentation environment. The gap between them is the gap between a development environment and a production cluster.
The naming has not helped. It went from Azure AI Studio to Azure AI Foundry to Microsoft Foundry, and plenty of people assumed it was just another rebrand. The name changed. The architecture changed more: Foundry runs on an entirely different resource architecture, replacing the old Azure ML workspace model that AI Studio relied on.
The architecture separates two concerns. The Foundry Resource handles IT governance: networking, security, model deployments, role-based access control. Projects sit underneath as isolated development environments where you build agents and run evaluations. This layered separation means the control plane (who can deploy, which models are approved, what policies apply) is distinct from the data plane (your agent code, your evaluations). That separation is what makes Foundry an operational surface, not a playground.
Foundry assumes models will change. The governance layer, identity layer, and operational tooling are built to persist across model generations. If you swap from GPT-5 to Claude next year, your deployment pipelines and compliance posture do not reset.
Foundry Agent Service provides a managed runtime that handles scaling, state management, tool orchestration, observability, and cost tracking. Your team focuses on agent logic; the service handles the infrastructure.
Agent types. Hosted agents are stateful, containerised, with managed scaling and memory persistence. They run in sandboxed sessions and are framework-agnostic: you can build them with the Microsoft Agent Framework, LangGraph, the OpenAI Agents SDK, or the Anthropic Agent SDK. Prompt agents are stateless, defined entirely through configuration with no code to maintain.
The rule: choose hosted agents when you need custom orchestration logic; choose prompt agents when instructions and tool attachments are enough.
Memory. Hosted agents are stateful because of the three memory types Foundry provides. Procedural memory governs agent instructions and behaviour patterns. Microsoft reports a 7 to 14 per cent absolute improvement in benchmark success rates at near-baseline cost, compared to agents without procedural memory configuration. User memory retains cross-session preferences so agents personalise without re-prompting. Session memory holds in-flight conversation state, preventing context collapse during long-running interactions.
Knowledge grounding. Foundry IQ lets your agents retrieve and reason over enterprise data (Azure Blob Storage, SharePoint, OneLake) with permission-aware, citation-backed answers. Built on Azure AI Search, it provides a single grounding API. An agent cannot access data the user lacks permission to see.
The Responses API provides a unified abstraction across all agent types. Switch models without changing agent code.
CI/CD. Foundry applies software deployment discipline to your agents. You create, test, trace, evaluate, publish, and monitor, with evaluation gates and canary deployments built in. GitHub Actions and Azure DevOps integration runs automated evaluations on every commit, with rollback mechanisms if scores degrade.
Developer tooling. The VS Code Foundry Toolkit provides templates, GitHub Copilot SDK integration, local debugging with traces, and one-click deployment. The Azure Developer CLI supports one-command deployments with autoscaling, managed identity, and promotion gates.
Identity and governance. Each agent gets a dedicated workload identity through Microsoft Entra ID, authenticating as itself rather than a user proxy. Azure API Management enforces rate limiting, authentication, and policy on every tool call. Semantic Kernel and the Microsoft Agent Framework provide the open-source orchestration runtime beneath the managed service.
Scale evidence. Enterprise deployments already running on Foundry include KPMG, which deployed Agent 365 to 276,000 employees, Standard Chartered with a 40 per cent developer productivity boost, and SoftBank, which cut customer support costs by $150 million. Foundry’s control plane surfaces cost per agent interaction across model providers, with budget alerts and spending caps configurable at the resource level. The production gap was never about model capability. It was always about infrastructure.
Microsoft Foundry’s model marketplace hosts models from Anthropic, OpenAI, Meta, DeepSeek, Mistral, xAI, Fireworks AI, and Microsoft’s own models, all behind a unified governance, identity, and cost-management layer. The strategy eliminates model lock-in: the infrastructure persists regardless of which model you choose.
The marketplace is the architectural expression of the reliability-first thesis. If models commoditise rapidly, the asset that holds value is the layer that manages them. Foundry makes that layer the product.
Consider the roster. Anthropic’s Claude Fable 5 arrived on Foundry on 9 June 2026. Opus 4.8 was available from 29 May 2026. A competitor’s frontier models, hosted as first-class citizens on Microsoft’s infrastructure. Over 10,000 customers have used more than one model on Foundry, and the number using both Anthropic and OpenAI models doubled quarter over quarter.
Deloitte demonstrates why this matters at scale. In October 2025, Deloitte rolled out Claude to more than 470,000 employees globally. They chose a specific model for specific enterprise workflows, through Foundry’s marketplace, where the governance infrastructure was already in place.
You want model portability. The Foundry Control Plane applies the same content safety filters and cost controls whether an agent calls GPT-5 or Claude. The governance layer makes multi-model choice safe. We explore the governance infrastructure that makes this possible in detail elsewhere, and how Foundry stacks up against AWS Bedrock and Google Vertex AI is a comparison worth its own treatment.
That 88 per cent statistic is not a comment on model quality. It describes a gap in operational infrastructure. Foundry’s architecture is designed to close that gap, and Microsoft’s $150 billion annual spend is the bet behind it.
Every layer makes the same argument: the infrastructure that manages models outlasts the models themselves. The marketplace, the agent service, the CI/CD pipelines. They are bets on where value will accumulate.
If models commoditise as fast as the marketplace strategy assumes, the platform with the best models today may not be the platform with the governance, deployment, and identity infrastructure still standing when today’s models are gone.
Microsoft Foundry pricing is consumption-based and varies by the models and services you use. The platform itself has no fixed licensing fee; costs accrue from model inference tokens, agent hosting compute, knowledge indexing via Foundry IQ, and API management throughput. Foundry’s built-in Agent ROI analytics surface cost per agent interaction across model providers, so you can compare spending across GPT-5, Claude, and other models from a single cost-management pane. Budget alerts and spending caps are configurable at the Foundry Resource level.
No, and that is the point. Azure AI Studio projects remain fully operational, and Foundry does not force a migration. The two platforms serve different stages of the lifecycle: AI Studio is for experimentation and prototyping, while Foundry is for production deployment and governance. You can continue building and evaluating models in AI Studio and promote agents to Foundry’s managed runtime when they are ready for production. The Project layer within Foundry is designed to receive promoted artefacts from existing AI Studio workspaces.
Microsoft Foundry runs both. The model marketplace includes over 1,900 models spanning commercial frontier models from Anthropic, OpenAI, Meta, DeepSeek, Mistral, and xAI alongside open-weight models like Llama that you can deploy as managed endpoints. Beyond the marketplace, Foundry also supports custom model endpoints, meaning you can deploy your own fine-tuned or self-hosted models and govern them under the same identity, policy, and cost-management layer as any marketplace model.
Foundry is designed for any organisation that needs governed, production-grade AI agent infrastructure, regardless of size. The consumption-based pricing means you pay only for what you use, and the prompt agent type removes the need for custom orchestration code, making it accessible to teams without deep AI engineering resources. That said, the full governance surface (Entra ID workload identities, Azure API Management policies, CI/CD evaluation gates) delivers the most value to organisations managing risk across multiple agents, which skews toward mid-market and enterprise.
Foundry’s CI/CD pipeline applies software deployment discipline to AI agents: agents move through development, staging, and production environments with evaluation gates at each stage. Before promotion, automated evaluations run against quality, safety, and performance criteria using Foundry’s built-in evaluation framework. Canary deployments route a fraction of traffic to a new agent version, and rollback mechanisms restore the prior version if evaluation scores degrade. The Azure Developer CLI supports one-command deployments with autoscaling, managed identity, and promotion rules baked in.
Foundry agents can invoke any tool exposed through the Model Context Protocol (MCP), including Azure services, custom APIs, databases, and third-party SaaS connectors. The governance layer sits between the agent and its tools: Azure API Management enforces rate limiting, authentication, and request policies on every tool call, while Microsoft Entra ID ensures the agent authenticates as its own workload identity rather than impersonating a user. This means tool access is auditable, revocable, and subject to the same governance as any other enterprise API surface.
Foundry supports multi-agent orchestration natively. The Microsoft Agent Framework and Semantic Kernel, which underpin Foundry’s managed runtime, provide patterns for agent composition, delegation, and multi-agent workflows. You can build hosted agents that coordinate sub-agents for complex, multi-step business processes, and the Responses API provides a unified abstraction so that orchestrator agents call the same interface regardless of whether a sub-agent runs on GPT-5, Claude, or a fine-tuned custom model.
Microsoft Foundry inherits the Azure compliance portfolio, which includes over 100 certifications spanning ISO 27001, SOC 1/2/3, HIPAA, FedRAMP, PCI DSS, and GDPR standards. Because Foundry operates within the Azure trust boundary, its data handling, encryption, and audit logging are covered by existing Azure compliance attestations. The key addition at the Foundry layer is agent-specific governance: content safety filters, prompt shields, and protected material detection apply uniformly across every model in the marketplace, providing a consistent safety surface regardless of which provider you choose.
You can bring fine-tuned models into Foundry as custom model endpoints. The platform supports deploying fine-tuned versions of open-weight models like Llama and also provides a path for fine-tuning within Foundry using your enterprise data. Once deployed as a custom endpoint, your fine-tuned model operates under the same governance, identity, and cost-tracking layer as any marketplace model. This means the reliability-first architecture extends to models you control directly, not just those Microsoft or its partners provide.
Foundry deploys within your chosen Azure region, and data processed by agents stays within that region’s boundary unless you configure cross-region failover. Knowledge grounding via Foundry IQ indexes enterprise data at rest in your Azure Blob Storage, SharePoint, or OneLake instances, meaning source data never leaves your tenant. For model inference, Foundry’s managed endpoints route requests to model providers from within your selected region where available, and you can restrict which models an agent may call based on regional deployment availability and your organisation’s data sovereignty policies.
Why Most Enterprise AI Agents Never Reach Production: The 7-Gap Stack and What the 12% Do DifferentlyA customer-service agent passes its pilot with flying colours. It handles refunds, resolves complaints, routes escalations, everything the test plan asked for. Within 48 hours of going live it approves a fraudulent refund worth thousands. The investigation reveals the agent had service-account-level access to the payment system, no per-user identity propagation, and no one had thought to govern what tools it could actually call on behalf of a specific customer.
If you have been following enterprise AI, you know this is not an edge case. It is the norm.
Seventy-eight per cent of enterprises are running AI agent pilots. You have probably seen that statistic, and you may even be in that camp yourself. But only 12% of those pilots reach production at scale, a 66-percentage-point gap that represents the largest deployment delta in enterprise software history. The models keep getting better. The conversion rate barely moves. The bottleneck sits elsewhere: in the operational scaffolding that agents need to function safely at scale.
The headline number: only 12% of enterprise AI agent pilots reach production, a figure originating in Composio‘s 2025 AI Agent Report and corroborated by Forrester and the MIT Sloan CIO panel. Seventy-eight per cent of organisations are running pilots. The space between those two numbers is where most enterprise AI investment is disappearing in 2026.
The more revealing statistic is the rollback rate. According to a Sinch survey of more than 2,500 senior decision-makers across ten countries, 74% of enterprises have rolled back at least one AI agent after going live, with 41% experiencing multiple rollbacks in a 12-month window. For context, traditional SaaS deployments carry a 5 to 10% rollback rate. AI agents are 7 to 15 times more volatile, and the gap comes down to the absence of equivalent operational scaffolding. DevOps spent decades building deployment gates and incident response for traditional software. Agents landed without any of that.
The pattern is structural. Agents clear the pilot gate. They fail at the operational boundary. And the money keeps flowing anyway: IDC and McKinsey converge on roughly $1.4 trillion in global enterprise AI agent spend by 2027, while S&P Global Market Intelligence data shows only 31% of enterprises have reached production deployment. The average enterprise AI infrastructure budget has grown 483% since 2024 while production conversion has barely moved.
Enterprises are spending. They are just not succeeding. Sixty-four per cent of organisations that attempt to expand an agent beyond its pilot scope encounter blocking issues, with 72% of those stalled for more than six months with no clear resolution path. The average pilot duration before stalling is 4.7 months. That is a significant investment yielding no return.
If the 74% rollback rate is the acute symptom, Gartner’s forecast is the chronic diagnosis. In June 2025, Gartner projected that over 40% of agentic AI projects will be cancelled or demoted by the end of 2027. This is not a prediction of future failure. It is the lagging indicator of problems already embedded in today’s production deployments.
The trigger Gartner identifies is worth examining. Gartner points to governance gaps discovered only after production deployment, when agents are exposed to real data, real users, and real compliance requirements. The agents that passed pilot evaluation fail when the organisation cannot prove they are safe, compliant, and auditable.
This forecast sits alongside Gartner’s other 2026 findings. The firm reports that 80% of enterprise applications now embed at least one AI agent, up from 33% in 2024. It also documents the agentic loop multiplier: agentic models require between 5 and 30 times more tokens per task than a standard chatbot. Gartner is bullish on agent distribution and bearish on agent survivability. The embedding trend and the decommissioning trend are the same story told from different angles.
By 2027, organisations will have exhausted the “better models will fix this” narrative. The decommissioning wave will force a reckoning. And the specific dimensions of the infrastructure that is missing are well understood by now.
The 7-gap production stack is a diagnostic framework. It transforms the amorphous “production readiness” problem into seven concrete engineering and operational questions. Each gap represents a specific failure mode, and organisations that address fewer than four of them have near-zero probability of production success. The 12% that reach production typically have mature coverage across at least five.
Gap 1: Identity and access. Agents need fine-grained, per-user identity propagation across every tool call. Without it, an agent with service-account-level access can read or modify data the requesting user should never see. Only 21.9% of teams treat AI agents as independent, identity-bearing entities within their security model, and only 18% of security leaders express confidence that their identity systems can handle agent identities. If you cannot answer “who did the agent act as for this action,” you are not production-ready.
If identity is the foundation, tool safety is the next failure point up the stack.
Gap 2: Tool safety and MCP governance. The Model Context Protocol standardises tool connections, which is useful, but it also introduces what researchers call the “lethal trifecta“: the combination of private data access, exposure to untrusted content, and the ability to communicate externally, all within a single execution context. Without an MCP gateway enforcing tool allowlists, sandboxing, and data loss prevention, any unvetted MCP server can become an exfiltration path. MCP adoption has crossed 9,400 public servers, creating a large ungoverned tool surface.
Even with tools locked down, what the agent produces next creates its own category of risk.
Gap 3: Non-deterministic output management. Same input, different output. This breaks traditional QA paradigms based on exact output matching, and in regulated environments it is a hard blocker. Auditors cannot reproduce agent decisions. Compliance teams cannot certify behaviour. Incident responders cannot replay failure scenarios. Seventy per cent of enterprise leaders name non-deterministic outputs as the number-one production-readiness barrier. The challenge is less “the model is wrong” and more “we cannot tell when it is wrong, and our regression tests do not catch it.”
If you cannot trust what the agent produces, the next question is whether you can trust how it operates within your organisation’s rules.
Gap 4: Governance and compliance. Eighty-two per cent of executives express confidence in their AI policies. Only 14.4% deploy agents with full security or IT approval. That confidence gap is the pre-condition for post-deployment governance discovery, and it lines up with the Gartner forecast. Governance means runtime policy enforcement, privilege rings, kill switches, and audit trails, not policy documents. Only 7.7% of organisations audit AI agent activities daily, creating a significant lag between autonomous actions and security detection.
Governance tells you the rules were enforced. Observability tells you what the agent actually did.
Gap 5: Observability and tracing. Traditional monitoring tells you what failed. Agent observability tells you why. Causal AI observability requires span-per-tick tracing that captures every reasoning step, tool call, memory operation, and agent-to-agent handoff. This is a distinct category from infrastructure monitoring. Traditional APM was never designed to see into agent decision chains. Platforms like Datadog are adapting their LLM observability products for agent workloads, integrating with Google’s ADK to automatically instrument agent applications. When evaluating observability tooling, engineering leaders should look for causal tracing, agent-specific span attribution, and decision-level audit trails, capabilities that sit beyond standard APM.
Observability shows you what happened. Evaluation tells you whether it should have happened at all.
Gap 6: Evaluation and testing. Only 38% of production agents run automated evaluations on every prompt change. Here is what that means in practice: agents without automated evals carry a 47% rollback rate; agents with full eval coverage drop to 9%. That is a 5x reliability improvement from a single infrastructure investment. LangChain and LangGraph provide orchestration, but they do not automatically produce evaluation harnesses. Framework choice alone does not solve production readiness. A labelled test set of 200 or more representative production inputs, plus an adversarial set of 50 or more edge cases, forms the minimum viable evaluation baseline.
The final gap is the one that catches everyone by surprise: what any of this actually costs.
Gap 7: Cost and ROI measurement. Pilot economics calculated on single-query API calls bear no relationship to production agent economics. An agent that costs $0.03 per interaction in pilot can cost $0.90 in production when it makes multiple reasoning turns, calls tools, and retrieves context on every task. The agentic loop multiplier destroys the business case if unmeasured. Only 44% of organisations have adopted AI FinOps as a discipline, and 73% report that AI costs exceeded original budget projections. Cost-per-task tracking, model usage chargebacks, and outcome-based ROI measurement are the financial infrastructure without which agents are deployed blind.
Each gap can be assessed across four maturity levels, from nascent (no coverage) to optimised (defence-in-depth). But the practical takeaway is simpler than a full maturity assessment: the 74% rollback rate and the 40% decommissioning forecast are the predictable consequence of organisations that have mature coverage across fewer than four of these gaps. The question is what the 12% do differently.
The 12% of agents that survive share a consistent profile. It is the empirically observed common denominator of agents that survive beyond 90 days in production operation. Five criteria distinguish them from the 88% that do not make it. These five criteria operationalise the 7-gap framework into readiness gates. They are the observable markers of gap coverage, not a replacement for the gaps themselves.
First, automated evaluation coverage for at least 80% of expected agent behaviours. Below that threshold, manual QA is doing the work automation should handle, and edge cases are swamping reviewer capacity. The reliability difference between automated evals and manual QA is structural: automated evals provide coverage breadth across thousands of test cases; manual QA provides depth on complex edge cases. Both are needed, but automated evals are the gate. If you cannot automatically verify 80% of what your agent should do, you cannot scale.
Second, named organisational ownership with budget authority. Ninety-four per cent of production-successful agents have a named owner with a measurable target outcome. This is the simplest criterion and the most frequently skipped.
Third, a human-in-the-loop deployment pattern with defined confidence thresholds. The architecture follows a specific pattern: agent output, confidence scoring, a human review queue for low-confidence results, and resolution. Exception-based HITL rates vary by domain: 8% for sales development, 21% for coding, 32% for customer service, and 61% for legal and compliance. Seventy-four per cent of production-successful agents deploy with explicit HITL checkpoints for the first 60 to 90 days. HITL is not a process workaround. It is the architectural bridge between non-deterministic outputs and enterprise accountability.
Fourth, identity propagation across every tool call. No agent is production-ready without per-user identity, runtime policy enforcement, and decision-level audit trails. If an auditor cannot trace what identity the agent operated under, which tools it called, and the reasoning behind a specific decision, the agent is a pilot, not a production system.
Fifth, cost-per-task measurement against a human baseline. Sixty-three per cent of the production-successful cohort measure cost-per-task as a primary metric alongside quality and latency. The ROI question shifts from task completion to provable cost and accuracy improvement over the human baseline. Organisations that measure agent ROI against the human baseline achieve higher production-conversion rates. The median payback on successful agent deployments is 5.1 months across functions.
Return to the opening vignette. The agent that passed pilot and failed in production was not experiencing one failure. It was the predictable intersection of three gaps: ungoverned tool access, absent per-user identity, and no decision-level audit trail. None of those gaps had anything to do with model quality.
The 66-percentage-point gap between pilot enthusiasm and production reality is a diagnostic readout on operational infrastructure maturity. The organisations that address these gaps before 2027 will be the ones whose agents survive the decommissioning wave. The organisations that keep waiting for better models will become the next rollback statistic. Their models were capable enough. They just never built the rails those models needed to run on.
Model capability and production readiness are separate problems. A better language model does not give you identity propagation across tool calls, runtime policy enforcement, or decision-level audit trails. The 12% of agents that reach production do not succeed because they use a superior model; they succeed because their organisations built the seven infrastructure layers that make an agent governable, observable, and auditable at scale.
A pilot agent answers the question “can it do the task” under curated conditions. A production agent answers “can it do the task safely, repeatably, and provably” under real-world conditions with real data, real users, and real compliance requirements. The gap between the two is not a matter of scale; it is a matter of infrastructure. Pilots skip governance, observability, and cost measurement. Production cannot.
There is no standard timeline, but the data suggests most organisations underestimate the journey by an order of magnitude. The 66-percentage-point gap between pilot activity (78%) and production deployment (12%) indicates that most pilots never make it at all. For those that do, the limiting factor is rarely the agent itself; it is the time required to build identity propagation, evaluation harnesses, and governance infrastructure before the agent can be safely deployed.
Reliability is a function of infrastructure, not a property of agent technology. Traditional SaaS achieves ~5 to 10% rollback rates because decades of DevOps tooling provide monitoring, deployment gates, and incident response. AI agents carry a 74% rollback rate because that same operational infrastructure was never built for non-deterministic systems. The reliability gap closes when organisations apply the same engineering rigour to agent deployments as they do to traditional software.
A rollback is rarely a clean revert to a prior version. In practice, it means the agent is pulled from production, its tool connections are severed, and the team reverts to a manual process while they investigate. For the 41% of enterprises that experience multiple rollbacks in a 12-month window, the pattern is consistent: deploy, discover a failure mode that testing did not catch, withdraw, patch, and redeploy. Each iteration erodes stakeholder confidence and extends the timeline to sustainable production.
Non-deterministic output failure is the most frequently cited trigger. The agent produces a correct answer nine times and a wrong answer on the tenth, and that tenth answer might involve a financial decision, a compliance violation, or a customer-facing error. Without automated evaluation coverage (which only 38% of production agents maintain), organisations cannot catch these failures before deployment. This is why agents without automated evals carry a 47% rollback rate.
If you can connect any MCP server without an enforcement layer reviewing the connection, your tool surface is not safe for production. The minimum viable safety posture requires a gateway that enforces tool allowlists, inspects data flowing through tool calls (DLP), and sandboxes execution so an unvetted tool cannot leak PII or communicate externally. Without this, you are trusting every MCP server author with your enterprise data. That is a pilot posture, not a production one.
The build-versus-buy decision depends on where your organisation sits on the 7-gap maturity model. If you have mature coverage across fewer than three gaps, a platform like Microsoft Foundry compresses the timeline by providing identity, governance, and observability out of the box. If you already have deep infrastructure engineering capability and need custom control across all seven gaps, a build approach may be appropriate. Most enterprises fall into the former category.
Industries with existing compliance infrastructure and structured workflows lead production adoption. Financial services and insurance, where regulatory requirements already demand audit trails and access controls, have an advantage because the governance scaffolding for agents overlaps with their existing controls. Conversely, industries with high-variability, unstructured work and lighter regulatory frameworks often underestimate the infrastructure gap and experience higher rollback rates.
Start with exception-based human-in-the-loop deployment. Route low-confidence agent outputs to a human review queue rather than directly to production systems. This pattern, combined with basic identity propagation (so you always know who the agent acted as), gives you a safety net while you build the remaining infrastructure layers. The HITL rate will vary by domain; legal and compliance use cases may require 61% human review, while sales development may settle at 8%.
Yes, and this is one of the least-discussed production risks. Model behaviour drifts as prompts change, tool APIs evolve, and edge cases accumulate. Without continuous evaluation pipelines that run on every prompt change, drift goes undetected until it causes a failure. This is why evaluation coverage is not a one-time gate; it is continuous infrastructure. Organisations that treat evaluation as a pre-deployment checkpoint rather than a production monitoring function are accumulating undetected drift.
The agentic loop multiplier means production costs can be 5 to 30 times higher than pilot estimates. An agent that costs $0.03 per single-query interaction in testing can cost $0.90 in production because it makes multiple reasoning turns, calls tools, and retrieves context on every task. Without cost-per-task tracking and model usage chargebacks (AI FinOps), organisations discover this delta on their cloud bill, not in their planning model. That surprise destroys the business case.
Undersea Cable Sabotage: The New Front of Geopolitical Infrastructure Warfare Threatening the Global InternetBeneath the world’s oceans, roughly 500 fibre-optic cables carry 99% of intercontinental internet traffic across 1.6 million kilometres of seabed. Every financial transaction, every diplomatic cable, every video call runs through them.
Since 2022, ten Baltic Sea cables have been cut, seven within a single 60-day window. The perpetrators exploit shallow waters, flag-of-convenience vessels, and a legal framework drafted when telegraphs were cutting-edge. The gap between how well we can detect these attacks and how rarely anyone is held accountable is the fault line that defines this emerging theatre of infrastructure warfare.
This series maps the entire landscape: who is attacking, how they do it, what technology exists to stop them, which institutions are mobilising, and why, despite all of the above, no saboteur has yet faced justice. From the Baltic’s unique exposure to seabed sabotage to the attribution and prosecution gap that leaves perpetrators unpunished, each article in this series examines a distinct dimension of the same strategic crisis.
In This Series
Why the Baltic Sea Has Become the Epicentre of Undersea Cable Sabotage. The geography, infrastructure density, and jurisdictional patchwork that make the Baltic the world’s most exposed cable corridor.
Shadow Fleets and Deep-Sea Submersibles: How Russia and China Target Undersea Cables. The two distinct threat models: Russia’s deniable anchor-drag campaign and China’s purpose-built submersible capability.
How Distributed Acoustic Sensing and Seabed Surveillance Protect Undersea Cables. The detection technology, repair logistics, and redundancy architecture that form the defence.
NATO’s Baltic Sentry and the Global Race to Secure Undersea Infrastructure. The institutional mobilisation and the strategic debates shaping cable governance.
Why Undersea Cable Saboteurs Almost Never Face Justice. The attribution gap, the resilience dilemma, and the legal architecture that makes prosecution structurally improbable.
Undersea cables have always been vulnerable to accidental damage from anchors and trawling. Roughly 150 such incidents occur annually, and they have since the first telegraph cables were laid. What changed after 2022 is intent.
Russia’s full-scale invasion of Ukraine triggered a strategic pivot to grey-zone operations against European infrastructure. The goal: target assets below the threshold of armed conflict where NATO’s Article 5 does not clearly apply. Cables are attractive in this calculus. They are essential, unarmed, and governed by a legal framework from 1982 that places enforcement responsibility with flag states, many of which are flag-of-convenience registries with neither the capacity nor the incentive to act.
The Nord Stream pipeline sabotage in September 2022 served as proof of concept that deep-seabed infrastructure is reachable. As one analysis put it, the attack provided “a complete playbook for damaging submarine cables.” Russia had already spent a decade mapping critical infrastructure in the North and Baltic Seas, according to a 2023 Swedish Television investigation. The ships, the routes, the methods: the reconnaissance was done before the shooting started.
Cables are different from other infrastructure in ways that make them ideal grey-zone targets. Physically, they are armoured fibre roughly the diameter of a garden hose, laid unprotected across much of the seabed. They are privately owned and commercially operated, which means no government guards them. And until recently, they were unmonitored in real time. Unlike a power plant or a data centre, there is no perimeter fence and no obvious moment of attack. A cable simply goes dark, and the operator runs an OTDR trace to find the break. The Baltic’s unique exposure to seabed sabotage is a function of geography as much as policy.
The legal framework compounds the vulnerability. Under UNCLOS Articles 113 to 115, enforcement responsibility falls to the flag state of the offending vessel. When that flag is the Cook Islands, Panama, or Tanzania, enforcement is absent in practice. Between January 2024 and July 2025, roughly 44 incidents of cable damage were recorded globally. The baseline of 150 annual faults, mostly from fishing and anchoring accidents, provides cover for the ones that are not accidents at all.
For the full geographic and infrastructure context, read why the Baltic Sea has become the epicentre of undersea cable sabotage.
The Baltic Sea is the world’s most exposed cable corridor, and the numbers tell the story: average depth of 55 metres, over 35 cables connecting the bordering countries, 4,000 ships passing through daily, and only three narrow access points through the Danish Straits.
Shallow water is the primary reason anchor-drag attacks work here. An attack in the 4,000-metre-deep Atlantic requires specialised equipment. In the Baltic, a standard commercial anchor and chain are sufficient. The narrow exclusive economic zones force cables into predictable paths through choke points like the Gulf of Finland, where Russian territorial waters sit within tens of kilometres of NATO members’ coastlines. Finland and Sweden’s NATO accession turned the Baltic into what analysts call a “NATO Lake”, with nine of ten bordering countries now alliance members. The cables that connect NATO allies run through water Russia can reach from its home ports. This intersection of geography and infrastructure density is what makes the Baltic uniquely vulnerable.
The timeline of incidents is stark. Ten subsea cables have been cut since 2022, with seven occurring between November 2024 and January 2025. The damaged systems include C-Lion1 (Finland to Germany), BCS East-West Interlink (Lithuania to Sweden), EstLink 2 (the Finland-Estonia power cable), and Balticonnector (the Estonia-Finland gas pipeline). Power cables, gas pipelines, and data cables share the Baltic seabed in corridors sometimes less than a kilometre wide. A single anchor drag can, and has, damaged multiple infrastructure types simultaneously.
Most incidents occur in EEZs, where coastal states have limited enforcement authority over foreign-flagged vessels. Proximity to Russian ports (St. Petersburg, Kaliningrad) means suspect vessels are within hours of a safe harbour. The Red Sea chokepoint at Bab el-Mandeb demonstrates that Baltic vulnerability is not unique. It is the most advanced instance of a global pattern where geography, infrastructure density, and jurisdictional ambiguity create the conditions for sabotage.
Cable landing stations are the attack surface that gets least attention. A single station can terminate multiple cables. Physical security is typically the responsibility of the cable owner, not the state. They are known, fixed, unhardened locations, often in publicly accessible coastal areas. A single station can sever multiple systems at once, and attacking one requires less sophistication than a seabed operation while potentially causing more disruption.
Read the full analysis in why the Baltic Sea has become the epicentre of undersea cable sabotage.
Russia’s shadow fleet is an estimated 600 to 1,600 ageing tankers registered under flags of convenience (Cook Islands, Panama, Liberia) with ownership chains obscured through shell companies. The fleet’s primary purpose is sanctions evasion: transporting Russian crude above the $60 per barrel price cap using Western insurance and shipping services. Around 60% of Russia’s seaborne oil exports use this network.
But the shadow fleet has a dual-use capability. “Russia is transforming the shadow fleet from a system for evading sanctions into an instrument of hybrid warfare,” according to researchers at the German Institute for International and Security Affairs. The operational characteristics that serve sanctions evasion also serve sabotage: poor maintenance makes AIS failure and anchor incidents plausible, flag-of-convenience registration creates jurisdictional fog, and frequent name and ownership changes defeat tracking. The shadow fleet and deep-sea submersible threat represents two distinct operational models converging on the same target set.
The signature method is the anchor-drag attack. A vessel approaches a cable corridor, deactivates its AIS transponder, deploys or extends its anchor, and steams across the corridor. The anchor tears through cables on the seabed, often damaging multiple systems in a single pass. The Baltic’s 55-metre average depth means a standard anchor reaches the seabed easily. The method maintains enough ambiguity about intent to frustrate prosecution because anchors do drag accidentally and AIS transponders do malfunction on poorly maintained vessels.
The Eagle S incident in December 2024 is the most thoroughly documented case. A Cook Islands-flagged tanker linked to Russia’s shadow fleet dragged its anchor across the Gulf of Finland for what investigators estimate was 56 nautical miles, damaging EstLink 2 and four further subsea cables. Finnish authorities seized the vessel. The captain was reportedly instructed via radio to destroy evidence, specifically charts depicting local subsea cable routes. The case was dismissed on jurisdictional grounds: the Helsinki Court interpreted UNCLOS such that jurisdiction lay only with the flag state (Cook Islands) or crew nationality, not Finland.
The Fitburg investigation illustrates the evidence-gathering burden even when suspects are identified. The vessel’s ownership was characteristically opaque: built in Romania, previously named Finex and Volmeborg, owned by a Turkish firm, sailing between Russia and Israel, crewed by Georgians and Kazakhs. Finnish intelligence (Supo) took 19 months from the November 2024 incident to reach a referral stage in June 2026.
There is a more sophisticated track operating in parallel. Russia’s GUGI (Main Directorate of Deep-Sea Research) operates specialised vessels like the Yantar, equipped with deep-sea submersibles capable of accessing cables at depth. In May 2025, Russia deployed an Su-35 fighter jet to overfly a shadow-fleet tanker to deter an Estonian interception attempt, demonstrating willingness to escalate militarily in defence of the fleet’s operations.
Read the full threat actor analysis in how Russia and China target undersea cables.
China’s undersea cable threat profile is different from Russia’s. Where Russia relies on deniable, low-tech anchor-drag attacks through a distributed civilian fleet, China has developed purpose-built deep-sea cable-cutting submersibles, patented by PLA-linked research institutions and field-tested at extreme depths. The two threat models that define undersea cable warfare require fundamentally different defensive postures.
In April 2026, China tested a deep-sea cable-cutting device from the research vessel Haiyang Dizhi 2 at 3,500 metres. The device uses a six-inch diamond-coated grinding wheel spinning at 1,600 RPM, capable of breaching reinforced sheaths at 4,000 metres. This is not a prototype. The PLA Navy’s Institute of Communication Application patented a deep-sea optical cable shear and retrieval device as early as 2013. The PLA Naval University of Engineering patented a cable-retrieval system in 2022 that severs and secures both ends of cut cables simultaneously. This is a decade-plus technology development programme, not a recent improvisation.
The primary theatre is the Taiwan Strait, not the Baltic. Taiwan connects to the global network through just 24 undersea cables: 14 international and 10 domestic. The Matsu Islands incident in February 2023 saw Chinese ships sever two cables, resulting in a 50-day digital blackout for 14,000 residents. In early 2025, Chinese-operated ships dragged their anchors across cables connecting Taiwan. Taiwan sentenced the Chinese captain of the Hongtai 58 to three years in prison, the first time Taiwanese authorities have imposed serious criminal penalties for cable damage. But that prosecution was within territorial waters, not international waters, and is the exception that proves the rule.
The contrast with Russia’s Baltic model is instructive. Russia uses distributed, deniable, low-tech methods for persistent harassment. China is developing centralised, attributable, high-tech capability for a military contingency. Cable sabotage fits into China’s “Three Warfares” strategy: psychological, media, and legal warfare aimed at undermining Taiwan’s will to resist. As Ray Powell, director of Stanford’s Sea Light project, observes: “The entire gray zone is about maintaining just enough deniability that even though the evidence overwhelmingly points to the perpetrator, affected nations cannot definitively prove intent.”
The two theatres are not separate. Chinese-flagged vessels have appeared in Baltic incidents: the Newnew Polar Bear was linked to the October 2023 Balticonnector damage, and the Yi Peng 3 was detained by Denmark in November 2024. The Hudson Institute notes that “the coordinated nature of these incidents, with Chinese vessels targeting European undersea assets in exchange for Russian assistance near Taiwan, suggests that the two regimes are sharing tactics, intelligence, and operational assets.”
Read the comparative analysis in how Russia and China target undersea cables.
Distributed Acoustic Sensing (DAS) transforms existing fibre-optic cable infrastructure into a continuous seabed listening grid. The technology sends laser pulses down unused “dark” fibre strands and analyses the Rayleigh backscatter: microscopic light reflections perturbed by acoustic events like an anchor dragging or a vessel propeller. A 100-kilometre cable becomes 10,000 virtual sensors, each 10 metres long, polling at least 1,000 times per second. This is the foundation of DAS and seabed-to-space surveillance, the most significant technology advance in cable protection.
The operating principle is straightforward. A device called an interrogator sends coherent laser pulses down the fibre. Microscopic impurities in the glass create Rayleigh backscatter. Acoustic sources generate strain waves that perturb the backscatter pattern. Analysis of the perturbation reveals the nature, location, and timing of the acoustic event. The technology can detect vessel trajectory, speed, and depth, with speed estimation errors consistently below 1%.
The strategic advantage is that DAS requires no new seabed hardware. It uses fibre already in place. A single interrogator unit, costing approximately $200,000 or more, can monitor tens of kilometres of cable. SOSUS, the Cold War-era US Navy seabed hydrophone array, proved that persistent undersea monitoring had strategic value. DAS delivers that capability through commercial fibre rather than military hardware.
Finland deployed DAS operationally in June 2026 through telecom operator Elisa, in cooperation with the Finnish Border Guard and Finnish Navy. It is the first real-time cable-protection application of a technology that previously existed only in research and trial contexts. “The protection of undersea infrastructure is a nationally important task,” said Jouni Petrow, Elisa’s Director of New Business. “The recent cable breaks in mind, we have built a solution that provides an early warning of an approaching threat.”
The operational significance is real. Real-time detection means authorities can be alerted while a vessel is still in the cable corridor, creating the possibility of interdiction rather than post-incident investigation. The UK’s STFC Hartree Centre has worked with Indeximate to apply machine learning to DAS data for real-time vessel detection, distinguishing vessel acoustic patterns from environmental noise.
DAS provides the acoustic detection layer. Identification requires integration with AIS tracking, satellite imagery, and surface radar: a seabed-to-space architecture where each layer depends on the others. That integration is what the next section on redundancy builds toward.
Read the full technology explainer in how DAS and seabed surveillance protect undersea cables.
Route bifurcation (building two or more physically separated cable paths between endpoints) means a single cut does not isolate connectivity. Traffic reroutes automatically via BGP and SDN, and users typically notice nothing. When two Baltic cables were damaged in November 2024, RIPE NCC, Cloudflare, and Kentik all recorded minimal impact on regional internet traffic.
This has been the cable industry’s primary resilience strategy for decades, and it works well for random failures. But the model was designed for accidental damage from anchors, trawling, and earthquakes, not for an adversary who studies cable routes and targets the convergence points. The limits are structural, and the detection and resilience technology now being deployed addresses some but not all of them.
First, cost. Each additional route is a multi-hundred-million-dollar investment.
Second, geography. Narrow corridors force convergence. In the Gulf of Finland, all Finland-Estonia cables share the same narrow path regardless of how many routes exist. Physical separation is not possible when the sea forces cables together. The Bab el-Mandeb chokepoint in the Red Sea creates the same dynamic in a different theatre: geography overrides engineering.
Third, landing station convergence. Bifurcated routes that terminate at the same shore facility create the same single-point failure that redundancy was designed to eliminate. An attacker who knows the landing station locations (they are public information) can achieve with one strike what route diversity was meant to prevent.
The ownership dimension complicates the resilience picture. Hyperscalers (Google, Meta, Microsoft, Amazon) now own or co-own more than 50% of intercontinental cable capacity. Their share of transatlantic capacity has expanded from roughly 10% in 2014 to approximately 90% by 2024. In 2024, hyperscalers accounted for 71% of international capacity used by EU member states. Infrastructure owned by traditional European operators now represents roughly 2% of total transatlantic capacity.
Hyperscalers build redundancy for commercial continuity, and their networks are resilient by design. But their routing decisions optimise for their own traffic, not national resilience. A government concerned with strategic connectivity may have different redundancy requirements than a commercial operator, and the two do not always align.
The global cable repair fleet is itself a bottleneck. Approximately 62 to 75 cable ships exist worldwide. Of 62 vessels tracked, 19 are contracted for maintenance, 26 for installation, and 16 switch between both. None are owned by governments. The global median repair time is approximately 40 days. In favourable Baltic conditions, the full process requires at least 14 days. A single repair vessel can cost over €50 million, and the commercial repair market operates with narrow profit margins: vessels are maintained for routine fault rates, not surge capacity.
Read the full resilience analysis in how DAS and seabed surveillance protect undersea cables.
NATO’s Baltic Sentry, launched in January 2025, is the alliance’s first operation specifically tasked with undersea infrastructure protection. It deploys frigates from multiple member states, P-8 Poseidon and Atlantique 2 maritime patrol aircraft, and 20-plus uncrewed surface vessels conducting persistent surveillance in the Baltic. Task Force X-Baltic (TFX-Baltic), NATO’s experimental unit for uncrewed seabed monitoring, uses USVs and UUVs to extend surveillance coverage beyond what crewed vessels can sustain. Eight Baltic NATO states plus France, the Netherlands, and the US participate. This is the institutional response to seabed warfare that the threat landscape demands.
The operational concept is presence-based deterrence: visible NATO patrols that raise the risk calculus for would-be saboteurs. NATO reports a significant reduction in malicious sabotage between January 2025 and January 2026, with response times dropping from 17 hours to one hour. “Baltic Sentry demonstrates that Allies have the political will and operational capabilities to sustain a collective defence capability,” said Lt. Cmdr. Tim Pietrack of NATO Allied Maritime Command. “We’ve seen 12 boardings under national authorities by allied nations in the past year.”
Several complementary initiatives operate alongside Baltic Sentry. Nordic Warden, under the UK-led Joint Expeditionary Force, focuses on intelligence fusion, data sharing, and AI-enabled vessel tracking rather than operational patrol presence. Baltic Sentry provides the visible deterrent; Nordic Warden provides the intelligence architecture that tells the deterrent where to look. Gotland Sentry is Sweden’s unilateral cable-protection patrol.
The EU takes a different approach. Its Cable Security Toolbox and Action Plan (February 2026) introduced a €347 million subsea infrastructure initiative, the largest EU-level investment to date. The plan operates through regulatory authority and economic levers: vulnerability assessments, repair-capacity coordination, sanctions mechanisms, and diplomatic pressure. The EU’s €20 million Rapid Repair Pilot represents roughly 5.7% of the overall initiative, focused on pre-positioning modular repair equipment in regional ports.
The difference is institutional. NATO operates in the security domain through military means: patrol, deter, interdict. The EU operates in the regulatory and economic domain through civilian means: coordinate, invest, sanction. Neither framework alone is sufficient. NATO can patrol but not regulate. The EU can coordinate but not patrol. Their coordination in practice, across different member-state compositions, decision-making timelines, and legal authorities, remains largely untested.
The US Strategic Subsea Cables Act of 2026 provides the American parallel to the EU’s regulatory approach. It requires the President to impose sanctions against individuals who intentionally damage subsea cables, establishes an interagency committee, mandates threat information sharing with private operators, and requires at least ten dedicated State Department staff for cable diplomacy.
Read the full institutional analysis in NATO’s Baltic Sentry and the global race to secure undersea infrastructure.
Neither approach has demonstrated effectiveness, but for different reasons. The comparison sits at the heart of the institutional response to seabed warfare that NATO and the EU are racing to build.
Military deterrence through presence-based patrols is proactive. Assets operate in real time, and Baltic Sentry has reduced response times from 17 hours to one hour. NATO reports fewer incidents since the operation launched. But attacks continued after January 2025: the Fitburg incident occurred in December 2025, well into Baltic Sentry’s deployment. The challenge is that presence-based deterrence in a grey-zone context suffers from an ambiguity problem: what exactly are you deterring when the attack is designed to be deniable? The attacker can always claim accident, and the deterrent signal is correspondingly weakened.
Legal accountability is reactive, following the attack, and has produced zero convictions for undersea cable sabotage globally. The Eagle S case, the most thoroughly documented incident with the vessel seized in the act, was dismissed on jurisdictional grounds. The Chinese Yi Peng 3, suspected of cutting two Baltic cables in 2024, was released after brief detention by a NATO member state. This is precisely the attribution and prosecution gap that undermines the entire deterrence architecture.
The problem is not that investigators cannot identify suspects. It is that the gap between intelligence-level certainty and criminal-standard proof is wide, and the UNCLOS framework places enforcement responsibility with flag-of-convenience states that have no incentive to act. “Criminal prosecutions, constrained by jurisdictional and evidentiary hurdles, seem poorly suited to effectively deter future actions or even impose meaningful costs on those responsible,” one legal analysis concluded. “If states rely solely on criminal prosecutions, their success is questionable and failure will embolden further hybrid threat actors.”
Military deterrence at least operates proactively. Legal accountability is structurally reactive, and the reaction, when it comes, has been consistently insufficient. The honest assessment is that neither approach has built a convincing evidence base, and the attackers appear to understand this. Why attribution fails so consistently is the next question.
Read the full comparison in NATO’s Baltic Sentry and the global race to secure undersea infrastructure.
Attribution is a three-layer problem, and success at one layer does not guarantee success at the next. The attribution and prosecution gap represents the critical failure point in the entire detection-and-response chain.
Technical attribution, which vessel was present, what happened, where, is increasingly robust. DAS detects acoustic signatures in real time. AIS tracking shows vessel movements, including the pattern of transponder deactivation and reactivation that marks a suspicious transit. Satellite imagery confirms vessel positions independently. Anchor-drag forensic analysis matches damage patterns to specific anchors. Technical attribution is not the bottleneck.
Legal attribution, proving intent to a criminal standard, is where most cases fail. Anchor drags happen accidentally. AIS failures are common on poorly maintained vessels. Crew testimony requires international cooperation across jurisdictions that may be uncooperative. Chains of ownership through shell companies obscure beneficial ownership. The forensic indicators of intent (AIS deactivation pattern, course deviation to intersect cable routes, multiple cables struck, shadow-fleet ownership links) are probabilistic, not deterministic. They build a pattern that convinces intelligence analysts but may not satisfy a criminal court’s “beyond reasonable doubt” standard. The Eagle S demonstrated most of the intent indicators and was still dismissed because the Helsinki Court ruled jurisdiction lay only with the flag state or crew nationality.
Political attribution, which state is responsible and what response is appropriate, can fail even when the first two layers succeed. States may choose not to escalate a grey-zone incident to avoid broader confrontation. The Yi Peng 3 case demonstrated this: diplomatic negotiations between Denmark, China, Sweden, Finland, and Germany produced paralysis rather than action. Finnish intelligence Supo publicly stated in March 2026 that investigations found “no evidence of deliberate Russian state activity,” a view its director described as “broadly shared in the other European intelligence community.” That assessment sits in tension with the US Congress’s characterisation of deliberate state-sponsored sabotage. The intelligence community itself cannot agree on what the evidence means.
As Ray Powell of Stanford’s Sea Light project puts it: “China and Russia will continue this behavior because they calculate that the consequences will not be severe enough to warrant stopping.” That calculation, as of mid-2026, appears to be correct.
Read the full attribution analysis in why undersea cable saboteurs almost never face justice.
The resilience dilemma is the paradox that measures which make cable infrastructure more resilient simultaneously weaken the legal case against saboteurs. If a cut cable causes no user-visible outage because traffic rerouted seamlessly, what was the harm? If rapid repair disturbs or removes seabed evidence before investigators can examine it, what can be proven? If operators do not immediately notice a cut because automatic rerouting masks it, when was the crime? This is the core tension that the attribution and prosecution gap analysis explores in full.
Walk through each dimension. Route bifurcation: a cut cable causes no user-visible outage. Traffic reroutes in milliseconds, users notice nothing, and the legal question “what harm was caused?” becomes difficult to answer with the specificity a court requires. Rapid repair: the EU’s €20 million Rapid Repair Pilot aims to accelerate recovery, but faster recovery reduces the window for forensic examination and may disturb or destroy seabed evidence during the retrieval process. Automatic rerouting: operators relying on automated systems may not detect a cable cut for hours or days, creating uncertainty about the time of the offence that complicates the evidentiary chain.
The Finnish court’s Eagle S dismissal illustrates the problem directly. As CEPA’s analysis noted, the case “highlights the ‘resilience dilemma’: countries’ efforts to protect and harden their undersea infrastructure, and to build in redundancy, can make it harder to make a case against bad actors.”
The dilemma creates a self-reinforcing strategic feedback loop. Detection technology works: DAS can identify an anchor drag in real time. Institutional machinery is mobilising: Baltic Sentry, the EU Cable Security Toolbox, the Strategic Subsea Cables Act. But the resilience measures that make the network robust against disruption simultaneously undermine the legal basis for prosecution. Without prosecution there is no meaningful deterrence. Without deterrence, the incentive to invest in resilience increases, feeding back into the loop. The deterrence strategies that depend on fixing attribution remain unproven until the legal dimension is resolved.
This is not a theoretical concern. It is the operational reality of every Baltic cable cut since 2023: the network stayed up, users noticed nothing, and the legal basis for prosecution was weakened. The more resilient the network, the harder it is to establish that a prosecutable offence occurred.
There is a parallel tension in the strategic debate. The same interconnection that securitisation advocates frame as vulnerability has, in practice, functioned as resilience. Dense, redundant networks enable rerouting and limit disruption. Connectivity, not bifurcation, underwrites resilience. Fragmentation risks brittleness. But the resilience that interconnection provides is precisely what frustrates prosecution. The dilemma is not resolvable by choosing one approach over the other. It is built into the architecture.
Read the full legal analysis in why undersea cable saboteurs almost never face justice.
Why the Baltic Sea Has Become the Epicentre of Undersea Cable Sabotage. Examines the geographic choke points, seabed infrastructure density, and jurisdictional patchwork that make the Baltic the world’s most exposed cable corridor. You will understand the timeline of incidents since 2022, why shallow-water geography enables low-tech attacks, and why cable landing stations represent an overlooked single-point failure.
Shadow Fleets and Deep-Sea Submersibles: How Russia and China Target Undersea Cables. Analyses the two distinct threat models: Russia’s shadow fleet and deniable anchor-drag campaign versus China’s purpose-built deep-sea submersible capability. You will understand the Eagle S case, the operational methods used in each theatre, and why the two threat models require different defensive postures.
How Distributed Acoustic Sensing and Seabed Surveillance Protect Undersea Cables. Explains the technology transforming cable protection: DAS, seabed-to-space situational awareness, and the repair logistics that determine whether a cut cable is a nuisance or a crisis. You will understand how Finland’s June 2026 operational deployment works, why the global repair fleet is a strategic bottleneck, and where routing redundancy succeeds and where it fails.
NATO’s Baltic Sentry and the Global Race to Secure Undersea Infrastructure. Evaluates the institutional mobilisation and strategic debates: Baltic Sentry, the EU Cable Security Toolbox, the US Strategic Subsea Cables Act, and the competing frameworks of military deterrence, regulatory coordination, securitisation, and cooperative interconnection. You will understand the evidence for and against each approach and the trade-offs that policymakers face.
Why Undersea Cable Saboteurs Almost Never Face Justice. Exposes the failure point in the entire detection-and-response architecture: the legal framework that makes prosecution structurally improbable. You will understand the UNCLOS enforcement gaps, the three-layer attribution problem, the resilience dilemma that weakens the legal case as infrastructure improves, and why, as of mid-2026, no cable saboteur has been convicted.
Suggested reading order: Start with the Baltic vulnerability backgrounder to understand the geography and stakes, then the threat actor analysis to see who is operating and how. The detection and institutional response articles build on that foundation. The legal analysis serves as the capstone that exposes the unresolved strategic tension.
How many undersea cables cross the Baltic Sea and how much traffic do they carry?
The Baltic Sea hosts over 35 cable systems, ranging from high-capacity transcontinental links like C-Lion1 (Finland to Germany) to regional systems connecting Nordic and Baltic states. There is no single authoritative public count, but the density is among the highest of any sea basin globally relative to its size. The cables carry financial transactions, cloud-computing traffic, military communications, and consumer internet for the entire Nordic-Baltic region. For the foundational infrastructure context, see the Baltic vulnerability analysis.
How has China actually been involved in undersea cable incidents?
Chinese-flagged or Chinese-linked vessels have been implicated in both the Baltic and Taiwan theatres. In the Baltic, the Newnew Polar Bear (Hong Kong-registered, Chinese-owned) was linked to the October 2023 Balticonnector damage, and the Yi Peng 3 (Chinese-flagged) was detained by Denmark in November 2024. In the Taiwan Strait, the Hongtai 58 severed a cable connecting Taiwan and Penghu Islands in February 2025. Separately, PLA-linked research institutions have developed and tested purpose-built deep-sea cable-cutting submersibles. For the full threat profile, see the shadow fleet and submersible analysis.
Can undersea cables be repaired, and how long does it take?
Yes. Cables are repaired by a global fleet of approximately 60 to 75 specialist ships (roughly 20 of which are contracted for maintenance) using a well-established process: OTDR fault localisation, grapnel retrieval from the seabed, precision fibre splicing aboard the vessel, and redeployment. The timeline ranges from 48 hours in favourable conditions to several weeks for remote deep-water locations, with a global median of approximately 40 days. The repair fleet (commercially operated, mostly built in the 1990s to 2000s, with no government-owned surge capacity) is itself a strategic bottleneck. For the full repair process, see the detection and resilience explainer.
What would be the economic consequences of a coordinated, large-scale undersea cable disruption?
No comprehensive economic model exists for a multi-region coordinated cable disruption. The most cited single-region estimate, for Taiwan, projects losses of approximately $55 million per day and $1.69 billion per month. Equivalent modelling for a Baltic Sea, Red Sea, or transatlantic scenario has not been published. The financial transaction volume alone (SWIFT and interbank settlement traffic that transits undersea cables) suggests the daily cost of a coordinated disruption across multiple chokepoints would be measured in billions, not millions. For the economic stakes, see the institutional response analysis.
What is “weaponised interdependence” and how does it apply to undersea cables?
Weaponised interdependence, the framework developed by Henry Farrell and Abraham Newman, describes how states can exploit the global networks they are embedded in, using panopticon effects (surveillance through infrastructure access) and chokepoint effects (denial by controlling critical nodes). Applied to undersea cables, the framework explains why interconnection creates vulnerability: the same network architecture that makes the global internet work also creates chokepoints that states can exploit. This informs the debate over whether the right response is to withdraw into trusted corridors or to strengthen multilateral governance. For the full strategic analysis, see the institutional response comparison.
Has anyone ever been prosecuted for undersea cable sabotage?
No. No individual or organisation has been successfully prosecuted for deliberate undersea cable sabotage in any jurisdiction. The Eagle S case, the most thoroughly documented incident with the vessel seized in the act, was dismissed on jurisdictional grounds. Taiwan sentenced the Chinese captain of the Hongtai 58 to three years in prison for the Penghu cable severance, but that prosecution was for violating Taiwanese law within its territorial waters. It is the closest any case has come to accountability. For the full legal framework, see the prosecution gap analysis.
What is the difference between Baltic Sentry and Nordic Warden?
Baltic Sentry is a NATO operation launched in January 2025: a multinational military deployment of frigates, maritime patrol aircraft, and uncrewed surface vessels conducting persistent surveillance in the Baltic Sea. Nordic Warden is a complementary but distinct initiative under the Joint Expeditionary Force (JEF), a UK-led minilateral grouping of Nordic and Baltic states that focuses on intelligence fusion, data sharing, and alerting rather than operational patrol presence. Baltic Sentry provides the visible deterrent; Nordic Warden provides the intelligence architecture that tells the deterrent where to look. For the full operational comparison, see the institutional response analysis.
How much does undersea cable protection cost, and who pays for it?
There is no single answer. Cable protection costs are distributed across private operators, national governments, and multilateral institutions. Cable owners bear the costs of repair (typically AU$1.5 to 3 million per operation, largely covered by insurance) and redundancy (each additional route is a multi-hundred-million-dollar investment). Governments fund surveillance (Baltic Sentry’s rotating member-state contributions) and regulatory infrastructure (the EU’s €347 million cable security initiative, including a €20 million Rapid Repair Pilot). DAS represents a relatively low marginal cost since it uses existing fibre, but the sensor fusion architecture that makes it actionable requires ongoing investment. For the cost-effectiveness comparison, see the institutional response analysis.
Why Undersea Cable Saboteurs Almost Never Face JusticeIn December 2024, Finnish authorities seized the Eagle S, a Cook Islands-flagged tanker, after its anchor dragged across the Baltic seabed and severed the Estlink 2 power cable and four telecommunications cables. The vessel was physically detained. The crew was questioned. Forensic evidence was gathered from the seabed, from AIS records showing the transponder had been switched off in the cable corridor, and from satellite imagery confirming course deviation. This is as close to catching a saboteur in the act as maritime law gets.
The case was dismissed. On 3 October 2025, the Helsinki District Court ruled that Finland lacked jurisdiction over acts committed by a foreign-flagged vessel in its Exclusive Economic Zone, and that the disruption caused was not severe enough to warrant criminal charges. Network redundancy meant nobody noticed the cables were down.
Detection technology works. Distributed Acoustic Sensing pinpoints cable breaks in real time. AIS records track vessel movements. Satellite imagery confirms positions. Yet as of mid-2026, not a single perpetrator has faced criminal prosecution for undersea cable sabotage. Detection works. The bottleneck is the legal architecture — a failure that sits at the heart of the broader geopolitical infrastructure warfare landscape.
The Eagle S was not a subtle operation. The vessel deactivated its AIS transponder before entering the cable corridor, deviated from its course to intersect cable routes, and dragged its anchor across multiple cables. Investigators found transmitting gear, laptops with Russian and Turkish keyboards, and sensor-type devices onboard, equipment atypical for commercial shipping. The vessel was registered in the Cook Islands, operated by an Indian company in Mumbai, and crewed primarily by Indian and Georgian nationals. Damages claimed by affected cable companies reached almost €56 million.
The Helsinki Court interpreted Articles 97 and 113 of UNCLOS to mean that jurisdiction lay only with the flag state, the Cook Islands, or with the crew’s nationalities, Georgia and India. Finland, as the coastal state where the damage occurred, had no authority to prosecute. The Cook Islands, a small Pacific nation with no Baltic presence and no investigative capacity, took no action.
The case exposed a chain of failure across three layers: technical attribution (identifying the vessel), legal attribution (proving intent), and political attribution (states willing to name and respond). Technical attribution worked. The other two collapsed. Catching saboteurs and prosecuting them are fundamentally different thresholds, and the gap between them is where impunity lives. If catching the vessel in the act did not lead to prosecution, the problem runs deeper than detection. It starts with how we define attribution itself.
Attribution is not one problem. It is three, and success at each layer is necessary but not sufficient.
Technical attribution is the most robust layer. DAS acoustic signatures detect the event, AIS records identify vessel positions, satellite imagery confirms locations, and anchor-drag forensic analysis matches damage patterns to specific anchors. This technology works.
Legal attribution, proving intent to a criminal standard, is where most cases collapse. Anchor drags happen accidentally. AIS transponders malfunction on poorly maintained vessels. Crew testimony requires multinational cooperation, and chains of shell-company ownership obscure beneficial ownership across multiple jurisdictions. The Fitburg, a vessel flagged to a convenience registry, owned by a Turkish shell company, and crewed by Georgian and Kazakh nationals, was detained after cable damage in the Baltic. The Finnish Security and Intelligence Service, Supo, spent 19 months gathering forensic seabed evidence, vessel records from a convenience registry, and crew testimony across multiple jurisdictions before reaching referral threshold, and the outcome remains uncertain. The Eagle S and Fitburg cases that exposed the legal gaps reveal a pattern where even successful technical attribution cannot guarantee prosecution.
Political attribution, the willingness of states to name a perpetrator and respond, can fail even when both technical and legal attribution succeed. Fear of escalation with a nuclear-armed adversary means governments may choose inaction. When Denmark detained the Chinese-flagged Yi Peng 3 in November 2024, a bulk carrier suspected of severing two Baltic data cables, the investigation became a multilateral diplomatic negotiation involving five states. China ultimately conducted its own inspection with only Swedish observers present before the vessel departed.
UNCLOS Articles 113 to 115 form the foundation. Every signatory must criminalise deliberate or negligently caused cable damage by vessels flying their flag. Article 113 specifically requires states to make cable breaking “willfully or through culpable negligence” a punishable offence.
These provisions were inherited from the 1884 Convention for the Protection of Submarine Telegraph Cables. It was built for an era when cable damage was a commercial nuisance. Three structural gaps make it inadequate for the current threat environment.
First, flag-state enforcement. Only the state whose flag a vessel flies bears primary responsibility for investigation and prosecution. When that state is a convenience registry with no capacity or incentive to act, enforcement evaporates.
Second, EEZ jurisdictional ambiguity. Coastal states hold full sovereignty in territorial waters, 12 nautical miles from shore, but only resource-related rights in the Exclusive Economic Zone, which extends to 200 nautical miles. Cable protection is not clearly included in coastal state EEZ powers, meaning most cable cuts fall into an enforcement grey zone where coastal states cannot prosecute foreign-flagged vessels without flag-state consent.
Third, UNCLOS has no dedicated enforcement mechanism. There is no international cable-protection prosecutor, no tribunal with compulsory jurisdiction over cable damage, and no obligation on states to cooperate in prosecution. UN General Assembly Resolution 78/69 of December 2023 recognised the problem diplomatically but imposed no binding obligations. It was diplomatic recognition without enforcement weight.
The flag-of-convenience system is not a loophole. It is the architecture’s design failure.
UNCLOS assigns enforcement to the flag state, an approach that assumes flag states have a genuine connection to their vessels and will enforce the law. In practice, the world’s largest ship registries, Panama, Liberia, the Marshall Islands, and the Cook Islands, operate as open registries. Any vessel owner can register. Fees are low. Regulatory oversight is minimal. There is no requirement for a genuine link between the vessel’s operations and the flag state.
When the Eagle S damaged cables in the Baltic, the Cook Islands was the state legally responsible for prosecution. It did nothing. When the Fitburg was detained, the flag state was absent. This is the outcome of a system where enforcement responsibility is assigned to states that were never intended to enforce.
The gap is self-reinforcing. States that sponsor sabotage deliberately flag their vessels in convenience registries precisely because those registries will not investigate. Coastal states in whose EEZs the damage occurs cannot prosecute without flag-state consent. Denmark has responded with intensified inspections of shadow-fleet tankers transiting the Danish straits, but port state control cannot substitute for criminal prosecution. The flag-of-convenience system makes cable sabotage effectively decriminalised for any state willing to operate through it.
Even if the jurisdictional barriers could be overcome, if a coastal state could prosecute, a separate problem waits: the forensic evidence itself is rarely conclusive enough for a criminal court.
The forensic evidence is probabilistic, not deterministic. The criminal standard of proof becomes the barrier.
Indicators of intent form a cumulative pattern. A vessel deactivates its AIS transponder before entering a cable corridor and reactivates after exiting, pattern evidence, not a one-off malfunction. An anchor is deployed in a known cable corridor with no navigational reason: no designated anchorage, no emergency, no standard commercial route. The vessel deviates from its course to intersect cable routes. The anchor-drag track crosses multiple cables, suggesting deliberate targeting rather than a single snag. Vessel ownership links to shadow-fleet networks through opaque shell companies.
Indicators of accident form the contrasting profile. AIS remains active throughout. The anchor is deployed in a designated anchorage or during a documented emergency. The vessel stays on a standard commercial route. Only a single cable is struck. Vessel ownership is transparent and commercial.
The problem is that these indicators are necessary but not sufficient. The Eagle S demonstrated most of the intent indicators, AIS off, course deviation, multiple cables struck, shadow-fleet ownership, and still did not result in prosecution. A defence can always argue AIS malfunction, navigational error, or crew negligence rather than state-directed sabotage. In the absence of a confession or intercepted order, that defence is difficult to disprove. What convinces an intelligence analyst rarely satisfies a criminal court’s beyond-reasonable-doubt standard.
The Yi Peng 3 dragged its anchor for more than 100 nautical miles in the area of the cables and had switched off its transponder for several hours, yet investigators could not bridge the gap from pattern evidence to proof.
The forensic evidence problem is only half the story. A deeper paradox means that even if evidence were perfect, prosecution would still face a structural obstacle, one that grows stronger with every investment in cable resilience.
This is the most counterintuitive failure in the system. The better we defend cables, the weaker prosecution becomes.
Route bifurcation means a cut cable causes no user-visible outage. Traffic reroutes seamlessly, and nobody notices. From a legal standpoint, what was the harm? If no harm is measurable, the basis for criminal charges erodes. Rapid repair compounds this. The faster a cable is fixed, the less time evidence persists on the seabed, and the less disruption accumulates.
The Finnish Eagle S court explicitly ruled that the disruption caused was not severe enough to justify criminal charges, in part because network redundancy mitigated the impact. This was not an incidental finding. It is the logical consequence of resilience investment. Every euro spent on hardening infrastructure simultaneously makes prosecution harder.
The dilemma operates at the strategic level too. If cable sabotage causes no user-visible outage and no economic damage beyond private operator repair costs, governments have less incentive to escalate diplomatically. Resilience protects the public from disruption but also protects perpetrators from consequences. This is the operational reality of every Baltic cable cut since 2023. Across more than a dozen suspected sabotage incidents in the region, the network stayed up, users noticed nothing, and the legal and political basis for prosecution was correspondingly weakened. The pattern is the same whether it is the Eagle S, the NewNew Polar Bear, or the Yi Peng 3: traffic reroutes, the public never sees a disruption, and the case for action dissolves.
This feedback loop ties the entire system together: detection works, institutions are mobilising, but the better the defence, the weaker the case against attackers. This is the core challenge facing the deterrence strategies that depend on fixing attribution.
The accountability gap is a problem of law. UNCLOS was drafted in 1982 for an era when cable damage was a commercial nuisance, not a geopolitical weapon. Its jurisdictional architecture assigns enforcement to states that will never enforce. The three-layer attribution problem separates intelligence certainty from courtroom proof. The forensic indicators that distinguish sabotage from accident are probabilistic, not deterministic. And the resilience that protects connectivity simultaneously weakens the case for prosecution.
Each failure reinforces the others, creating a system where cable sabotage is effectively decriminalised. The question has shifted from how to catch perpetrators to what legal system would make catching them matter. As of mid-2026, after more than a dozen suspected sabotage incidents in the Baltic alone, that question remains unanswered. No amount of surveillance technology or naval presence can close the accountability gap without renegotiating the legal architecture that created it. Closing this gap is the central challenge for the institutional responses attempting to close the gap — responses that, as of mid-2026, have yet to produce a single prosecution.
No. Despite more than a dozen suspected sabotage incidents in the Baltic alone since 2023, not a single perpetrator has faced criminal prosecution. The Eagle S crew were detained, questioned, and released. The Yi Peng 3 departed after China conducted its own investigation with only Swedish observers present. Detection works, but the gap between knowing who did it and proving it in court remains unbridgeable under current law.
For most users, nothing. Modern cable networks are designed with redundant routes, and traffic reroutes automatically within milliseconds. This is precisely the resilience dilemma at work: the system’s robustness means the public never notices a cable cut, which paradoxically weakens the legal case for prosecution because the measurable harm appears negligible. Your Netflix buffers; you blame your Wi-Fi.
Patrols can deter some opportunistic activity but cannot solve the prosecution problem. NATO’s Baltic Sentry operation has increased maritime presence, yet the fundamental legal architecture remains unchanged. A warship can observe a vessel dragging its anchor across a cable corridor, but under UNCLOS it cannot board or arrest a foreign-flagged vessel without flag-state consent. Surveillance without enforcement authority is deterrence theatre, not a solution.
Russia is the primary suspect in the Baltic theatre, where most incidents since 2023 trace back to vessels linked to its shadow fleet. But the Yi Peng 3 case implicated a Chinese-flagged vessel, and the vulnerability is systemic rather than actor-specific. Any state with access to a commercial vessel and a convenience-flag registry can exploit the same legal architecture. The framework fails regardless of which flag the perpetrator ultimately flies.
Typically between one and four weeks, depending on water depth, weather, cable type, and repair ship availability. The global fleet of specialised cable repair vessels numbers fewer than 60 ships, and they are often positioned days away from a break site. This repair timeline is the variable in the resilience dilemma: faster repairs mean less disruption, which means less measurable harm, which means a weaker basis for criminal charges.
Not directly, and this is the core jurisdictional failure. Under UNCLOS Article 113, the flag state holds primary enforcement responsibility. A coastal state where the cable makes landfall has full sovereignty only within its 12-nautical-mile territorial sea. Most cable damage occurs in Exclusive Economic Zones or on the high seas, where coastal states cannot prosecute foreign-flagged vessels without flag-state cooperation, which convenience registries systematically withhold.
No formal treaty process is underway, and the political will for one is weak. UN General Assembly Resolution 78/69 of December 2023 acknowledged the problem but imposed no binding obligations. The states that benefit most from the current framework, convenience registries and the actors who use them, have no incentive to negotiate restrictions on their own impunity. Incremental port-state measures by Denmark and NATO coordination represent workarounds, not structural reform.
Surface vessels cause virtually all confirmed and suspected sabotage incidents. The method is deceptively simple: a ship drops anchor in a known cable corridor, drags it across the seabed, and either snags and breaks cables or causes crushing damage. Submarines could theoretically cut cables with specialised equipment, but surface vessels exploiting anchor-drag ambiguity leave far more plausible deniability. The anchor is a $50,000 sabotage tool with built-in legal cover.
Distributed Acoustic Sensing (DAS) uses the fibre optic cable itself as a sensor, detecting the acoustic signature of a break or anchor strike in real time. Once the general location is known, remotely operated vehicles (ROVs) descend to survey the damage and collect forensic evidence. The technology works well: investigators can reconstruct the anchor-drag path, measure the force of impact, and correlate it with AIS vessel tracks to establish precisely which ship was responsible.
The cable operator bears the cost, and this is another structural weakness in the accountability system. A single cable repair can run between one and three million dollars, paid by the consortium of telecommunications companies that own the cable. They may carry insurance, but insurers increasingly classify cable sabotage as an uninsurable political risk. The operator absorbs the loss, the saboteur faces no financial penalty, and the cost of sabotage is effectively privatised while the benefit accrues to the attacker.
NATO’s Baltic Sentry and the Global Race to Secure Undersea InfrastructureAt least 11 undersea cable sabotage incidents hit the Baltic Sea between October 2023 and December 2025. What followed tells you something about how the West responds to hybrid warfare: NATO launched Baltic Sentry in January 2025, the EU published its Cable Security Action Plan a month later, and the US passed the Strategic Subsea Cables Act in early 2026. Three distinct frameworks. Three different sets of authorities. Three different assumptions about what cable protection actually requires. Each one was a response to a vulnerability that neither military nor legal frameworks were designed to address. None of them has yet demonstrated it can stop the attacks.
The cables themselves carry more than 95% of intercontinental data traffic and somewhere around $10 trillion in daily financial transactions. Getting the protection architecture wrong risks splitting the global internet into national-security silos — the stakes that make the full scope of the undersea infrastructure challenge one of the defining strategic questions of the decade. This article walks through each layer of the strategic problem, from what Baltic Sentry actually deploys to which surveillance technology makes sense for the budget available.
NATO launched Baltic Sentry on 14 January 2025 as an enhanced Vigilance Activity tasked with protecting undersea cables and pipelines in the Baltic Sea. It deploys frigates from Standing NATO Maritime Group 1, maritime patrol aircraft including P-8 Poseidons and Atlantique 2s, and over 20 uncrewed surface vessels for persistent surface monitoring. The operational concept is straightforward: visible patrols raise the risk calculus for anyone thinking about dragging an anchor across a cable corridor.
The launch came out of the Helsinki Summit of Baltic Sea allies, convened after Estlink-2 and Balticconnector made the sabotage campaign a strategic priority. Command runs through Allied Maritime Command at Northwood and Commander Task Force Baltic at Rostock, with Mainsail AI providing a common operating picture that fuses satellite imagery, sonar data, and operator-reported anomalies. The headline number is the response time: cut from 17 hours to roughly one hour through direct information sharing between NATO and cable operators.
Beneath the surface, Task Force X, NATO Allied Command Transformation’s experimental unit, put drones in the water within six weeks of the summit tender call, testing uncrewed underwater vehicles and AI-driven sensor fusion for seabed surveillance. Phase 2, signed by eight Baltic Sea states plus France, the Netherlands, and the US, transitioned from experimental fleets to nationally owned capabilities. Alongside this, the UK-led Joint Expeditionary Force activated Nordic Warden, an AI-based ship-tracking system subsequently handed over to NATO, which compiles a register of shadow fleet vessels and fuses intelligence across the Nordic and Baltic area.
Then there is Gotland Sentry, Sweden’s unilateral cable-protection patrol around Gotland, operating alongside both NATO and EU frameworks as a national initiative filling gaps that institutional coordination has not closed. The Finnish Border Guard launched a maritime surveillance centre in January 2026 specifically for cable monitoring.
The limitation is the one you would expect: Baltic Sentry is an operation, not a permanent architecture. It depends on rotating member-state contributions. When national navies face competing demands, the continuity risk is real.
That institutional impermanence is not unique to NATO. It mirrors a broader fragmentation in how the West organises cable protection: NATO and the EU bring complementary tools to the problem, but they operate on different timelines, with different member-state compositions and different legal authorities. Their coordination in practice remains untested.
On the NATO side: military presence, operational deterrence, and the Article 5 framework, though cable sabotage has never been treated as an armed attack. The Maritime Centre for the Security of Critical Undersea Infrastructure at Northwood coordinates expertise across ten participating nations. Mainsail AI does the anomaly detection. Twelve boardings under national authorities occurred in Baltic Sentry’s first year.
On the EU side: the Cable Security Action Plan, launched February 2025 with approximately €1 billion, operates through civilian institutions. It covers prevention, detection, response, recovery, and deterrence through vulnerability assessments, repair-capacity coordination, and sanctions on shadow fleet operators. The Connecting Europe Facility allocated €327 million for new cable infrastructure. A proposed Cable Vessels Reserve aims to address the repair bottleneck: fewer than 75 cable ships operate worldwide, and the median repair time sits at about 40 days globally. The NIS2 and CER Directives now require cable operators to report security incidents.
The US parallel is the Strategic Subsea Cables Act of 2026, which mandates interagency coordination, sanctions against individuals who damage cables, and threat-information sharing with private operators. It is a regulatory response, not a military one.
The difference is one of authority: NATO can deter but not regulate. The EU can coordinate and sanction but cannot patrol. Do these frameworks add up to coherent defence, or do the gaps at the seams, different decision-making timelines, different member-state compositions (the EU includes non-NATO members; NATO includes non-EU members like the US and UK) create vulnerabilities that attackers are already working through? The evidence does not yet support a clear answer.
Neither approach has demonstrated it works. The structural difference, though, matters: military deterrence operates proactively, while legal accountability only engages after the damage is done. If you are deciding where to put resources, that distinction is worth your attention.
The deterrence evidence is thin. A NATO official noted “zero incidents of malicious damage” between January 2025 and the Fitburg case in December 2025, and the one measurable improvement is the response-time reduction from 17 hours to one. But the seven-incident window from November 2024 to January 2025 coincided with Baltic Sentry’s initial deployment, and whether faster response deters attackers or simply shifts their tactics remains unproven. The Fitburg incident on 31 December 2025 demonstrated that attackers adapted rather than stopped.
The legal evidence is worse. Zero convictions worldwide for undersea cable sabotage. The Fitburg investigation took 19 months to reach a referral stage. In one closely watched example, the Eagle S case, where Finnish prosecutors charged the captain and two crew over the December 2024 Estlink-2 incident, was dismissed by a Helsinki court in October 2025 on jurisdictional grounds: the court found it lacked authority to prosecute acts by a foreign-flagged vessel in international waters. Finland was left paying the defendants’ legal expenses.
UNCLOS Articles 113 to 115 make cable disruption a punishable offence if done “wilfully or through culpable negligence,” but the convention does not specify penalties, and flag-state jurisdiction protections create the enforcement gap that hybrid warfare works through. The UN General Assembly Resolution 78/69 from December 2023 recognised the problem but carries no binding force.
Then there is the resilience dilemma: measures that make infrastructure more resilient, route bifurcation, rapid repair, redundancy, can paradoxically make sabotage harder to prosecute because they reduce the observable disruption. If a cut cable causes no consumer-visible outage, the political will to pursue a prosecution that requires 19 months and faces jurisdictional hurdles may simply evaporate. The law governing peacetime navigation was not designed to deter state-directed sabotage conducted through deniable commercial proxies.
If neither deterrence nor law reliably stops the attacks, the next question is architectural: do you harden the cables or keep them open? This is a central strategic question in undersea cable governance, because the answer determines whether cables remain global commons or become Balkanised national-security assets. The economic stakes of getting it wrong reach billions per day in disruption costs.
The securitisation argument is that threats require hardening: route bifurcation to avoid chokepoints like the Danish Straits and the Gulf of Finland, sovereign cable ownership, trusted-vendor requirements, cable route secrecy, and exclusion of adversarial states from cable consortia. Google and Meta’s Echo and Apricot cable systems were explicitly designed to avoid landfall in China and routing through the South China Sea. The Quad Partnership for Cable Connectivity and Japan’s economic security agenda both reflect this logic.
The cooperative interconnection argument points out that cables have historically functioned because they are neutral, commercial, and universally accessible. The International Cable Protection Committee articulates best practices but has no enforcement authority. UNCLOS provides the multilateral governance framework. Open consortia and shared ownership created the dense redundancy that makes the system resilient.
The concept of weaponised interdependence, developed by Henry Farrell and Abraham Newman, explains the dilemma: the networks that create global economic interdependence can be exploited by states controlling critical nodes. But disconnection may create greater vulnerability than interconnection. As one analysis puts it, “fragmentation will not only create new vulnerabilities but also undermine the resilience that has made cables largely secure in the first place.”
Then there is the hyperscaler dimension. Google, Meta, Microsoft, and Amazon now control roughly 90% of transatlantic cable capacity, up from 10% in 2014. Traditional European operators represent about 2% of total transatlantic capacity. This private concentration introduces a sovereignty concern that securitisation logic amplifies. If the cables are privately owned, and the owners are American tech companies, who decides whether a route is secure?
The route-diversification criteria are practical: geographic chokepoint avoidance, landing-station diversity, coastal-state risk profiles, and repair-fleet access. But the strategic choice underneath them, security through fragmentation or resilience through interconnection, remains unresolved.
No single technology wins across all threat models. The architecture that works is layered, and the real question — explored across the technology enabling seabed awareness — is what mix delivers the best detection-to-intervention chain for the budget you have to spend.
Distributed Acoustic Sensing turns existing fibre-optic cables into continuous acoustic sensors. In the Baltic context, Finnish telecom Elisa successfully tested DAS in the Gulf of Finland, detecting exceptional seabed vibrations and building an automated alerting service. A 100-kilometre cable effectively becomes 10,000 virtual sensors, polling at least 1,000 times per second. The marginal cost is low because you are using fibre you already own. The limitation is coverage: DAS only senses near the cable, not the seabed between routes.
UUVs provide mobile investigation and the possibility of interdiction. Task Force X tests them from the NATO Research Vessel Alliance. In July 2025, the Alliance detected the acoustic signature of a ship’s anchor hitting the seabed, with data fused through Mainsail. But UUVs have high capital costs and endurance measured in hours to days. They cannot provide the persistent coverage that cables need.
Satellite tracking combines AIS, synthetic aperture radar, and optical imagery for wide-area coverage at moderate cost. Nordic Warden and Mainsail AI fuse satellite data with other sources to flag suspicious vessel behaviour. The problem: AIS can be spoofed or deliberately disabled, and satellite revisit times are measured in hours, not minutes. Satellites can identify vessel behaviour but cannot confirm seabed activity.
If you are allocating a cable-protection budget across these three technologies, four criteria matter, but they are not equally weighted. For the Baltic, with its shallow waters and dense shipping traffic, detection-to-intervention latency and false-positive rate matter more than cost-per-kilometre or scalability. A false positive that sends a frigate chasing a fishing trawler costs real money and erodes political support for the mission. For Indo-Pacific coverage, the ranking flips: scalability and cost-per-kilometre dominate because the area is an order of magnitude larger and the cable routes are fewer and more concentrated.
The threat model determines which technology you prioritise: DAS excels against anchor-drag attacks with their distinctive acoustic signature at known cable locations. Satellite tracking excels against dark ships loitering in cable corridors. UUVs are the only option for investigating what the other layers detect. Routinely putting frigates and destroyers on cable patrol is not sustainable. The layered architecture you want has satellite tracking providing wide-area cuing, DAS providing persistent cable-proximate confirmation, and UUVs handling mobile investigation. Your budget question is what ratio of each layer.
Baltic Sentry demonstrates that undersea cable protection sits at the intersection of institutional, doctrinal, architectural, and technological choices where no single framework prevails. The institutional landscape is fragmented and coordination untested. Neither military deterrence nor legal accountability has a convincing evidence base. The securitisation-versus-interconnection debate has structural stakes for the global internet itself. And the surveillance technology mix is not just an engineering decision: it reflects deeper disagreements about what the internet’s physical backbone should be.
The open question is the one every framework described here was built to handle, and none is ready for: what happens when a sabotage incident is clearly attributable to a state actor but falls below the Article 5 threshold, and the legal framework has no jurisdiction to prosecute? Each path involves trade-offs that cascade through the system, a dynamic we trace across the broader strategic landscape of undersea infrastructure protection. The value lies in understanding what is lost with each choice.
No state has claimed responsibility, and formal attribution remains elusive. Western intelligence agencies point to Russia as the most likely actor, citing the pattern of incidents coinciding with broader hybrid warfare campaigns, the involvement of vessels from Russia’s shadow fleet, and the strategic logic of testing NATO’s response to grey-zone provocations. However, maritime evidence in international waters is fragmentary, and the legal standards for state responsibility are difficult to meet without a smoking gun.
Typically two to four weeks from the moment a fault is detected. The bottleneck is rarely the repair itself but the availability of specialist cable repair vessels, of which fewer than 60 operate worldwide. After a remotely operated vehicle locates the break, the vessel must lift the cable, splice in a replacement section, and lower it back to the seabed, all while contending with Baltic Sea weather that can delay operations by days.
Burial is standard practice in shallow waters, up to roughly 1,500 metres, to protect cables from fishing trawlers and anchors, but it does not prevent sabotage. A determined ship dragging an anchor across a known cable corridor can still snag and sever a buried cable. In deeper water, burial is technically infeasible. The Baltic Sea’s average depth of 55 metres means most cables remain within reach of surface-deployed equipment, burial or not.
NATO does not publish a consolidated Baltic Sentry budget because the operation draws on member-state-contributed assets rather than a dedicated funding line. Each contributing nation bears the cost of its own frigates, aircraft, and uncrewed systems. Operating a single frigate costs several hundred thousand euros per patrol day. The EU’s parallel Cable Security Action Plan has allocated approximately €1 billion for undersea infrastructure resilience through 2027, split between member-state contributions and Connecting Europe Facility funds.
Article 5 has been formally discussed but never invoked for undersea cable sabotage. The legal threshold for an “armed attack” is deliberately high, and grey-zone operations like cable cutting are designed to fall below it. NATO allies have instead opted for calibrated responses: enhanced surveillance through Baltic Sentry, diplomatic démarches, and sanctions against shadow fleet operators. Invoking Article 5 would require consensus among all 32 allies and a level of attribution that no incident has yet achieved.
A shadow fleet is a network of commercially registered vessels operating with opaque ownership structures, often carrying sanctioned cargo or performing tasks for states seeking plausible deniability. In the Baltic context, these vessels are typically older tankers with unclear insurance and flag-state arrangements. Their ambiguous status frustrates both interdiction and prosecution, because it is unclear whether they are commercial or military, and which state has jurisdiction over a ship flagged in one country, owned through shell companies in another, and crewed by nationals of a third.
The EU’s NIS2 and CER Directives, both in effect from late 2024, now require critical infrastructure operators including cable companies to report security incidents and maintain risk-management frameworks. Outside the EU, however, reporting obligations remain patchwork. The UNCLOS framework, which governs most international cable corridors, imposes no mandatory reporting requirement for damage, and many operators historically preferred to handle incidents quietly to avoid alarming commercial clients or triggering insurance complications.
A single cable cut rarely causes consumer-visible disruption because traffic reroutes automatically through redundant paths. A coordinated multi-cable attack, however, could saturate remaining capacity and degrade service across Northern Europe, manifesting as slower speeds, increased latency, and dropped connections rather than total blackout. Financial markets would feel the impact most acutely: settlement systems and trading platforms rely on the lowest-latency routes, and rerouting through longer paths adds milliseconds that matter for automated trading.
Under Baltic Sentry, NATO’s Mainsail AI platform ingests commercial AIS data, satellite imagery, and operator-reported anomalies into a common operating picture accessible to both naval commanders and participating cable operators. The practical breakthrough was cutting the detection-to-response window from 17 hours to approximately one hour, achieved not by new surveillance capability but by eliminating the institutional delay between a cable operator noticing something unusual and a naval asset being in position to investigate.
Yes, and the stakes are arguably higher. The Indo-Pacific carries a larger share of global data traffic with fewer redundant routes and more geographic chokepoints, including the Strait of Malacca, the Luzon Strait, and the South China Sea. China’s extensive survey vessel activity near cable corridors, combined with its control over key landing stations, has prompted Japan, Australia, and Quad partners to accelerate cable protection efforts, though no Indo-Pacific equivalent of Baltic Sentry yet exists at comparable scale.
Not yet, and this is one of the hardest problems in cable surveillance. Anchor drags from a fishing vessel that has lost power produce nearly identical acoustic signatures to anchor drags from a vessel deliberately loitering over a cable corridor. AI systems like Nordic Warden and Mainsail AI can flag suspicious patterns, such as AIS transponders switched off near cable routes or vessels deviating from commercial shipping lanes, but the final determination of intent still requires human assessment of context, vessel history, ownership, and geopolitical circumstances.
How Distributed Acoustic Sensing and Seabed Surveillance Protect Undersea Cables from SabotageIn June 2026, Finnish telecom operator Elisa connected a DAS interrogator unit to a dark fibre strand in one of its Baltic Sea cables and switched it on. Suddenly a cable laid for moving data became a sensor array capable of hearing every vessel approaching it. The deployment, using hardware from AP Sensing and tested with the Finnish Border Guard and Navy, was the first publicly acknowledged operational DAS system for real-time cable protection. The system surrounding it, however, is layered, and each layer has a breaking point — a reality that makes this one dimension of the broader undersea cable protection challenge.
The principle is phase-sensitive optical time domain reflectometry, or ϕ-OTDR. An interrogator at a landing station injects coherent laser pulses into a dark fibre, those unused strands manufacturers include as spare capacity. Because DAS uses dark fibre rather than active strands, it does not affect the internet traffic flowing through the same cable.
The pulses hit microscopic density fluctuations frozen into the glass during manufacturing, producing Rayleigh backscatter that returns to the interrogator. When acoustic energy from the water column, a ship’s propeller, an anchor dragging, strikes the fibre, it creates strain via the photo-elastic effect. The interrogator analyses phase changes between sections of backscatter separated by a gauge length, the spatial interval over which it compares readings, yielding dynamic strain measurements with metre-scale resolution along tens of kilometres of cable.
In practice, a 100 km cable becomes 10,000 virtual sensors, each 10 metres long, polling over a thousand times a second. Interrogator units need installing roughly every 100 km, making the system scalable across long-haul routes.
“Our goal is to use the early warning system to alert the authorities even before the first damage occurs,” said Jouni Petrow, Elisa’s New Business Director.
The historical thread matters. SOSUS, the Cold War US Navy hydrophone network, pioneered persistent seabed monitoring. DAS achieves comparable coverage using existing commercial infrastructure, without the cost and friction of deploying military sensors. But the capabilities that make DAS effective against surface vessels also define what it cannot yet do: detect submarines.
DAS is good at detecting surface vessels. Submarines are a different question.
The physics works against you. Acoustic energy from a submerged source must travel through the water column, couple into seabed sediment, and induce enough fibre strain to register above the noise floor. Surface vessels benefit from the Lloyd’s mirror effect, interference between direct and surface-reflected acoustic paths creating distinctive frequency notches. Submerged sources lack that component. Their signatures are weaker and harder to characterise.
Nobody has published quantitative data on DAS sensitivity to submarines or UUVs near cables. The INESC TEC ϕ-OTDR studies, the Hartree Centre work with Indeximate, the Nature Scientific Reports cable monitoring paper, all of it focuses on surface vessels. For the operator asking whether DAS will alert them to a submarine, the honest answer is: not reliably, and not yet.
This matters because Russian submarine activity near cables in the Irish Sea and Norwegian Sea is documented, and China has tested deep-water cable-cutting devices.
Detection without identification gets you a notification that something is near your cable. Is it a fishing trawler or a hostile actor? You do not know.
Seabed-to-space situational awareness, S3A, is the architecture designed to answer that question. NATO formalised the concept under its 2023 Digital Ocean Initiative. It has four layers.
The seabed layer is DAS, persistent acoustic detection. The surface layer is AIS vessel tracking and coastal radar. AIS broadcasts identity and position for most commercial ships, but it can be switched off, creating dark vessels. The space layer adds SAR and optical satellite imagery, wide-area and non-cooperative, but intermittent: orbital passes are periodic and optical sensors are weather-dependent. The subsurface mobile layer, UUVs and crewed submersibles, provides close inspection but cannot cover wide areas persistently.
No single layer is sufficient. DAS detects but cannot name. AIS names but can be deactivated. Satellites see everything but not continuously. UUVs inspect closely but slowly.
The fusion layer is the unsolved problem. NATO’s Mainsail system, developed at the Centre for Maritime Research and Experimentation in La Spezia, uses AI to track over 100,000 vessels daily and flag anomalous behaviour — part of how NATO and the EU are deploying these technologies operationally.
There is also the data volume problem, which is separate from fusion. A single DAS interrogator produces terabytes of raw strain data daily. Without machine-learning filtering, operators drown in data while missing the signal. Fusion asks how to correlate multiple streams into one picture. The data volume problem asks how to make a single stream manageable. Both need solving before S3A becomes operational reality.
So DAS detects and S3A identifies. What happens when something still gets through?
Routing redundancy is the internet’s built-in answer. Instead of a single cable between two points, operators build physically separated routes. When one cable is cut, BGP and software-defined networking reroute your traffic automatically, typically before you notice. Users in well-connected regions rarely feel a single failure. The system was built for accidents, and it handles them well.
The limits are structural. Cost is the obvious one: each route costs hundreds of millions, and for nations served by a single cable, a second cannot be justified commercially.
Geography is harder. Narrow corridors like the Gulf of Finland, Bab el-Mandeb, and the Luzon Strait force multiple cables through the same physical space because there is no alternative. If you operate in a chokepoint region, redundancy is physically impossible, all paths share the same corridor.
Landing station convergence may be more vulnerable. Separate submarine routes can terminate at the same building. A fire or physical attack there defeats the redundancy of the submarine segments.
Then there is the ownership dimension. Hyperscalers, Google, Meta, Microsoft, Amazon, now control more than half of intercontinental cable capacity and accounted for approximately 90% of new investment by 2024. They build redundancy because it protects their services. But their routing is commercially optimised for their own traffic, not for national resilience. The two objectives overlap but are not identical, and the gap is a strategic vulnerability that governments are only beginning to recognise — at the centre of the strategic debate over infrastructure resilience.
When detection, identification, and redundancy all fail, you are left with repair. And repair has a bottleneck.
The sequence is straightforward. Here is how it plays out:
The bottleneck is the fleet. Between 60 and 75 cable repair ships serve the entire globe, most built in the 1990s to 2000s, none government-owned. They are commercially scheduled. If multiple cables are severed simultaneously, a coordinated attack could leave regions offline for months.
A fibre optic repair runs roughly AU$1.5 to 3 million, borne by the cable owner and typically insured. The EU has launched a cable security action plan with funding for rapid repair capability. Japan is subsidising new vessels for NEC. But the structural question remains: should governments invest in sovereign repair fleets? The case for it is surge capacity during a crisis. The case against is that the commercial model has functioned for decades, and a government fleet sitting idle between crises is expensive. What is changing is the perceived likelihood of the crisis that would require it. That crisis scenario is what brings us back to the architecture.
The protective architecture around undersea cables is real. DAS turns passive infrastructure into active sensors. S3A promises to fuse sensor streams into awareness. Routing redundancy absorbs single failures. The repair fleet restores what breaks.
But each layer has a structural limit an informed adversary can map. DAS cannot reliably detect submarines. Sensor fusion remains an unsolved integration problem. Redundancy fails at chokepoints and landing stations. The repair fleet is stretched, commercial, and cannot surge.
The Finnish DAS deployment is progress, but it protects against surface vessels in one sea, not submarines, not chokepoint sabotage, not coordinated multi-cable attacks. The gap between what each layer can do and what a determined adversary would demand of it: that is the story. The cable protection problem is a systems problem. Each layer works; each layer has a seam. The question is whether the seams are found and closed before an adversary finds them first.
No. DAS uses dark fibre, which are unused strands already inside the cable that were included during manufacturing as spare capacity. The laser pulses travel through these dormant fibres while the active strands continue carrying data uninterrupted. The DAS interrogator connects only at the landing station, and the sensing process does not physically alter the cable in any way. Regular internet traffic is completely unaffected.
For a single cable cut, most users never notice an outage at all. Traffic reroutes automatically via alternate cable paths within seconds through BGP and software-defined networking. The problem emerges when multiple cables are severed simultaneously, or when a cable serves a region with no redundancy. In those cases, the impact ranges from noticeably slower speeds to a complete blackout that persists until repair, which can take weeks.
No. Satellite constellations provide valuable last-mile and emergency connectivity, but they cannot replace the bandwidth of undersea cables. A single modern fibre pair carries terabits per second; the entire Starlink constellation combined cannot match one transatlantic cable. Satellites complement cables, and they provide resilience for isolated communities, but intercontinental data volume grows faster than satellite capacity ever will. Cables remain the backbone of the global internet.
Cable faults are surprisingly routine. The submarine cable industry averages 100 to 200 faults per year globally, though the overwhelming majority are caused by fishing trawls and ship anchors rather than sabotage. Most of these go unnoticed by the public because redundancy absorbs the impact. What has changed since 2023 is not the frequency of damage but the nature of it: the Baltic Sea has seen a cluster of deliberate, targeted cuts rather than accidental breaks, which is historically unprecedented.
DAS is a detection system, not a prevention system. It can identify a vessel behaving suspiciously near a cable and alert authorities in real time, potentially enabling an intercept before damage occurs. But DAS cannot physically stop an anchor from dragging or a submersible from cutting. Prevention requires the operational response layer: patrol vessels, naval presence, and the political will to intercept a suspect vessel, which DAS enables but does not itself provide.
Cable burial is limited by water depth and seabed geology. Remotely operated ploughs can bury cables to about one to three metres below the seabed, but this is only feasible in depths shallower than approximately 1,500 metres. Beyond that, the equipment cannot operate effectively, and the risk of damage from fishing and anchors also drops sharply. In deep water, cables are simply laid on the seabed where natural sedimentation gradually covers them over time.
The cable owner or consortium bears the cost. For a commercial operator like Elisa, the business case is straightforward: preventing a single cable cut that would require weeks of repair and cost millions in restoration, plus reputational damage and regulatory scrutiny, justifies the investment in DAS interrogator hardware. For consortium-owned cables, costs are shared. Governments have also begun subsidising DAS deployment on cables deemed critical national infrastructure, particularly in the Baltic Sea region.
It depends on context and attribution. Deliberately severing a civilian telecommunications cable during peacetime is a violation of the United Nations Convention on the Law of the Sea, specifically the cable protection provisions, but it is not automatically an act of war. The threshold rises to an armed attack under Article 51 of the UN Charter if the damage is severe, systematic, and attributable to a state actor. The grey zone is exactly where cable sabotage operates: below the threshold of armed conflict but above ordinary criminality.
You wait. The global fleet of approximately 20 cable repair ships is commercially scheduled and cannot surge beyond its physical capacity. If three cables are cut simultaneously in different oceans, at least one fault site will sit unattended for days or weeks until a ship completes another job and transits to the new site. This is not a hypothetical scenario: NATO and national defence planners actively war-game coordinated multi-cable attack scenarios precisely because the repair fleet is the single biggest bottleneck in cable resilience.
Yes, dramatically so. The Indo-Pacific region, parts of Africa, and Pacific Island nations often rely on one or two cables for all international connectivity. A single cut can isolate an entire country. By contrast, Western Europe and North America are connected by dozens of cables on diverse routes, making total isolation nearly impossible. Geography compounds the problem: maritime chokepoints like the Luzon Strait and the Strait of Bab el-Mandeb concentrate multiple cables in narrow corridors where redundancy cannot be physically achieved.
Through behavioural analysis rather than a single signature. A fishing vessel trawling legally follows predictable patterns: steady speed, repeated passes over fishing grounds, AIS transponder active. A vessel dragging an anchor across a cable corridor or loitering above a cable with AIS deactivated exhibits anomalous behaviour. Machine-learning models trained on DAS acoustic data, fused with AIS feeds, flag these behavioural deviations for human operators. The system identifies anomalies; a human analyst makes the final threat determination.
Almost never, and this is one of the most significant weaknesses in the cable protection framework. The evidentiary burden for prosecution is extremely high: you must prove beyond reasonable doubt that damage was intentional, identify the specific vessel and crew, establish jurisdiction, and apprehend the perpetrators. In the Baltic Sea incidents since 2023, vessels of interest have been identified, but no prosecutions have succeeded. Attribution is not enforcement, and the gap between knowing and proving is where impunity lives.