Private connectivity is becoming a requirement for agent gateways
- AI
- Cloud Architecture
- Enterprise Integration
What happened: AWS published private connectivity patterns for Amazon Bedrock AgentCore Gateway targets, covering MCP servers, REST APIs, regional API Gateway targets, Lambda functions, on-premises targets, multicloud targets, and multi-VPC or cross-account setups.
Why it matters: Agent tools are no longer just public APIs or local developer helpers. Once agents call internal systems, gateway placement, private routing, VPC boundaries, cross-account access, and audit scope become first-class design decisions.
Enterprise adoption impact: Regulated clients will ask whether agent tool traffic leaves private networks, whether MCP servers are reachable only through approved routes, and whether existing API/private connectivity patterns can be reused.
Watchpoint: Add "agent tool network path" to architecture reviews: source agent, gateway, identity boundary, target type, private route, audit log, failure mode, and owning platform team.
EU cloud and AI sovereignty is moving toward assessable levels
- Cloud Architecture
- Enterprise IT Architecture
- AI Governance
What happened: On 3 June 2026, the European Commission published its Tech Sovereignty Package, including the Cloud and AI Development Act. The proposal introduces a single EU-wide sovereignty framework, public-sector procurement mechanisms, open source support, and a target to at least triple EU data centre capacity within five to seven years.
Why it matters: Sovereignty is becoming less of a slogan and more of an assessment model. The Commission describes four assurance levels for cloud and AI sovereignty, from EU-based processing and storage through to full supply-chain transparency and no third-country interference.
Enterprise adoption impact: Belgian and Flemish clients may start asking suppliers to prove jurisdictional control, software supply-chain transparency, operational control, data and AI controls, and resilience evidence.
Watchpoint: Build a sovereignty checklist that maps each claim to architecture proof: location, legal control, operator control, support access, key management, software supply chain, audit exports, exit path, and AI/data isolation.
Cloud-admin MCP servers need a stronger governance model than local setup notes
- AI
- Automation Platforms
- Cloud Architecture
What happened: Microsoft documents Azure MCP Server as a way for AI agents and clients to interact with Azure resources through MCP, using Entra ID, Azure Identity, Azure CLI or managed identity, and Azure RBAC. It supports developer tools, code editors, and programmatic clients.
Why it matters: This is powerful, but it also turns cloud administration into an agent-accessible surface. The risk is not the MCP server itself. The risk is unmanaged local configurations, over-broad subscriptions, unclear role assignment, missing approval flows, and no audit model for changes suggested or executed through an AI assistant.
Enterprise adoption impact: Platform teams will need standards for where developer MCP usage is allowed, which subscriptions can be touched, how privileged actions are approved, and which logs prove what happened.
Watchpoint: Treat cloud MCP setup like privileged automation: named environments, least-privilege roles, approved tool namespaces, break-glass rules, drift detection, and clear separation between read-only diagnostics and state-changing operations.