AWS Frontier Agents Dissected: What Security Agent and DevOps Agent Actually Do Under the Hood

Last December at re:Invent, Swami Sivasubramanian walked on stage and introduced a term that made a lot of people uncomfortable: frontier agents. Not chatbots. Not copilots. Not AI assistants that wait politely for your next prompt. Autonomous systems that run for hours or days, make their own decisions, and deliver finished outcomes without someone hovering over a terminal.

At the time, it sounded like a vision statement. Yesterday it became a shipping product. Two of them, actually.

AWS Security Agent and AWS DevOps Agent are now generally available. And I want to take them apart, piece by piece, because the marketing copy tells you what they do. It does not tell you how they work. As a Solutions Architect who has spent the last few months mapping the entire AWS agentic stack (Strands, AgentCore, MCP, A2A), these two agents are the first concrete proof that the stack actually holds up in production. That alone makes them worth studying.

I have not run full hands-on tests yet. The GA announcement dropped yesterday, March 31st. What I can do is dissect the architecture, read between the lines of the technical documentation, connect dots that the official blogs leave unconnected, and tell you what I think matters and what I think is noise.

AWS defines frontier agents by three characteristics: they work autonomously toward goals across multiple steps, they scale to handle concurrent tasks across your entire portfolio, and they run persistently for hours or days without constant human oversight.

That last part is the one that matters most. Every AI tool in the market can do step one and step two to some degree. Running for days without a human in the loop? That is a different trust model entirely. It means the system needs to reason about its own progress, handle unexpected states, and decide when to escalate versus when to keep going. That is not a prompt engineering problem. That is an agent architecture problem.

Keep this distinction in your head, because it shapes every design decision in both agents.

Let me start with what this is not. This is not another vulnerability scanner. If you have used tools like Snyk, Checkmarx, Burp Suite, or any SAST/DAST (Static Application Security Testing / Dynamic Application Security Testing) tool, you know the drill: run a scan, get a list of findings, spend three days triaging false positives, fix the real ones, repeat. Those tools look at code in isolation (SAST) or poke at running applications without context (DAST). Neither understands your application as a whole.

AWS Security Agent combines SAST, DAST, and penetration testing into a single context-aware agent. That combination is the interesting part. The agent ingests your source code, architecture diagrams, infrastructure-as-code, design documents, user stories, and threat models. It builds a mental model of your application before it starts testing. Then it uses that model to chain individual vulnerabilities into attack paths that no individual scanner would catch.

The AWS Security Blog published a detailed breakdown of the multi-agent architecture back in February, and it reveals a system that is more sophisticated than the marketing suggests.

Phase 1: Authentication and initial access. The agent starts by actually signing into your application. This sounds trivial until you remember that most security tools skip this step entirely, or require you to manually configure session tokens. Security Agent uses an LLM-based (Large Language Model) sign-in component that can navigate OAuth, SAML, Okta, and MFA (Multi-Factor Authentication) flows. You provide credentials and optional sign-in instructions, and the agent figures out how to use them. It maintains authenticated sessions across the entire test. This is where the browser tool comes in: the agent literally interacts with your application the way an attacker would.

Phase 2: Baseline scanning. Once authenticated, the system launches parallel specialized scanners. Think of this as the reconnaissance phase. The agent maps your attack surface: endpoints, parameters, authentication boundaries, API schemas. If you provided OpenAPI or Swagger specs, it uses those. If not, it discovers endpoints through exploration. This phase produces the raw material for everything that follows.

Phase 3: Multi-phased exploration with a specialized agent swarm. This is where it gets interesting. The system does not send a single agent to test everything. It deploys a swarm of specialized agents, each focused on a different risk category. One agent tests authentication bypasses. Another looks for injection vulnerabilities. Another probes business logic flaws. They run in parallel, share findings with each other, and adapt their strategies based on what they discover. The critical insight here is that the system dynamically generates test tasks based on what the swarm finds. This is not a static playbook. If one agent discovers an admin endpoint that was not in the original specification, the system creates new test tasks targeting that endpoint. The swarm adapts.

Phase 4: Validation and report generation. Every finding goes through independent validation. A separate validation agent takes the exploit path discovered by the swarm, reproduces it from scratch, and confirms it works. This is why the preview customers report dramatically fewer false positives. The system does not report a finding until it has been independently confirmed. Each validated finding includes CVSS (Common Vulnerability Scoring System) risk scores, application-specific severity ratings, detailed reproduction steps, and recommended fixes.

