AWS DevOps Agent & Security Agent Hit GA: What This Means for Your On-Call Team

On March 31, 2026, AWS moved two of its most ambitious AI services from preview to general availability: DevOps Agent and Security Agent. Both were introduced at re:Invent 2025 as “frontier agents” — autonomous AI systems designed to operate continuously across multiple steps without constant human oversight.

This is not a minor feature launch. These are production-grade agentic systems already running inside T-Mobile, United Airlines, Western Governors University, Zenchef, and Verisk — with verified, customer-reported results. The numbers are hard to dismiss: 77% MTTR reduction at WGU, 75% faster root cause analysis at Zenchef, and up to 3–5x faster resolution across preview customers.

For DevOps teams, this is the most significant agentic AI story in the market right now. Not because it promises to replace anyone — but because it rewrites the economics and speed of incident response in a way that will force every team to reconsider how they operate.

Here is what the GA launch actually includes, what the real-world results look like, what it costs, and — critically — what questions you should ask before handing your incident response to an AI.

What AWS DevOps Agent actually does

DevOps Agent is built on Amazon Bedrock AgentCore and operates as an always-on, autonomous operations assistant. When an incident triggers — via a CloudWatch alarm, PagerDuty alert, Dynatrace problem, ServiceNow ticket, or any webhook-configured event — the agent begins investigating immediately, without human prompting.

This is not a chatbot you ask questions. It is an autonomous investigator that correlates telemetry, code, deployment history, and infrastructure topology to form hypotheses, test them, and surface root causes with recommended remediation steps.

The GA release introduced several capabilities that weren’t available during the preview:

Multi-cloud and hybrid investigation. DevOps Agent now investigates incidents across AWS, Azure, and on-premises environments. The agent uses the Model Context Protocol (MCP) to discover on-premises resources by analysing metrics, logs, and code — building a comprehensive topology across your entire estate without requiring you to replicate everything into a single observability platform.

Broad tool integration. Native connectors for CloudWatch, Datadog, Dynatrace, New Relic, Splunk, Grafana, GitHub, GitLab, Azure DevOps, PagerDuty, ServiceNow, and Slack. The extensibility point here is MCP — the same protocol that’s becoming the industry standard for agent-to-tool communication.

On-demand SRE tasks. Beyond incident response, you can interact with the agent conversationally to query application architecture, analyse system health, and perform ad-hoc operational work using natural language.

Custom agent skills. You can extend the agent’s capabilities with custom skills — essentially teaching it your organisation’s specific runbooks, procedures, and tribal knowledge. This is the feature that moves DevOps Agent from “generic AI assistant” to “something that knows how your systems actually work.”

Historical pattern analysis. The agent learns from past incidents to identify patterns and recommend preventative improvements — shifting the value from reactive resolution to proactive prevention.

What AWS Security Agent does

Security Agent is the second frontier agent in the pair, and it tackles a different but complementary problem: continuous, autonomous penetration testing.

The agent ingests source code, architecture diagrams, and documentation, then identifies vulnerabilities and attempts to exploit them with targeted payloads and attack chains — behaving much like a human penetration tester, but running continuously rather than in quarterly engagement windows.

LG CNS, one of the early adopters, reported over 50% faster testing cycles and approximately 30% lower costs, along with significantly fewer false positives compared to traditional automated scanning tools. HENNGE and Wayspring are also reporting strong results.

The combination is deliberate: DevOps Agent handles what happens after something breaks, while Security Agent tries to find what might break before it does. Together, they represent AWS’s bet that the future of operations and security is agentic — autonomous, continuous, and embedded in the pipeline rather than bolted on.

The customer results: what’s real and what needs scrutiny

Let’s separate the verified from the marketing.

Western Governors University (WGU) was the earliest adopter — deploying DevOps Agent into production even before the preview launch at re:Invent. During a real production service disruption, their SRE team used the agent to reduce resolution time from approximately two hours to 28 minutes — a 77% MTTR improvement. The agent traced the root cause to a Lambda function misconfiguration, surfacing operational knowledge that had been buried in undiscovered internal documentation.

United Airlines operates at enormous scale: 500,000+ daily passengers, 38,000 Dynatrace OneAgents, 500+ AWS accounts, 20,000 Lambda functions. Their previous setup used multiple overlapping tools that created what they described as “gaps and black boxes during troubleshooting.” DevOps Agent integrated with Dynatrace eliminated that fragmentation — issues detected by Dynatrace are automatically investigated by the agent, with findings fed directly back.

T-Mobile was a design partner from day one, providing real-world feedback that directly shaped the product. Their infrastructure spans multiple clouds and on-premises environments, with logs centralised in an on-prem Splunk deployment. The multi-cloud investigation capability was explicitly influenced by T-Mobile’s requirements.

