devopsy.kinsta.cloud

Author: Venkat Thiruvengadam

The Self-Driving Help Desk: Agentic AI’s Role in the Next DevOps Era
The concept of agentic AI, where intelligent agents perform tasks, not just answer questions, is finally arriving in DevOps and IT. It is an urgent need in the world of DevOps, where teams are increasingly strained by scale, complexity and security demands. The application of AI has added unprecedented velocity to software development that now requires applications to be launched into production at an equitable speed, thus adding further strain on infrastructure teams.

While AI has transformed industries from content creation to autonomous vehicles, most enterprise IT systems still largely rely on static automation scripts and human-run help desks. The agentic help desk model introduces a transformative shift: DevOps engineers and IT administrators are no longer scripting repetitive tasks — now, they can build AI agents that run these workflows in real time enabling an unprecedented level of self-service for end users.

The Challenge With AI in IT Operations

In its current state, AI in IT is largely limited to chatbot-style Q&A interfaces. These tools can provide useful information or even generate snippets of code, but they fall short when it comes to taking action. Critical operational tasks — especially those that involve “write” actions like deploying infrastructure or changing configurations — are typically outside the scope of today’s AI implementations.

This isn’t due to a limitation in language models; it’s a safety concern and also requires a specialized middle layer of orchestration, above the models.

This middle layer — a framework that supports five key components:
1. Context Awareness:
AI must understand the environment in which it operates. For instance, when an engineer asks, “Why is my cart service crashing?”, the AI needs access to metadata like cluster names, deployment status and error logs. Injecting this system context into prompts dramatically improves the relevance and utility of responses.
1. Centralized Tools and APIs:
In large-scale DevOps environments, agents need to invoke APIs for systems like AWS, Kubernetes, or Terraform. Relying on every agent to independently implement these APIs is inefficient. A centralized, standardized set of tools — delivered via a shared Model Context Protocol (MCP) — allows for more scalable and secure automation.
1. Apply Guardrails with Human-in-the-Loop Capabilities:
Autonomy shouldn’t mean loss of control. AI systems should include approval mechanisms, letting engineers review or augment workflows before they are executed, as well as collaborate across teams. Engineers need peer-programming-like experiences that support terminals, pull requests, and inline code suggestions within CI/CD workflows. This is essential for safety and trust, and mirrors how an engineer collaborates with a teammate.
1. Granular Access Control:
Access should inherit user permissions and be enforced through a secure framework. Without this, organizations risk accidental privilege escalation or security breaches. Agents should also operate entirely within the customer’s cloud — no remote control plane — preserving security, data locality, and compliance, with strict RBAC, audit trails and scoped, time-bound credentials.

Why a Help Desk Interface?

The traditional help desk is a familiar construct in IT: Users submit tickets, and human specialists resolve them asynchronously. This system is predictable — but it’s also slow and inefficient in a world where things are moving fast and surrounded by automation.

The agentic help desk reimagines this model. Instead of waiting in a queue, users assign tickets to intelligent agents capable of resolving them in real-time. Administrators design, curate and approve agents to handle specific workflows, and end users simply describe their needs in plain language. Agents can even transfer tickets to one another based on specialization.

This evolution supports a future where support is continuous, real-time, and intelligent — without sacrificing safety or control.

Real-World Use Cases

Agentic workflows are already proving valuable in high-pressure DevOps environments. Common examples include:
- Translating legacy deployment formats (e.g., Docker Compose) into Kubernetes-ready manifests
- Running cloud cost optimization diagnostics and implementing savings suggestions
- Troubleshooting performance issues using observability frameworks like OpenTelemetry
- Onboarding new engineers with personalized, interactive guidance
- Automatically detecting and remediating security policy violations
By operationalizing tasks with AI agents, teams are able to reduce manual tasks, accelerate deployments and free up senior engineers to focus on strategic priorities.

The Road Ahead: From DevOps to Broad IT Support

While the initial focus is on DevOps, the underlying architecture of agentic help desks is broadly applicable across the IT ecosystem. Any function that currently relies on ticket queues — security operations, IT support, compliance audits — can benefit from real-time AI-driven workflows.

The long-term vision is for software vendors and in-house teams to build and publish their own agents, creating a dynamic network of automation. This model is extensible, customizable, and built for a future where scale, speed and compliance are all critical.

As IT systems grow more complex, the reactive help desk model is no longer sustainable. Agentic AI introduces a paradigm shift — one where automation becomes intelligent, collaborative and proactive. The potential for this technology to enhance velocity, reduce burnout and harden security is enormous.