The GA blog post includes a scenario that perfectly illustrates why context awareness matters. Three individual findings: a stored XSS (Cross-Site Scripting) rated CVSS 6.1, a session hijack that produces zero alerts in any traditional tool, and a database credential exfiltration through an admin config endpoint rated CVSS 9.8. In isolation, the XSS sits in a backlog for weeks. The session hijack generates no finding at all because SAST does not analyze runtime sessions, DAST crawls as a standard user, and EDR/XDR (Endpoint Detection and Response / Extended Detection and Response) sees a valid HTTPS session. The admin endpoint works as designed, so no tool flags it.

Security Agent chains all three. It reads the PRD (Product Requirements Document) and understands that the admin config endpoint was designed for troubleshooting but assumes the authentication gateway prevents unauthorized access. It proves the full attack path: XSS captures admin session cookie, hijacked session reaches the admin panel, admin config endpoint exposes production database credentials in plaintext. A deprioritized medium-severity finding becomes the entry point to a critical data exfiltration.

No individual SAST, DAST, or SCA (Software Composition Analysis) tool would catch this chain. Most human penetration testers would need days to connect these dots. The agent did it by understanding the application holistically before starting to attack it.

The agent scored 92.5% on CVE Bench v2.0. That is a standardized benchmark for vulnerability detection, and it is a strong number. But benchmarks test known vulnerability patterns. The real value is in zero-day discovery against custom business logic, where traditional CVE databases are useless. The customer quotes suggest this is where the agent shines, but we will need hands-on validation to confirm.

GA regions: US East (N. Virginia), US West (Oregon), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Sydney), and Asia Pacific (Tokyo). Six regions. No South America yet, which matters if you have data residency requirements for Brazilian or Latin American workloads.

New customers get a two-month free trial. The pricing model beyond that is not fully detailed in the GA announcement, but the product page links to a pricing page worth reading before you commit.

Multicloud support is real: AWS, Azure, GCP, other cloud providers, and on-premises. You provide a URL for public endpoints or connect private endpoints through a VPC. This means you can consolidate penetration testing across your entire infrastructure in one tool, regardless of where it runs.

GitHub Enterprise integration lets the agent automatically review pull requests for security violations and submit pull requests with recommended fixes when it finds something during a pentest. That closes the loop from discovery to remediation inside the developer workflow.

If Security Agent is an offensive agent that attacks your applications to find weaknesses, DevOps Agent is a defensive agent that monitors your applications and fixes problems when they break.

But calling it a monitoring tool undersells it by a wide margin. DevOps Agent is an autonomous incident responder that correlates data across your entire operational stack, identifies root causes, generates mitigation plans, and coordinates response through your existing communication channels. It also analyzes historical patterns to prevent future incidents before they happen.

DevOps Agent is organized around the concept of Agent Spaces. An Agent Space is a logical container that defines what the agent can access: your AWS accounts, third-party tool integrations, and access permissions. You can organize Agent Spaces by application, by on-call team, or by any organizational model that makes sense for your operations.

The agent builds an application topology graph. It maps your resources and their relationships automatically. This is not a static diagram. The topology evolves as the agent completes more tasks and discovers new resources. Think of it as the agent building its own understanding of your infrastructure through direct experience.

When an incident occurs, the agent does not wait for someone to open a ticket. It starts investigating the moment an alert fires. The investigation process follows a pattern that experienced SREs (Site Reliability Engineers) would recognize: correlate telemetry (metrics, logs, traces) with recent code deployments and infrastructure changes, identify the most probable root cause, and generate a detailed mitigation plan with specific actions, success criteria, and rollback procedures.

The agent integrates with CloudWatch natively, but also with Datadog, Dynatrace, New Relic, Splunk, and Grafana. On the deployment side, it works with GitHub Actions, GitLab CI/CD, and Azure DevOps. For communication, it routes to Slack, ServiceNow, and PagerDuty.

And here is the part that connects directly to what I covered in Week 2 of this series: DevOps Agent supports custom tool integration through MCP (Model Context Protocol) servers. You can connect the agent to your own MCP server, which means you can integrate it with any internal tool, proprietary ticketing system, or custom observability solution your organization uses. This is MCP doing exactly what I described three weeks ago: acting as the protocol layer that lets agents interact with external tools without being hardcoded to any specific implementation.

The Swami blog post mentions that DevOps Agent works with Kiro and Claude Code to generate validated fixes that can be applied back into the system. That is not a throwaway line. If the agent identifies a root cause in a Lambda function configuration, it can generate a fix and feed it back into your development workflow. The loop from detection to resolution becomes tighter than any purely human-driven process.

DevOps Agent uses a dual-console design. Administrators use the AWS Management Console to create Agent Spaces, configure integrations, and manage access controls. Operators use a separate DevOps Agent web app for day-to-day incident response, investigation steering, topology browsing, and reviewing preventative recommendations. This separation is smart. It keeps the blast radius of operator actions contained while giving administrators full governance control.

