How AI Control Planes Balance Security, Speed and Flexibility

For years, enterprise technology leaders have wrestled with a familiar dilemma: Embrace the speed and innovation of a vendor platform or invest in building enough internal capability to maintain strategic control. Generative AI has made that trade-off far more consequential. As organizations move beyond chatbots to autonomous agents that retrieve information, invoke tools and make decisions across business systems, the focus is increasingly on who controls the pathways connecting models, knowledge, applications and enterprise data.

That challenge is driving renewed interest in customer-owned AI control planes—enterprise-managed gateways that sit between AI applications and the rapidly expanding ecosystem of models, Model Context Protocol (MCP) servers, agent hubs and knowledge sources. Rather than relying entirely on vendor-specific ecosystems, these architectures promise centralized governance, stronger security, greater architectural flexibility and the ability to adopt new AI capabilities without redesigning the entire technology stack. Yet they also introduce an important question: Does adding another layer simplify enterprise AI or simply shift complexity from vendors to internal engineering teams?

Members of the Senior Executive AI Think Tank, a community of leaders shaping enterprise AI strategy across architecture, governance, cloud computing and digital transformation, largely agree that customer-owned control planes represent an important evolution—but only if organizations approach them with discipline. Below, they discuss why centralized gateways can help organizations reduce vendor lock-in without slowing innovation, what security and architecture teams need to see before they’ll trust agentic AI at scale and why governance should be built into every model and tool interaction rather than bolted on later.

“A customer-owned control plane can reduce lock-in and still keep security and architecture teams comfortable, but only if it really governs how agents talk to systems rather just adding more wiring.”

– Pon Murugesh Devendren, SAP Enterprise AI Architect at Deloitte

SHARE IT

Governance Begins at the Gateway

Pon Murugesh Devendren, SAP Enterprise AI Architect at Deloitte, says organizations should think of the control plane less as another integration layer and more as the enterprise’s single point of governance.

“A customer-owned control plane can reduce lock-in and still keep security and architecture teams comfortable, but only if it really governs how agents talk to systems rather just adding more wiring,” he says.

Rather than allowing every AI application to establish its own connections to enterprise systems, Devendren advocates routing requests through common gateways that consistently enforce authentication, authorization and auditing.

“In that model, every agent request goes through one shared path where identity, permissions and logging are handled the same way every time.”

That centralized approach becomes increasingly valuable as enterprises deploy dozens—or eventually hundreds—of AI agents across departments. According to the National Institute of Standards and Technology’s AI Risk Management Framework, consistent governance and traceability are foundational capabilities for trustworthy AI systems, particularly as organizational complexity increases.

Devendren also argues that governance should extend beyond model access.

“All LLM model calls should flow through a customer AI gateway and all tool calls should go through a customer MCP gateway that can register both customer-owned and vendor MCP servers, so access and observability stay under one governing layer,” he says.

To Devendren, enterprises should own the trust boundary, even if they don’t own every technology behind it.

Security Depends on Knowing When Things Change

For Bhubalan Mani, Lead of Supply Chain Technology and Analytics at GARMIN, routing requests through a gateway is only the beginning.

“The router is the easy part,” he says. “Auth, routing and logging are a quarter’s work.”

The more difficult challenge, he argues, lies in maintaining trust as AI tools evolve.

“The harder problem is tool-surface drift. MCP has no integrity primitive, so an approved server can rewrite its tool descriptions and a one-time review means little.”

Instead of relying on static approvals, Mani recommends continuously validating tool definitions through hashed registries and automated drift detection.

“A control plane earns its keep by hashing the tools or list manifest into a private registry and failing closed on drift.”

The OWASP MCP Security Cheat Sheet similarly recommends runtime validation, tool definition integrity checks, cryptographic pinning of tool schemas and continuous monitoring instead of relying on one-time approval processes.

“That control, not the proxy, is what convinces security. Portability isn’t a routing feature,” he says. 