But this future won’t be realized through LLMs alone. It will require a deep rethinking of infrastructure, interfaces and governance — built not just for intelligence, but for impact.
June 30, 2025
Infrastructure-as-Code Pitfalls in Platform Engineering
In the context of cloud operations, the last decade was ruled by DevOps and infrastructure-as-code (IaC). But what is true DevOps? Is it developers running their own operations? Is it operators learning development skills to automate infrastructure provisioning using infrastructure-as-code (IaC) tools like Terraform?

Though DevOps is widely understood to incorporate both of these, software developers are far from fully understanding or operating infrastructure. IaC is purely a DevOps tool. When an organization claims to have automated its infrastructure, they mean automation for the efficiency of the DevOps teams, not automation for developers. Developers are still left waiting on DevOps for days for even small infrastructure changes.

While there were efficiencies gained by the current DevOps model, there is an increasing acknowledgment that we require a better approach to enable developer self-service. This has led to the platform engineering discipline.

The high-level goals of platform engineering are:
- Developer self-service for significant parts of infrastructure updates without DevOps subject matter expertise.
- Built-in security and compliance controls.
Infrastructure-as-Code (IaC) Limitations in Platform Engineering

A DuploCloud survey of 40+ enterprises that have made substantial investments in platform engineering showed that the prevalent approach is for DevOps teams to build a DevOps platform with IaC as a core underlying technology. They create templates for the organization’s use cases and publish them in a CI/CD pipeline or a self-service catalog.

Here are the top reasons why platforms that build on top of IaC are failing these platform engineering goals:
1. IaC templates are rigid and not flexible enough to meet changing developer requirements: It is true that DevOps teams can anticipate cloud infrastructure topologies to some extent and have IaC templates for those with a few customizable parameters. But in a microservices world, there are thousands of other workflows and topologies possible based on changing application needs and security controls. Large data centers and edge infrastructure make this even more complex. A manual approach, relying solely on DevOps personnel to constantly build and update myriad combinations in static scripts simply can’t scale.
2. Scripting tools can’t build life cycle management: In cloud operations, people-triggered changes are only a subset of possible use cases. Many asynchronous operations need to be continuously performed. These range from detection of configurations, from desired state to reverting, or complex configuration scenarios where individual components have to be set up asynchronously and brought together later. It could be as simple as a certain component going down and needing to be restored. IaC is a script that runs when triggered to completion. It has no active life cycle to operate continuously in the background.
3. Inability to build a concept of an environment: In any orchestration system, users have a concept of the environment they want to build. When they log in to the platform and navigate to their environment, they expect to update as well as view the state and aspects of resources in that environment, be it the provisioning status, metrics, logs, faults, audit logs, compliance posture, etc. They may want to perform debugging functions, such as restarting services, SSHinginto a VM or accessing a resource’s cloud console (S3 Console, for example) using access control boundaries within that environment. For example, in Kubernetes, you choose the namespace to be the environment and management software like Rancher on top of K8S to provide these functions. If we must replicate this same concept across a broad infrastructure-level platform, we cannot do it using only IaC. We need something with a scope that spans all cloud operations, like Kubernetes. Terraform is a configuration updating and management software, not an orchestration system.
Many platform teams have tried to work around these problems with point solutions by using a disparate set of jobs for certain aspects of life cycle management, building a thin UI shim on top of cloud accounts for visualization of resources while redirecting to other systems like Datadog for logging, metrics and alerts. But for most of the use cases, the DevOps team is still very much in the operations workflow. This completely defeats the concept of developer self-service as well as continuous compliance goals.

Learning From Other Successful Platforms

Two recent examples of successful cloud platforms are Amazon Web Services (AWS) in the context of infrastructure-as-a-service (IaaS) and Kubernetes for container orchestration. These are distributed system implementations using higher-level programming languages like Java and Go. You can’t build such complex systems using scripts and jobs.

Building a true DevOps orchestration platform requires a systems design approach. It also takes expert systems engineers and many years to build and mature, like it did for K8s and IaaS in the Public Cloud.

Conclusion

Since platform engineering teams need systems design expertise that is likely outside of the scope of the typical DevOps role, we need the software development function to intervene with distributed systems programmers and many years of investment. Most organizations trying to build in-house platforms don’t have or don’t want to make this type of investment, as it may not be their core business. Megascale tech companies like Facebook, Uber, Netflix, etc. will likely build an in-house solution, as they have the talent and scale, but for the masses, it is likely that the solution will be an off-the-shelf product from an ISV.

The industry has solved IaaS with public cloud, container orchestration with Kubernetes and observability with platforms like Datadog. The platform engineering category is heading in the same direction.
May 18, 2023
Self-Service Helps Devs Solve Cloud Security and Compliance
Organizations that need compliance must follow a growing number of security standards—PCI, HIPAA, SOC 2 and GDPR just to name a few. Every new standard gives rise to an exhaustive list of hard-to-implement security controls.

