By Alok Singh, Lead Architect, Thales
For the last two years, most conversations about AI in software engineering have centered on coding assistants—agents that write code faster, review pull requests, or explain stack traces. That conversation is now beginning to shift, and platform teams are likely to feel the impact first.
The more important question is no longer, “Can an AI agent write my code?” It is, “Can an AI agent safely act on my infrastructure?”
As organisations move from AI-assisted development toward AI-assisted operations, agents are increasingly expected to interact with APIs, deployment pipelines, cloud platforms, ticketing systems, observability tools, and business applications. The challenge is no longer generating responses; it is enabling AI systems to interact with enterprise environments safely, consistently, and at scale.
The Model Context Protocol (MCP) is the piece quietly making that transition possible.
What MCP Actually Solves
Strip away the hype, and MCP is solving a problem that anyone who has tried to connect an AI agent to real-world infrastructure will immediately recognise.
Every tool, API, and data source an agent needs to access comes with its own authentication model, schema, conventions, and operational quirks. Multiply that across dozens or hundreds of internal systems, and organisations quickly find themselves facing a familiar integration challenge—the same N×M problem that API gateways were created to address.
The difference is that the consumer is no longer a browser, a mobile application, or another service. The consumer is an AI agent.
MCP standardises that boundary. Instead of building custom integrations for every tool, MCP provides a common method for agents to discover available resources, understand capabilities, and invoke actions through a consistent interface.
That may sound like a technical convenience, but its impact is much larger.
Without a standard protocol, every team builds its own agent integrations, resulting in fragmented security models, duplicated effort, inconsistent governance, and difficult operational management. With MCP, organisations gain a reusable integration framework that transforms AI capabilities from isolated experiments into a shared platform capability.
In many ways, MCP represents for AI agents what APIs represented for application integration: a common language that enables scalable interaction across heterogeneous systems.
Why This Belongs at the Gateway, Not Scattered Across Services
Having spent years working on platform foundations—identity, API gateways, access management, and secrets management—the pattern is familiar.
The technologies change, but the architectural principle remains remarkably consistent.
Anything that must be enforced universally—authentication, authorisation, rate limiting, auditing, governance, and policy enforcement—belongs at the boundary. It should not be repeatedly implemented inside every application, every service, or every integration.
That same principle applies to MCP.
Treating MCP integration as a gateway-layer responsibility rather than something individual teams bolt onto their services independently creates immediate advantages.
First, it centralises security controls.
Second, it ensures consistent policy enforcement.
Third, it prevents every product team from reinventing the same integration patterns.
Most importantly, it allows organisations to apply the same governance model they already trust for human and machine traffic to a new class of consumer: AI agents.
An AI agent invoking tools through MCP should be subject to the same controls as any authenticated caller:
- Identity verification
- Authorisation scopes
- Rate limits
- Audit logging
- Policy enforcement
- Access reviews
Arguably, agent traffic deserves greater scrutiny.
Unlike humans, agents can operate continuously, execute actions at machine speed, consume information from multiple systems simultaneously, and chain actions together in ways that would be impractical for a human operator.
If organisations have spent years hardening their API and identity infrastructure, it makes little sense to bypass those controls simply because the caller is an AI model.
Identity Matters More Than Ever
As MCP adoption grows, identity becomes one of the most critical architectural considerations.
Many early demonstrations of AI agents focus on capabilities—what tools an agent can access and what tasks it can automate. The more important question is under whose authority those actions are executed.
An agent should never operate as an anonymous super-user.
Instead, organisations need clear identity models that answer questions such as:
- Is the agent acting on behalf of a user?
- Is it acting as a service account?
- What permissions has it been granted?
- What systems is it allowed to access?
- How can its actions be audited?
Fortunately, the industry already has mature mechanisms for solving these problems.
OIDC and OAuth 2.1-based frameworks provide well-understood patterns for delegated authorisation, workload identities, token management, and scope-based access control. Rather than inventing a new security model for agents, organisations should extend these proven identity foundations—the same ones already enforced at the API gateway layer for human and service-to-service traffic—into the MCP ecosystem.
The goal should be straightforward: an AI agent must be as identifiable, governable, and auditable as any human user or machine workload operating within the enterprise.
The Part Everyone Underestimates: What an Agent Is Actually Allowed to Do
The most difficult challenge in this space is not the protocol.
MCP is increasingly well-defined, and the mechanics of connecting agents to tools are becoming standardised.
The harder problem is determining what an agent should actually be allowed to do.
An MCP-enabled agent operating behind an enterprise gateway is effectively a new category of API consumer. Yet many organisations still do not have a mature definition of what least privilege means for a caller capable of orchestrating multiple actions across multiple systems.
Consider a simple example.
An agent may have access to:
- A Kubernetes management tool
- A deployment pipeline
- An incident management platform
- A ticketing system
- Monitoring and observability tools
Individually, each capability appears harmless and appropriately scoped.
However, when combined, the agent can potentially diagnose an issue, create a change request, trigger a deployment, modify infrastructure, and update operational records—all without direct human involvement.
The risk is not necessarily any single action. The risk lies in the chain of actions.
To an AI agent, a read-only operation and a production-altering operation are simply available capabilities. Unless the platform explicitly distinguishes between them and enforces those distinctions, the agent cannot be relied upon to make governance decisions on its own.
That responsibility belongs to the platform.
This is where existing platform engineering practices provide a significant advantage. Organisations already understand concepts such as:
- Least privilege
- Separation of duties
- Change control
- Auditability
- Policy enforcement
- Operational blast radius
The challenge is extending those principles from APIs and services to AI-driven workflows.
A Practical MCP Scenario
Imagine an on-call engineer investigating a production issue.
Instead of manually switching between monitoring dashboards, Kubernetes consoles, deployment tools, and ticketing systems, the engineer interacts with an AI assistant.
The agent:
- Queries observability platforms for recent alerts.
- Retrieves deployment history from CI/CD systems.
- Examines relevant Kubernetes resources.
- Correlates events across systems.
- Creates an incident ticket.
- Presents recommended remediation actions.
In a more advanced environment, the agent may even execute approved operational tasks. The value is obvious: faster investigations, reduced cognitive load, and improved operational efficiency. The governance challenge is equally obvious.
Should the agent be allowed to restart workloads?
Can it deploy changes?
Can it modify production configurations?
Can it trigger rollbacks?
Answering these questions requires strong identity, authorisation, and policy controls—not just a protocol for connecting tools.
MCP provides the connectivity. Platform architecture provides the governance. Both are necessary.
Where This Goes Next
MCP remains early in its adoption journey, and many best practices are still being developed in public. That is precisely why platform teams should engage now rather than wait for standards and patterns to become entrenched.
For organisations that already operate hardened API gateways, identity platforms, and governance controls, MCP should not be viewed as an entirely new discipline.
It is an evolution of a familiar one.
The same principles that governed service-to-service communication, API security, and enterprise integration now need to be applied to AI agents.
The organisations that recognise this will spend the coming years safely integrating agents into their operational ecosystems while leveraging the investments they have already made in identity, security, and governance.
Those that approach MCP as a collection of isolated connectors and one-off integrations will likely face growing inconsistency, fragmented controls, duplicated effort, and increased operational risk.
Ultimately, MCP is not the story.
The larger story is the emergence of AI agents as first-class consumers of enterprise infrastructure.
MCP simply provides the standardised interface that makes this possible.
The real challenge—and opportunity—for platform teams lies in deciding how these agents are authenticated, authorised, governed, observed, and controlled at scale.
In that sense, MCP may become to AI agents what APIs became to modern software: not the destination itself, but the foundational layer upon which everything else is built.