Organizations often assume changing foundation models will be straightforward if they avoid proprietary APIs. In practice, prompts, latency expectations and tool behavior become deeply optimized around individual models.

“Without an evaluation suite per use case, ‘no lock-in’ is a slide, not a capability.”

His conclusion captures an important distinction for enterprise leaders: “Own the trust boundary and the evals. Rent the rest.”

Treat the Control Plane Like a Product

David Obasiolu, AI Security, Governance and Systems Consultant at Vliso AI, believes many organizations misunderstand what they’re actually building.

“A customer-owned control plane can work, but only if you treat it as a product, not a project.”

That distinction shapes everything from staffing to governance.

“It genuinely helps with lock-in, auditability and giving security teams one place to enforce policy across agents and MCP servers.”

However, Obasiolu warns that many enterprises inadvertently recreate the very rigidity they’re trying to eliminate.

“The risk is building a bespoke bottleneck that lags the ecosystem.”

Instead, he recommends concentrating on three enduring capabilities: open standards, dedicated platform ownership and architectural restraint.

“You standardize on open protocols so swapping models and tools stays cheap, you staff a real platform team to keep pace with fast-moving agent frameworks and you keep the gateway thin.”

In other words, the control plane should focus on routing, authentication, governance and observability while allowing product teams to innovate independently.

“If it becomes a gatekeeper instead of an enabler, you’ve just built new lock-in—to yourself.”

“The goal isn’t to own more technology but to preserve the ability to choose.”

– Andre Shojaie, Founder of HumanLearn

SHARE IT

Preserve Choice, Not Just Ownership

Andre Shojaie, Founder of HumanLearn and an executive leader in AI governance, leadership transformation and digital strategy, believes organizations sometimes focus too much on owning technology and not enough on preserving strategic flexibility.

“I think a customer-owned control plane can reduce lock-in but only if organizations resist the temptation to rebuild every vendor capability themselves,” he says.

For Shojaie, ownership is valuable only when it protects future options rather than creating another proprietary ecosystem.

“The real value isn’t ownership for its own sake. It’s preserving the freedom to replace models, tools and providers without redesigning the entire architecture every time the market shifts.”

Shojaie also warns that organizations can unintentionally replace one dependency with another.

“A control plane can easily become another source of dependency if only a small group understands how it works.”

That creates institutional risk rather than reducing it.

“In that case, the organization has simply replaced vendor lock-in with internal lock-in. The goal isn’t to own more technology but to preserve the ability to choose.”

His point broadens the conversation beyond software architecture to organizational resilience. Sustainable AI governance depends not only on technology decisions but also on building systems that multiple teams can understand, maintain and evolve over time.

Make Governance Invisible to Developers

Divya Parekh, Founder of executive coaching brand DivyaParekh.com, works with executives on AI adoption and leadership performance. She believes the control plane succeeds only when it accelerates execution instead of adding friction.

“A customer-owned control plane can work, but only when you consider it a product, not an additional infrastructure project.”

Its purpose, she explains, is to provide one consistent layer for “identity, permissions, model routing, audit trails, data boundaries, tool approval and agent observability across vendors.”

Like several other Think Tank members, Parekh cautions against trying to duplicate every capability vendors already provide.

“The trap is rebuilding every vendor feature internally. Keep the plane thin, standards-based and focused on policy and visibility. Let vendors compete above it.”

For Parekh, execution depends as much on organizational design as technology.

“For this to succeed, three things matter: a platform team with clear ownership, reusable security patterns that do not slow developers down and measurable exit options so switching providers is real, not theoretical.”

When those conditions exist, she says, governance becomes an accelerator rather than an obstacle.

“Done well, it becomes a speed layer. Done poorly, it becomes a very expensive tollbooth.”

Enterprise Architecture Is a Moving Target

Manpinder Singh Panesar, Senior Solutions Architect at Amazon Web Services (AWS), approaches the debate through the lens of decades of enterprise platform evolution.

