I Let AWS's Frontier Agents Review My Code, My Pipeline, and My Bill
A hands-on walkthrough of AWS Continuum (Security Agent), AWS DevOps Agent, and AWS FinOps Agent - using a deliberately broken sample app in my own AWS account.
When AWS unveiled its "Frontier Agents" lineup, my first reaction was: wait, didn't AWS DevOps Agent and AWS Security Agent already exist? Turns out yes, both went GA back in March 2026. What AWS Summit NYC 2026 actually added was a release-management capability for DevOps Agent and a new umbrella security platform called AWS Continuum that absorbed Security Agent.
AWS FinOps Agent, the newest member of the lineup, had gone into preview about a week earlier.
Reading the announcement posts is one thing. I wanted to know what these agents actually do when pointed at something real: my own GitHub repo, my own broken code, my own AWS bill. So I built a small, deliberately imperfect demo and let all three loose on it. Here's what came back.
1. The Frontier Agents lineup, correctly framed
AWS's official Frontier Agents page lists four members, not three, and one of them changed names while I was still researching it:
- AWS Continuum (launched June 17, 2026): the new umbrella security platform. AWS Security Agent has been folded into it: "AWS Security Agent (now part of Continuum)." Continuum pen testing is GA, Continuum code scanning and threat modeling are Preview, and the broader 4-phase vulnerability lifecycle (Discovery, Prioritization, Validation, Remediation) is Gated Preview.
- AWS DevOps Agent (GA since March 2026): an ops teammate for incident triage, root cause analysis, and now release-readiness reviews.
- Kiro (GA): spec-driven development, with its own autonomous-agent mode that takes GitHub-assigned tasks like a virtual developer.
- AWS FinOps Agent (Public Preview, launched June 9, 2026): cost investigation, anomaly root-causing, and optimization recommendations.
The Summit didn't introduce three brand-new agents, it upgraded DevOps Agent, rebranded Security Agent under the new Continuum platform, and launched FinOps Agent(just a week before the summit).
2. What I built to test them
I created a small repo,
cloud-patrol-demo, wrapping a single Lambda function: a network diagnostics tool that pings a host passed in via an event payload, after validating it against an allowlist pattern. Clean baseline on main. Then two follow-up branches, opened as pull requests, each with a planted problem:- PR #1 (
feature/connectivity-debug-tool): a "deep diagnostics override" mode usingsubprocesswithshell=Trueon unsanitized input, classic command injection, gated behind a hardcoded override password. The kind of shortcut a tired on-call engineer might actually ship. - PR #2 (
feature/diagnostic-v2): a "simplification" that swapsevent.get("host")for directevent["host"]indexing, and changes the return value from a structured{statusCode, body}dict to a raw string. Both changes look like harmless cleanup. Both quietly break things.
3. AWS Continuum (Security Agent): catching what I tried to sneak in
What I connected and ran here is still labeled AWS Security Agent in the console, but per AWS's own Continuum page it's now officially "AWS Security Agent (now part of Continuum)", and the code review I ran below is what AWS now calls Continuum code scanning, currently in preview. After installing the GitHub App and registering
cloud-patrol-demo in the console, I ran a full code review from the Security Agent web application.
The cloud-patrol-demo Agent Space - Penetration testing, Threat models, Design reviews, and Code reviews are all ready to run.
run in progress: Preflight, Static analysis, Validation, and Finalizing all complete.
Six findings came back: 1 High, 3 Medium, 2 Low.
Findings summary - severity breakdown and risk types, including the Command Injection I planted.
What this demonstrates: I expected it to flag exactly the one bug I wrote. Instead it flagged Command Injection plus four other risk categories: Server Side Request Forgery, Information Disclosure, Security Misconfiguration, and Authentication Bypass, all from roughly 40 lines of code. That's the kind of breadth a rushed end-of-sprint human review usually misses.
4. AWS DevOps Agent: blocking my "harmless" cleanup
Connecting GitHub to DevOps Agent surfaced as a "release management capabilities" onboarding banner on the AgentSpace page rather than a static settings section, a reminder that this is a brand-new preview feature still finding its UI. Once connected, I pushed an empty commit to PR #2 to trigger a fresh review.
DevOps Agent's inline review comment on PR #2, marked Blocking, explaining exactly why removing the safe get() lookup breaks error handling.
It identified the regression precisely: swappingevent.get("host")for direct indexing turns a clean validation failure into an unhandledKeyError, which surfaces to the caller as a 502 through API Gateway instead of a clean 400, and pollutes the function's CloudWatchErrorsmetric with client input mistakes.
The Report tab breaks down both detected changes: the missing-host validation guard, and the response shape change.
It also caught the second, unrelated issue in the same diff: the response no longer matches the Lambda proxy integration shape, breaking every caller that expects astatusCode/bodyobject.
Back in the DevOps Agent console: the release-readiness review on PR #2, marked Completed.
The same console doubles as a chat interface for ad-hoc SRE questions, not just automated PR reviews.
What this demonstrates: Two unrelated regressions, both disguised as simplification, both caught from a PR diff alone, no hints from me about what to look for.
5. AWS FinOps Agent: the honest answer
Spinning up a FinOps agent is a five-step wizard: name it, auto-create the agent role, auto-create the web-app role, optionally connect Jira/Slack, review and create. I skipped the integrations and asked it the simplest possible question.
The FinOps Agent web app, with suggested starting tasks - rightsizing reports, scheduled cost checks, anomaly investigation with CloudTrail correlation.
query: the agent powers up its cost-analysis skill and calls the Cost Explorer tool directly.
The answer: this account has essentially no billable spend, with an exact breakdown of the trace amounts that do exist.
What this demonstrates: Rather than invent a plausible-sounding savings number, it told me the truth: near-zero spend, an exact breakdown of which services even appear in the billing data, and it proactively asked whether it should check for linked accounts.For a cost tool, that's exactly what I want: the truth, even when the truth is boring
6. Where Kiro fits
Kiro isn't a fourth peer agent alongside these three, it sits upstream of all of them, as the spec-and-code layer the others react to. It also has its own autonomous-agent mode that takes GitHub-assigned work directly, like a virtual developer. In practice, a real pipeline could chain all four together: Kiro authors the change, Continuum reviews and threat-models the PR, DevOps Agent runs the release-readiness review on the same PR (including any auto-remediation PR Continuum opens), and FinOps Agent watches whether the eventual deploy moves the cost needle, all glued together through the Agent-to-Agent and MCP integration points AWS DevOps Agent already exposes. The human stays the approval gate at every step.
The squad, assembled
None of these agents replaced a decision I needed to make, they replaced the tedious first pass of finding what was wrong. The Security Agent found vulnerabilities I planted and a few I didn't think about. The DevOps Agent blocked two regressions hiding in a one-line diff. The FinOps Agent told me the truth about an account with nothing to hide. That's the actual pitch for agentic tooling: not autonomy for its own sake, but a faster, wider first pass, with the engineer still holding the merge button.
7. The real payoff: earning full autonomy in non-prod
The real reason to wire this up isn't novelty, it's speed: a faster first pass means shipping faster. The natural next step is to let these three run autonomously against non-production environments, within guardrails a human still defines and reviews, auto-merging clean release reviews, auto-remediating findings, acting on cost recommendations without waiting for approval on each individual action, because the boundaries were already set by a person and mistakes in a sandbox are cheap. That's effectively the on-ramp AWS's own AI-Driven Development Lifecycle (AI-DLC) describes: AI-powered execution with human oversight, moving through Inception, Construction, and Operations in tight "bolts" instead of multi-week sprints, where people review and steer the plan and its guardrails rather than approving every single step. Earn that autonomy in non-prod first, under guardrails a human set, and the same guardrails carry forward into production, where the merge button stays in human hands and the path to it gets a lot shorter.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article