Cloud providers like AWS have tried to help, but there is still a lot left for developers to do to secure their infrastructure. Cloud providers give you the raw materials necessary to remain compliant, but you’ll have to learn how to use them.

It may be easier to envision the scale of the compliance challenge by working through an example. PCI DSS is a typical security standard. When moving to the cloud, you’ll have to figure out how to take your compliant infrastructure and implement it using cloud technologies.

PCI has several requirements regarding network architecture and firewall barriers. For example, specification 1.1.4 calls for a “firewall at each internet connection and between any demilitarized zone (DMZ) and the internal network zone.”

Segmentation is the goal. Your network can’t allow traffic to move freely to wherever it wants. You need to set up rules and carefully guard sensitive areas of the system.

In AWS, we’d suggest implementing this requirement using a mixture of services. Testing, staging and production regions of your application should each be in their own VPC. You’ll also need intelligent use of Security Groups, identity and access management (IAM) and instance profiles. Lock everything down and only open the necessary ports. A web application firewall (WAF) should protect the perimeter.

IaaS services like RDS and Elasticsearch should be isolated via security group. Platform services like Dynamo, S3, SQS and Secrets Manager should be isolated via IAM. Lambda has one leg in the security group and another in IAM.

PCI control 6.1 states that you must have a mechanism in place to identify security vulnerabilities within your compliant systems. How can you accomplish this in AWS?

Automation is your best friend in application security. As the speed of development increases, security must keep up. And while there will always be a place for humans to dig into applications through penetration testing to find tricky vulnerabilities, automation will help you find the low-hanging fruit.

AWS Inspector is an API-based service that will proactively scan and assess your application for vulnerabilities and warn you about them. This is an automatic process once it is set up, but it requires an administrator to choose what to test.

Other tools exist to automate application security, such as Wazuh. As with AWS Inspector, there is effort involved in setting it up, initially. But once you complete the configuration, you’ll have a constant security scan running to find vulnerabilities before they reach production. And should some slip in, the scans will continue to search and find vulnerabilities before attackers exploit them.

PCI Requirement 7 states that you must “restrict access to cardholder data by business need to know.” You’ll need to know who has access to what within your application and when they can access it.

Restricting access in a cloud environment can be challenging because you require administrators to configure the services that your application needs to work. How can you limit access while allowing the admins to do their jobs?

Orchestrating access control will require careful use of AWS Security Groups, IAM and federated tokens. Give your admins a token for access that expires quickly. Whitelist trusted IPs for access only to the areas of your environment that are necessary for the user’s role.

The whitelist of IPs and the security groups will need to be kept up-to-date to make sure no holes open when personnel changes. Keep a tight grip on access control in your cloud environment.

PCI Requirement 10 outlines the need to track and monitor all access to network resources and cardholder data. As your cloud environment grows, you’ll need more help to keep tabs on changes and user activity.

AWS CloudTrail can be used to track user activity and API usage. But you’ll have to make sure that CloudTrail can’t be disabled without your knowledge to hide someone’s illicit activity. AWS IAM and Config services can be used to make sure CloudTrail can’t be disabled and to alert you if it is.

CloudTrail can cover user activity, but what about infrastructure changes? You may need to bring in another tool, such as ELK, to track changes to your infrastructure. You can then marry the data from CloudTrail and ELK into a single SIEM for dashboarding.

From this example and just these few requirements, you can see that the cloud is not a “push-button” solution.

And this is only one example. Remaining compliant with SOC 2, HIPAA, GDPR, NIST and a host of other standards will require the same careful planning and execution.

Planning for Compliance

First, your team must stitch together many different software tools that help with compliance. Second, you must run periodic scans on your infrastructure and security controls after you provision your resources which essentially place Band-Aids on top of the holes you’ve created. Instead, applying controls during the provisioning process places a secure foundation under your developers’ code.

DevOps teams try to maintain control over infrastructure and application deployment processes to avoid any mistakes from developers. Suddenly, developing software in the cloud begins to look the same as developing on-premises—delays, disappointment and frustration.

Three things lead to successful cloud compliance:
1. Careful planning and execution
2. Automation to provision the necessary controls while you build your infrastructure
3. Ongoing maintenance to adapt to changing regulations and standards
You can help developers unlock the power and agility of cloud development while remaining compliant. But you must enable self-service for them as much as possible while maintaining security and compliance. The only way is to give them control of doing things they want while hiding low-level details that can get them in trouble.
May 2, 2022