Customers in the preview reported up to 75% lower MTTR (Mean Time to Resolution), up to 80% faster investigations, and 94% root cause accuracy. Western Governors University deployed DevOps Agent into production before the preview even launched and reduced resolution time on a service disruption from an estimated two hours to 28 minutes. The Commonwealth Bank of Australia replicated a complex network and identity management issue that would take a seasoned engineer hours to diagnose. The agent found the root cause in under 15 minutes.

These are impressive numbers, but they come from preview environments with likely favorable conditions. The real test is sustained performance across months of diverse incidents in production. That data does not exist yet.

During preview, DevOps Agent operated exclusively from US East (N. Virginia) as its processing hub, though it could reach into resources across all regions in your configured accounts. The exact region list at GA is worth confirming in the console. Preview was free with quotas (10 Agent Spaces, limited task hours per month). GA pricing details are not fully public at the time of writing.

Step back and look at what both agents share:

Agent Spaces as organizational boundaries. Both agents use the concept of Agent Spaces to define scope, permissions, and context. This is a consistent abstraction that maps cleanly to how enterprises organize teams and applications. It also means the agents only see what you let them see.

Context ingestion before action. Security Agent reads your code, docs, and architecture before attacking. DevOps Agent builds a topology graph of your resources before investigating. Both agents invest in understanding before doing. That is a design philosophy borrowed from how skilled humans work, and it is the opposite of how most automated tools operate.

Multi-agent orchestration internally. Security Agent uses a swarm of specialized agents that share findings and adapt strategies. DevOps Agent correlates data across multiple tools and generates coordinated responses. Neither agent is a single model running a single prompt. They are orchestrated systems with specialized components.

MCP as the integration protocol. DevOps Agent explicitly supports MCP for custom tool integration. Security Agent integrates with GitHub through its own mechanism. But the pattern is the same: the agent needs to interact with tools it was not built for, and it needs a protocol to do that safely.

Multicloud by design. Both agents work across AWS, Azure, GCP, and on-premises. AWS built frontier agents that are not locked to the AWS ecosystem. That is a strategic choice that tells you where AWS sees the competitive advantage: the intelligence the agents provide, regardless of where the infrastructure lives.

I have not used either agent in production yet. The GA dropped yesterday. But based on the architecture, the documentation, and the preview reports, here is what I want to validate:

Security Agent: Does the context ingestion scale? The agent ingests source code, architecture docs, threat models, and user stories. For a microservices application with fifty repositories and thousands of endpoints, how deep does the context actually go? Does the agent prioritize, or does it try to understand everything and hit performance limits?

DevOps Agent: How good is the topology graph for complex architectures? The agent builds its own understanding of your infrastructure. For a multi-account, multi-region setup with cross-account roles, shared VPCs, and third-party integrations, how accurately does the topology reflect reality? Misunderstanding a dependency is worse than not knowing about it.

Both agents: What happens when they are wrong? The preview metrics are strong. But 94% root cause accuracy means 6% of the time the agent points you in the wrong direction. In incident response, a wrong root cause analysis can extend an outage by hours. What does the escalation path look like? How does the agent signal uncertainty?

Both agents: How do they handle sensitive data? Security Agent ingests your source code and tests against production endpoints during pentest. DevOps Agent reads your logs, metrics, and deployment data. Both agents process information that is sensitive by definition. The documentation says your data is never used to train models and all activity is logged to CloudTrail. But the compliance and governance questions for regulated industries (finance, healthcare) will be detailed and worth tracking.

Two months ago, I mapped the AWS agentic stack: Strands as the framework layer, AgentCore as the infrastructure layer, MCP as the tool integration protocol, A2A as the agent-to-agent protocol. At the time, the stack felt theoretical. There were no AWS-built agents that demonstrated the full vision.

Today there are two. Security Agent and DevOps Agent are not just products. They are existence proofs. They show that the agentic stack can support agents that run for hours, coordinate multiple specialized sub-agents, integrate with third-party tools through standardized protocols, and deliver outcomes that previously required teams of human specialists.

Whether these specific agents work as well as the preview numbers suggest, only production time will tell. But the architecture patterns they establish will shape how every agent built on AWS works going forward.

I will be setting up both agents as soon as the console lets me in. Expect field notes from actual hands-on testing in the coming weeks.

For now, here are the links that matter:

Erick Mancz is an AWS Solutions Architect holding Golden Jacket status (all active AWS certifications). He writes about agentic architecture, distributed systems at scale, and the intersection of ML/GenAI with cloud infrastructure. This is Week 5 of Golden Jacket Field Notes. Previous weeks: Bedrock Knowledge Bases in production, the AWS agentic stack, payment authorization architecture, and MCP context management. Connect with him on Medium  and LinkedIn .