An enterprise can gain tighter control over its AI agents while becoming more dependent on the platform that supplies those controls. That is the strategic tension in the emerging agentic infrastructure stack: the same systems that constrain an agent’s authority can deepen a cloud provider’s role in how the enterprise operates.
AWS’s enterprise agent platform guidance and Microsoft’s Azure Copilot announcements show infrastructure providers bringing execution, oversight and security into connected operating environments. They support a narrower argument than the claim that cloud giants have already captured agentic AI: operational governance is becoming a potential source of platform dependence. The decisive question is whether enterprises can retain their controls when they change platforms.
Control is becoming part of the infrastructure
The AWS enterprise agent platform sample illustrates how much surrounds the model. Its enterprise architecture uses a management account to orchestrate provisioning through CloudFormation StackSets. Separate development, staging and production accounts run isolated AgentCore stacks containing Runtime, Gateway, Memory and Code Interpreter. CloudWatch OAM aggregates observability across accounts, while a dedicated security account centralizes CloudTrail, SCPs and KMS.
These are distinct responsibilities assembled within an AWS operating environment. The sample is architectural guidance, not evidence of widespread adoption or demonstrated performance. Its significance is the breadth of the proposed relationship: AWS services organize where agents execute, how their operations are observed and where security controls sit.
That arrangement can give an enterprise clearer internal boundaries. Separating workloads and centralizing security are mechanisms for exercising control. Yet internal separation and external independence are different properties. Multiple accounts within one provider do not, by themselves, establish that the operating system can move elsewhere.
The potential dependence follows from the architecture, rather than from a documented restriction on departure. If an enterprise organizes agent execution, memory, monitoring and security around this environment, evaluating an alternative would involve more than choosing another model. The supplied evidence does not measure that migration burden. It does show why model choice alone is an incomplete measure of autonomy.
Governance gives integration its strongest argument
Microsoft describes a similar connection between operational capability and oversight. Its Azure Copilot announcement introduces six agents for migration, deployment, optimization, observability, resiliency and troubleshooting in gated preview. Microsoft says actions respect role-based access control, which determines permissions through assigned roles, and Azure Policy.
In its account of agentic cloud operations, Microsoft also says agent actions are reviewable, traceable and auditable. Bring Your Own Storage keeps conversation history within the customer’s own Azure environment. These are vendor descriptions of functionality and intended benefits, not independent findings that deployments meet every sovereignty or compliance requirement.
Still, they establish the strongest counterargument to the consolidation thesis. An integrated platform can supply mechanisms through which an enterprise sets boundaries and supervises automation. Greater dependence on a provider can coexist with greater control over what an agent is permitted to do. Treating every integration as a loss of sovereignty would miss that distinction.
The storage example makes the boundary precise. Keeping operational history in customer-controlled storage within Azure can strengthen control inside that environment. It does not establish independence from Azure. Whether that arrangement satisfies an enterprise’s requirements depends on which kind of control it needs.
Model flexibility leaves another dependency to examine
Augment Code’s infrastructure guide distinguishes model serving from agent operations: agents use iterative tool calls, maintain state and operate through sessions or tasks. It also argues that routing across model providers through gateways such as LiteLLM or Portkey reduces model-level lock-in.
That is a useful distinction, although the guide is a vendor-authored account rather than an independent comparison. Flexibility at the model layer does not establish portability at the operational layer. Changing the source of a model response and changing the environment responsible for agent memory, permissions and monitoring are different decisions.
Read alongside the AWS architecture, the implication is that model competition and platform dependence can coexist. An enterprise might preserve choice among models while relying on one environment to govern their use. The evidence does not establish that providers are deliberately engineering this outcome, or that it has already concentrated market power. It identifies an architectural route through which dependence could accumulate.
Local infrastructure changes the boundary of control
The counter-case extends beyond better governance within a public cloud. Mirantis describes k0rdent AI as a Kubernetes-native operational platform for private cloud, hybrid infrastructure, bare metal, edge and multi-tenant service-provider environments. Its stated scope includes GPU platform services, workload orchestration, lifecycle management, observability integration and tenant isolation.
This vendor description challenges the idea that the surrounding operational stack must belong to a hyperscaler. It offers a different deployment boundary for the same class of responsibilities. It does not demonstrate equivalent performance, lower cost or effortless portability.
The important consequence is that moving execution closer to an enterprise does not remove the work of governance. Monitoring, isolation and lifecycle management still need an operating home. Local deployment can change who manages that home; it cannot establish that every agent action is appropriately controlled merely by changing where computation occurs.
Accountability remains with the enterprise
The Cloud Security Alliance’s autonomy framework recommends implementing technical controls before granting autonomy and scaling monitoring investment with the autonomy deployed. This makes governance a prerequisite for delegation, rather than an optional addition to a hosting decision.
Palo Alto Networks’ governance guide likewise assigns primary responsibility to the deploying organization: it defines permissions, approves use cases and determines an agent’s authority. The guide calls for named owners of monitoring, intervention and incident response. Those are governance recommendations, not a legal determination, but they expose the organizational responsibility that infrastructure alone cannot settle.
The enterprise therefore has two questions to answer. Can it govern the agents it deploys? And can it preserve that governance if it changes the environment supporting them? The first concerns authority over actions. The second concerns dependence on the mechanisms that make those actions controllable.
The available evidence documents architectures and vendor promises, not the market shares, migration costs or customer outcomes needed to declare a cloud takeover. The concrete signal to watch is whether an enterprise can move an agent workflow while preserving its permissions, operational history and oversight. Demonstrated continuity would strengthen the case that integration expands autonomy. Having to reconstruct those controls would strengthen the case that dependence has shifted from the model to the operating stack.