“There is no absolute right or wrong here,” he says. “We have seen this cycle across IT for decades.”

Instead of viewing customer-owned control planes and vendor platforms as opposing strategies, Panesar sees them as mutually reinforcing.

“Enterprises with the horsepower to build and evolve their own platforms often influence what vendors productize next.”

He points to the evolution of modern data platforms as evidence.

“Enterprises built many data mesh and lake patterns themselves, while services such as EMR, Glue, Athena and platforms like Snowflake and Databricks evolved around similar industry needs.”

Agentic AI, he believes, will follow the same trajectory.

“The goal is not simply avoiding vendor lock-in; it is preserving architectural optionality while continuously evolving.”

Panesar concludes by reframing competitive advantage.

“Enterprise patterns and vendor platforms are a feedback loop. The real moat is evolving the business with technology faster than the market.”

Rather than asking whether to build or buy, leaders may achieve better outcomes by determining which capabilities differentiate their organizations and which are better consumed as services.

Own the Abstraction Layer

Pradeep Kumar Muthukamatchi, Principal Cloud Architect at Microsoft, believes enterprises should stop treating foundation models as the centerpiece of their AI strategies.

“The most strategic AI decision enterprises can make is not choosing a model—it’s owning the control plane,” he says. “In an agentic world, models, MCP servers, knowledge bases, tools and agents will evolve far faster than enterprise architectures.”

Instead of repeatedly redesigning applications to accommodate new technologies, organizations can isolate those changes behind a stable abstraction layer.

“A customer-owned control plane creates a layer of abstraction that allows organizations to swap components without rewriting the entire system, while giving security, compliance and architecture teams a single point for identity, governance, observability and policy enforcement.”

The approach, however, only works if enterprises resist turning the platform into another custom integration effort.

“The risk is treating it as a custom integration project. The organizations that succeed will standardize interfaces, automate orchestration and govern centrally while remaining vendor-agnostic.”

When implemented thoughtfully, Muthukamatchi says, the control plane becomes more than another technology component.

“Done right, a customer-owned control plane doesn’t add complexity—it becomes the foundation that enables both innovation and control at scale.”

“Every gateway can become another bottleneck if it slows developers or duplicates vendor features.”

– Venkata Kondepati, Manager of Data Architecture and Engineering at Ascentt

SHARE IT

Keep the Trust Boundary Under Enterprise Control

Venkata Kondepati, Manager of Data Architecture and Engineering at Ascentt, believes enterprises benefit most when they think of the control plane as a governance layer rather than another enterprise platform.

“A customer-owned control plane can help enterprises avoid lock-in, but only if it is treated as a thin governance and routing layer, not a new mega-platform,” he says.

For Kondepati, the value lies in creating a consistent operational framework across multiple AI vendors and technologies.

“Its value is giving security, architecture and business teams one place to manage identity, policies, approved tools, model routing, audit logs, knowledge access and agent behavior across vendors.”

Kondepati cautions that governance should never come at the expense of developer productivity.

“The risk is added complexity. Every gateway can become another bottleneck if it slows developers or duplicates vendor features,” he says.

Instead, he advocates for platforms that are standards-based, lightweight and easy to adopt.

“For this approach to succeed, it must be standards-based, lightweight, observable, secure by design and easy for teams to use.”

Ultimately, he says, organizations should focus on defining the boundary of trust rather than owning every technical component.

“The goal is not to own everything. It is to control the trust boundary while keeping vendor flexibility.”

Governance Must Exist at Runtime

Richie Adetimehin, AI Advisory and Transformation Delivery Consultant at Visani America, believes the true value of a customer-owned control plane appears only when governance moves beyond documentation into live operations.

“A customer-owned control plane can reduce lock-in and make agentic AI governable, but only if it becomes the enterprise’s stable layer for identity, policy, observability and tool routing rather than just another bespoke platform.”

That stability, however, comes with additional operational responsibility.

