Scaling DevOps with AI: MCP, AI Agents & Platform Engineering

Engineer Naveed Ahmed outlined an architecture for giving AI agents limited access to production infrastructure, using the Model Context Protocol (MCP) to expose narrowly scoped diagnostic tools rather than a general-purpose production terminal. He proposed a three-tier risk model—read-only, bounded change, and high-risk mutation requiring explicit human approval—with authentication, authorization, rate limits, and auditing enforced by the MCP server and policy decisions enforced outside the language model. Ahmed argued platform engineering should supply approved templates and reusable modules so agents work within standards rather than generating new infrastructure designs per request.

Originally published on Naveed Ahmed's Engineering Blog https://blog.naveedkumbhar.com/scaling-devops-in-the-age-of-ai/ . DevOps teams have been automating infrastructure for years. We have Terraform, Kubernetes, CI/CD pipelines, and dozens of monitoring tools. Yet engineers still spend a surprising amount of time investigating repetitive alerts, reviewing configuration changes, and collecting context during incidents. AI agents may help reduce that workload. But giving an AI agent access to production infrastructure introduces a different problem: how do you make sure it acts safely? I recently explored this question while writing about scaling DevOps in the age of AI. Here are the most important architectural lessons. Traditional automation works well when the steps are known. AI can help with tasks where engineers first need to collect and interpret context. For example, an AI-assisted incident workflow might: That can reduce investigation effort, provided the output is checked against actual system evidence. The important distinction is that proposing a fix and safely executing a fix are separate responsibilities. Model Context Protocol MCP provides a standardized way for AI applications to work with external tools. For DevOps teams, that might mean exposing narrowly scoped diagnostic operations instead of a general-purpose production terminal. Examples include: get pod events namespace, pod get deployment history namespace, deployment query prometheus metric, time range get recent application errors service However, MCP doesn't automatically enforce security. The server implementing these tools must apply authentication, authorization, parameter validation, rate limits, and auditing. A read-only Kubernetes service account is a better starting point than cluster-admin credentials. Not every infrastructure action carries the same risk. I prefer separating automation into three levels. | Level | Example | Control | |---|---|---| | Read-only | Fetch Pod logs and metrics | Authenticated automation | | Bounded change | Adjust replicas within approved limits | Deterministic policy and recovery checks | | High-risk mutation | Delete data or alter IAM permissions | Explicit human approval | These controls must be enforced outside the language model. You can use tools such as Open Policy Agent to evaluate structured requests, but a policy decision must still be enforced by the execution service. Even a Pod restart can cause problems, so production change automation needs workload-aware safeguards. Imagine an application starts returning 5xx errors immediately after deployment. A diagnostic agent could gather: kubectl get pods -n production kubectl describe deployment api -n production kubectl rollout history deployment/api -n production kubectl get events -n production --sort-by=.lastTimestamp It could then correlate that information with application logs, traces, and recent code changes. The result might be a concise incident briefing containing: That's useful even if the agent never executes a production mutation. AI-generated infrastructure is only as useful as the standards around it. Without reusable patterns, different services can end up with inconsistent security settings, readiness probes, resource limits, and monitoring. An internal developer platform can provide approved templates, reusable modules, and controlled self-service workflows. AI agents can work within those boundaries instead of generating a completely new infrastructure design for every request. This is where platform engineering becomes important: it creates reliable building blocks for engineers and automation alike. My full article covers: Read Scaling DevOps in the Age of AI: Full Architecture Guide https://blog.naveedkumbhar.com/scaling-devops-in-the-age-of-ai/ AI may change how DevOps work gets done, but it doesn't remove the need for engineering judgment. The opportunity is to automate repetitive investigation, create reliable self-service systems, and reserve human attention for decisions that truly need it. Would you allow AI to execute production changes, or keep it restricted to diagnosis and recommendations? Written by Naveed Ahmed — Lead DevOps & Platform Architect