An enterprise can give an AI agent permission to act without giving its supplier ownership of the rules. Keeping those two decisions separate is the strategic problem beneath the push for enterprise agent infrastructure.
Postman’s account of Agent Mode on Amazon Bedrock, Microsoft’s agent-management updates and AWS’s operational guidance point toward the same boundary: the machinery that determines what an agent can access, when it can act and who remains responsible. Call that machinery the agent control plane. It is where a model’s proposed action becomes an authorized business action—or is stopped.
These developments support a narrower, more consequential argument than the claim that operational reliability has displaced model capability. Vendors are building governance into the environments where agents work. That can make deployment more manageable, while creating a potential dependency on the platform that implements those controls. The evidence establishes the controls and the architectural choices; it does not establish that one vendor has won, that adoption has accelerated or that customers are already locked in.
The permission boundary is becoming part of the product
In an AWS-published account coauthored by engineers from Postman and AWS, Postman describes an agent that operates directly against its application. Agent Mode requires user approval before actions that modify application state. Postman also limits available tools to the task, selects context for that task and applies model-dependent data-retention settings.
The distinction matters. Restricting the tools available to an agent and requiring approval before it changes application state are different controls. One narrows what the agent can attempt; the other places a human decision at the point where its action changes something. Neither removes the need for production testing and monitoring, a qualification the account explicitly preserves.
Postman also says enterprise administrators can enable Amazon Bedrock Guardrails to redact personally identifiable information before it reaches the underlying large language model. That is an available administrative setting, not evidence that every deployment has enabled it.
This architecture distributes control. AWS supplies managed access to foundation models. Postman defines the agent’s interaction with its application and its approval requirements. Administrators have a documented privacy setting, and users retain approval over state-changing actions. Asking who controls the agent therefore requires more than identifying the model provider: different participants control different boundaries.
It also clarifies the limit of the case study. A vendor-authored production account is useful evidence of implementation choices. It is not an independent measurement of reliability gains, adoption outcomes or the comparative effectiveness of competing platforms.
Ownership becomes an administrative function
Microsoft’s Microsoft 365 Copilot release notes describe rules for bulk installation of first-party agents and automatic reassignment of ownerless agents to the appropriate manager. The notes say these actions previously required manual intervention or scripting.
Installing agents across an organization and keeping them attached to an owner belong to the same operating problem. Deployment expands the population of agents; ownership determines who remains accountable for that population. Microsoft presents the rules as a way to support adoption while reducing operational gaps. The documented change is the automation of those administrative workflows; its business impact remains Microsoft’s claim.
The strategic implication is that agent distribution and accountability can become coupled inside a platform. An enterprise adopting its installation rules may also adopt its mechanism for maintaining ownership. That is potentially useful consistency. It is also a reason to ask how much of the organization’s operating model is being expressed through that supplier’s administrative system.
Microsoft makes a related proposition at the infrastructure layer. In its Azure Copilot announcement, it says human and agent actions respect role-based access control and Azure Policy. The announcement introduces six agents—for migration, deployment, optimization, observability, resiliency and troubleshooting—in gated preview. That preview status limits what the announcement establishes about broad availability and production outcomes.
The same announcement says customers can bring their own storage for chat and artifact data. That provision complicates any simple account of vendor control: a managed platform can also offer customers specific ways to retain control over their data. The important question is which boundaries remain under enterprise authority, rather than whether the platform is managed at all.
Operational discipline can deepen platform dependence
AWS’s AgentOps guidance for Amazon Bedrock AgentCore treats memory configuration as a deployable artifact. It recommends versioning memory resources, time-to-live configurations, extraction strategies and namespace structures, then testing memory persistence, extraction quality, namespace isolation and cross-session retrieval before promotion to production.
Memory is therefore an operational responsibility, not merely an agent feature. Its configuration must survive changes, remain consistent across environments and be evaluated before release. AWS also describes a planning process involving a centralized use-case catalog, legal and compliance assessment, domain experts and defined success metrics. Its own guidance makes clear that a managed service does not eliminate organizational work.
Read alongside Postman’s application controls and Microsoft’s ownership rules, this suggests why infrastructure could become a source of supplier leverage. If an enterprise embeds its approval practices, memory configurations and accountability mechanisms in a platform, changing suppliers may require reconsidering more than the model connection. That is an architectural inference, not a measured switching cost. The supplied evidence provides no migration comparison or quantified lock-in penalty.
The strongest counter-case: controls can preserve flexibility
Governance need not constrain model experimentation. A stable execution boundary could let an enterprise change how an agent reasons while preserving the rules governing what it may do.
That is the approach Itential describes for infrastructure automation. Its proposed architecture separates AI reasoning from deterministic execution and infrastructure instrumentation. Agents generate plans but do not act directly on infrastructure; proposed actions pass through schema validation, role-based access control, policy enforcement and approval workflows in Itential’s execution layer. The company says the orchestration control plane remains constant as AI capabilities advance.
This is a credible architectural counterargument to the idea that operational controls necessarily stifle innovation. Separating reasoning from execution could preserve policy boundaries while allowing changes to the reasoning system. Itential’s description remains a vendor proposition, however, rather than independent proof of portability. Independence from a model supplier would not, by itself, establish independence from the orchestration supplier.
There is another limit to equating control with trust. BCG cautions that agents can cause harm even while following instructions and staying within permissions. It argues that organizations must govern purpose as well as conduct. An action passing an approval or access check does not establish that the underlying goal is appropriate.
The practical signal to watch is whether enterprises can change their reasoning systems while preserving—and continuing to test—their execution rules, ownership assignments and data boundaries. The documented controls make those questions concrete. Their value will depend on whether they give enterprises durable authority over agents, or make that authority increasingly dependent on a particular supplier’s machinery.
