Greenlight Financial Luna: An Autonomous SOC Resolving 83% of Alerts on Bedrock AgentCore

Greenlight Financial says its AI agents now resolve most of its security alerts without a person. A November 6, 2026 post on the AWS Machine Learning Blog by Adam Maksimuk, Gaurav Begwani, Mani Teja Nissankararao and Venu Thangalapally describes Luna, an autonomous security operations center (SOC) built on Amazon Bedrock AgentCore. The headline number is an 83% autonomous resolution rate with the first tier alone and above 90% with a second tier.

That number comes from the company that built the system, published on the vendor blog. It is worth reading for the design, and worth reading carefully for the claims.

TL;DR: what Greenlight reports

Agents that act on your behalf need rules. See how explainx helps secure your agents →

What problem was Greenlight solving?

Greenlight provides financial products for families. Its alerts come from four sources: dark web breach cards, identity and access anomalies, infrastructure alerts, and financial risk events. A human analyst needs 15 to 30 minutes per case, which does not scale at 3,000 to 4,000 cases a month.

The company set four goals, according to AWS: triage routine cases on its own, escalate complex ones with full context, learn from outcomes, and stay inside financial-services compliance guardrails.

This is a familiar shape. Security teams drown in low-value alerts, and the interesting question is whether language-model agents can take the routine bulk safely. Our guide to the open-source AI security operations center AISOC covers the same problem from the open-source side.

How is Luna built?

Autonomous SOC architecture: Tier 1 supervisor orchestrating specialized agents and escalating to a Tier 2 supervisor Image: AWS

Luna copies how a human SOC team is organised: a first line for volume and a second line for complexity.

Tier 1 supervisor. It runs on AgentCore runtime inside an Amazon VPC with private subnets. It orchestrates more than 30 specialised agents covering identity, endpoint detection, observability, payments, customer support and SOAR remediation playbooks. It picks agents by alert type and returns a verdict.

Tier 2 supervisor. It uses a more capable model with extended reasoning for the roughly 10% of cases that need multi-step investigation. It chains evidence across three to five data sources and writes reports for human review. It runs on EventBridge schedules and SNS completions, and on demand for urgent escalations.

Entry points. Alerts arrive automatically from Tines SOAR. Security, risk and ProdOps engineers can also call Luna through API Gateway, a queue API and an MCP endpoint, and on-call engineers get a Claude Desktop extension. Our explainer on the Model Context Protocol shows why an MCP endpoint is a handy way to give humans the same access agents have.

The services named in the post are AgentCore runtime and memory, Bedrock foundation models, VPC, S3, API Gateway, EventBridge, SNS, Lambda and DynamoDB. Third-party tools include Tines, Galileo, Mixpanel and Zendesk.

How does Luna learn from past cases?

Memory is the part that sets this apart from a stateless alert classifier. AWS describes three pieces.

A digest of these learnings is fed back to the Tier 1 supervisor as context. AgentCore memory supports built-in strategies such as semantic, summarisation, user preference and episodic memory, according to the AgentCore memory docs, which also mark parts of the service as preview and subject to change.

The idea of agents that learn from their own outcomes is hot right now. We covered it in Databricks MemCurrent and in Cognition Devin dreaming memory. We also covered a paper arguing that agent memory systems can underperform naive retrieval. Greenlight gives no ablation, so we cannot tell how much of the 83% comes from memory.

What are the results, and how solid are they?

A green bandage across a crack in a cream storage box, a metaphor for automated incident triage in an autonomous SOC

The post compares three states. Cases per month stay at 3,000 to 4,000 in all of them.

Four things to keep in mind when reading this table:

1. It is self-reported. The post is a customer write-up on the vendor blog. The visible text describes no independent audit.
2. The savings are derived. The 900 to 1,800 hours a month comes from 4,000 cases at 15 to 30 minutes each. That is arithmetic on an assumption, and not a measured saving. Cost avoidance is described only as significant.
3. "Resolved" is not "resolved correctly". The post gives no false-negative rate, meaning real incidents the agents closed as benign. In a SOC that is the number that matters most.
4. The numbers are slightly inconsistent. The intro says up to 4,000 cases a month and the body says 3,000 to 4,000.

None of this means the system does not work. It means a reader cannot yet tell how well. If you are evaluating a similar build, ask for the miss rate, a sample of closed cases audited by humans, and how often analysts reverse an agent verdict.

What safeguards does the post describe?

AWS lists escalation to humans for high-risk cases with a full evidence chain, a confidence threshold that triggers Tier 2, deduplication and allowlisting to cut false positives, and deployment in private subnets of a VPC. It says compliance guardrails were a requirement, but the visible text gives few specifics about them. The copy we fetched was also cut off before the later lessons and closing caveats, so we cannot comment on those.

Allowlisting deserves attention. When memory teaches the system that a pattern is benign, an attacker who can imitate that pattern gets a free pass. A learned allowlist is a feature and an attack surface at once. Our write-ups on AgentCorruption and on AWS trust in depth for agent autonomy cover how agent permissions and shared state can be abused, and AWS has since published a sample for running Claude Code on AgentCore with security controls.

How did the scope grow?

AWS says that within two months of the SOC launch, Greenlight added financial risk triage by adding specialised agents and a risk-domain supervisor. For dark web breach cards, which arrive in the hundreds daily, Luna verifies the card in Galileo, deduplicates notifications in DynamoDB, cross-references Mixpanel and Zendesk, and then logs, flags or escalates based on risk.

The visible lessons are practical. Start with a bounded domain and grow by adding agents instead of rebuilding. Mirror the human team structure, which helped build trust with the security team. Memory compounds in value over time.

How does this compare with other agent write-ups?

Most agent case studies report a task success rate on a benchmark. Luna reports an operational outcome in production: how many real alerts a team no longer touches. That is more useful to a buyer, and harder to verify from outside. A benchmark can be re-run by anyone. A production figure depends on how the company counts a case, what it counts as resolved, and which alerts it routes away before the agents see them.

Two questions help when you read any similar claim. First, what is the denominator: all alerts, or only those the system accepted? Second, who checks the closed cases, and how often do they overturn the agent? Greenlight's post answers neither in the text we could read. That does not make the result false. It makes it a claim to test in a pilot, with your own alerts and your own audit sample, before you plan headcount around it.

What this means if you build or buy agent systems

• The pattern is portable. A supervisor that routes to narrow specialists, plus a stronger second tier for hard cases, works outside security. Cost stays low because the expensive model sees only about 10% of cases.
• Measure misses, not only closures. An 83% autonomy rate is meaningless without a false-negative rate.
• Budget for memory hygiene. Decide who can write to long-term memory, how entries expire, and how you detect a poisoned lesson.
• Keep humans on the edges. Both the high-risk path and the audit of closed cases need people.
• Treat vendor case studies as claims. Ask for the method behind each number.

If you run AI agents of your own inside a security workflow, AgentBeam, the agent security platform from the explainx.ai team, stops AI agents before they take dangerous actions, which is a useful control around any autonomous responder.

Related reading

• AISOC: open-source AI security operations center
• Databricks MemCurrent agent memory
• Cognition Devin dreaming memory
• Memory tax: agent memory vs naive RAG
• AgentCorruption: one prompt hijacked every Bedrock AgentCore agent
• AWS trust in depth for agent autonomy
• Claude Code remote sessions on Bedrock AgentCore
• What is MCP

Figures reflect the AWS post dated November 6, 2026 and Greenlight own reporting. They may change.