Zenchef provides perhaps the most relatable story. During a company hackathon, a customer-facing API issue emerged. Rather than pulling engineers off the event, the team handed the problem to DevOps Agent. It systematically ruled out authentication as a factor, pivoted to investigating ECS deployments, and traced the root cause to a code regression — in under 30 minutes.

These are credible results from real production environments. But context matters: these are early adopters who were deeply supported by AWS engineering teams during preview. The question for everyone else is whether these results generalise to less-supported, more complex, more heterogeneous environments.

Pricing: pay-per-second with support credits

The pricing model is usage-based, billed per second of agent activity at $0.0083 per agent-second. You only pay when the agent is actively working — no charges for idle time.

The practical economics: a small team running 10 investigations per month averaging 8 minutes each would pay roughly $40/month. An active team running 80 investigations with additional on-demand SRE tasks would obviously pay more, but the cost-per-investigation is still dramatically lower than the human engineering time it displaces.

The strategic move is the support plan integration. Customers on Business Support+, Enterprise Support, or Unified Operations receive monthly DevOps Agent credits based on their previous month’s support spending — at 30%, 75%, or 100% respectively. For enterprise customers, this means DevOps Agent may be effectively free, funded by the support contract they’re already paying.

New customers also get a 2-month free trial, and the service is included in the AWS Free Tier.

The hard questions OpsHero clients should be asking

The capabilities and results are impressive. But every DevOps team considering adoption should work through these questions honestly:

What is the agent’s actual blast radius? DevOps Agent has read access to your logs, metrics, code, deployment history, and infrastructure topology. It can correlate data across AWS, Azure, and on-premises systems. If this agent is compromised or hallucinates at the wrong moment, what can it touch? This is the same “AI as privileged user” question we raised in our recent analysis of CI/CD security.

Who is accountable when the agent gets it wrong? A popular Reddit thread about the launch included a pointed question about accountability. When a human SRE misdiagnoses an incident, there’s a clear escalation path. When an autonomous agent provides a confident but wrong root cause analysis at 2am, and someone acts on it — who owns that outcome? AWS has not published an accountability model for agent recommendations.

How does this change your on-call culture? The promise is that the 2am page becomes less painful because the agent has already investigated and surfaced a likely root cause by the time you open your laptop. That’s genuinely transformational. But it also introduces a new failure mode: what happens when your team starts trusting the agent implicitly and stops developing the diagnostic instincts that catch the cases the agent misses?

Does this consolidate your observability or fragment it further? United Airlines praised DevOps Agent for creating “a single pane of glass.” But the agent’s power comes from connecting to multiple tools — and that introduces a new dependency. If your Dynatrace integration breaks, or your Splunk connector has a permissions issue, the agent’s investigation quality degrades silently. You’ve moved from “many tools, manual correlation” to “one agent, hidden dependencies.”

What is the lock-in calculus? DevOps Agent is deeply tied to the AWS ecosystem — Bedrock AgentCore, CloudWatch, and AWS Support plans. The multi-cloud support (Azure, on-prem via MCP) is a smart move to reduce lock-in anxiety, but the agent itself runs on AWS, and the credits are tied to AWS Support contracts. If you invest deeply in teaching the agent your runbooks and organisational knowledge, that investment doesn’t port.

The OpsHero perspective: this changes the game — with caveats

We’ve been watching agentic AI in operations closely, and the AWS DevOps Agent GA is the first time we’ve seen a major cloud provider ship an autonomous operations agent with real customer results and a production-ready pricing model.

For OpsHero’s clients — especially those in regulated industries with complex multi-cloud environments — this creates a genuine opportunity. The agent’s ability to correlate data across AWS, Azure, and on-prem systems via MCP is precisely the kind of cross-boundary investigation that takes human SREs the longest. If it works as advertised, it compresses the most painful part of incident response — the initial triage and hypothesis-formation — from hours to minutes.

But we’d advise any client to approach adoption with the same rigour they’d apply to onboarding a new team member with broad infrastructure access. Start in a non-production environment. Audit the agent’s permissions. Log every recommendation it makes and compare against your team’s independent analysis. Build the trust incrementally.

The teams that will get the most value from this are not the ones who turn it on and walk away. They’re the ones who treat it as what it is: a powerful, fallible teammate that needs onboarding, guardrails, and ongoing calibration — just like any other participant in your incident response process.

---

Evaluating AWS DevOps Agent for your environment? OpsHero helps engineering teams adopt AI-driven operations tooling with the right guardrails, observability, and compliance controls. Let’s talk.