“It also introduces operational responsibility that vendors would absorb.”

Adetimehin outlines five principles that distinguish successful implementations. First, the platform must remain technology-agnostic.

“The control plane must be technology-agnostic and built on open interfaces, so models, MCP servers and tools can be swapped without rewiring the enterprise.”

Second, AI agents should receive their own identities rather than inheriting human credentials.

“Identity must be per-agent, least-privilege and policy-driven, not borrowed from human credentials.”

He also emphasizes continuous governance and operational visibility.

“Policy enforcement must happen at runtime, not in documents or after the fact. Observability must be end-to-end, correlating model and tool calls and user intent across the stack.”

Finally, he says, “the platform team must treat it like a product, with clear ownership, standards and a small number of supported patterns.”

His recommendations illustrate how enterprise AI governance is increasingly becoming an operational discipline rather than simply a compliance exercise.

Make the AI Platform a Strategic Asset

Sabarinath Yada, Business Architect Associate Manager at Accenture, believes organizations should view customer-owned control planes through the same lens as any other mission-critical infrastructure.

“Engineering a customer-owned control plane can help organizations reduce vendor lock-in, meet security and architectural requirements and still maintain development speed.”

The key, he says, is combining strong engineering principles with practical governance.

“This is achievable when supported by strong design principles such as using open standards, applying guardrails at the gateway level and ensuring that governance frameworks enable progress rather than slow it down.”

Yada acknowledges that enterprises must be prepared to take on greater operational responsibility.

“Introducing a control plane does add a layer of operational complexity. Organizations need the right engineering capabilities to build and manage their own gateways and agent hubs.”

Yet he argues that the additional investment pays long-term dividends.

“This complexity is manageable and often justified by the long-term gains in flexibility and agility.”

Ultimately, organizations that succeed treat AI infrastructure as a continuously evolving business capability rather than a collection of isolated technology projects.

“Enterprises must treat their AI platform as core infrastructure—designed, maintained and evolved as a strategic asset, rather than a collection of disconnected initiatives.”

Best Practices for Customer-Owned AI Control Planes

• Create a single governance layer for every AI interaction. Route model and tool requests through common gateways to centralize identity, permissions, logging and observability.
• Continuously validate AI tools instead of trusting one-time approvals. Detect configuration drift and evaluate models regularly so portability remains practical rather than theoretical.
• Treat the control plane like a product. Assign dedicated ownership, maintain open standards and avoid turning governance into a development bottleneck.
• Preserve architectural choice. Build for flexibility so future models, tools and vendors can be adopted without redesigning enterprise systems.
• Keep governance lightweight. Focus the platform on policy, visibility and security while allowing vendors to innovate above the control plane.
• Remember that enterprise platforms and vendor platforms evolve together. Build strategic capabilities internally while taking advantage of mature commercial services where appropriate.
• Own the abstraction layer, not every technology component. Standardized interfaces allow organizations to evolve AI architectures without wholesale rewrites.
• Control the trust boundary. Centralize governance while avoiding unnecessary duplication of vendor functionality.
• Enforce policy at runtime. Identity, authorization and observability should operate continuously rather than relying solely on documentation or reviews.
• Treat AI infrastructure as a strategic business capability. Long-term success depends on investing in platform engineering, governance and continuous evolution.

Control the Foundation, Enable Innovation

Customer-owned AI control planes are not a universal answer to vendor lock-in, nor are they simply another enterprise architecture trend. According to the members of the Senior Executive AI Think Tank, they represent a governance strategy—one that allows organizations to separate policy, security and observability from the rapidly changing ecosystem of models, agents and enterprise AI tools.

Ultimately, the decision to build a customer-owned control plane is less about technology ownership and more about business control. Enterprises must decide which capabilities are strategic enough to manage internally and where external partners can provide value. The companies that strike that balance will be able to move faster with AI while maintaining the security, accountability and flexibility their businesses require.