Building a Cost-Effective Autonomous Threat Containment System on AWS

This year at AWS re:Invent 2025, I didn't fly out to Las Vegas. Instead, I followed along remotely—streaming the keynotes live and keeping a close eye on the AWS Blog announcements. Watching Amazon Bedrock AgentCore introduce Policy controls, Episodic Memory, and Gateway integrations, I found myself both excited and curious.

But after absorbing all these impressive announcements, a practical question kept coming back to me: How do I actually start building autonomous security systems without committing to expensive managed services from day one?

This post documents my journey building a proof-of-concept Autonomous Threat Containment Agent using native AWS services. I'll share what worked, what broke, and how the new AgentCore capabilities could elevate this architecture to production-grade.

The AWS re:Invent 2025 Context

Before diving into implementation, let me summarize the key announcements that inspired this project:

Amazon Bedrock AgentCore Updates

Policy in AgentCore (Preview): Define deterministic, real-time controls over agent actions using Cedar language or natural language. Policies integrate with AgentCore Gateway to intercept tool calls in milliseconds.

AgentCore Evaluations (Preview): Continuous quality assessment with 13 pre-built evaluators covering correctness, helpfulness, and tool selection.

Episodic Memory: Agents can learn from experiences over time. For incident response, your agent can remember that last month's GuardDuty finding was a false positive.

The Cost Reality Check

Here's the thing—AgentCore Gateway, Memory, and Policy are powerful, but they come with costs that might not make sense for initial experimentation. I wanted to validate the patterns before committing to managed services.

The answer: validate patterns using native AWS services. My POC cost approximately $0.15 to build and test.

---

The Architecture

My goal was to create a system that:

1. Detects security threats from GuardDuty
2. Enriches findings with correlated signals
3. Checks historical context (simulated episodic memory)
4. Evaluates policies before taking action
5. Executes containment (isolation, forensic snapshots)
6. Notifies the security team
7. Records episodes for future learning

┌─────────────────────────────────────────────────────────────┐
│                  GuardDuty Sample Findings                  │
│               (Free test events, real format)               │
└─────────────────────────────┬───────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│           EventBridge Rule (severity >= 4 filter)           │
└─────────────────────────────┬───────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│              Step Functions State Machine                   │
│                                                             │
│  Enrich → Check Memory → Evaluate Policy → Containment      │
│                                    │                        │
│                                    ▼                        │
│                   Parallel: Snapshot + Isolate              │
│                                    │                        │
│                                    ▼                        │
│                    Notify SOC → Record Episode              │
└─────────────────────────────────────────────────────────────┘

Design Decisions

Step Functions as Orchestrator: Visual debugging, built-in error handling, parallel execution—costs pennies for low-volume workloads.

DynamoDB as Episodic Memory: Simple GSI query on findingType for similar past incidents. Not as sophisticated as AgentCore Memory's semantic search, but demonstrates the pattern.

Lambda-based Policy Engine: Cedar-inspired rules in Python. Changes require redeployment, but validates the concept.

GuardDuty Sample Findings: The key insight! CreateSampleFindings API generates events that flow through EventBridge exactly like real threats—perfect for testing.

---

Lessons Learned the Hard Way

The EventBridge Severity Filter Gotcha

My initial EventBridge rule:

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "severity": [{"numeric": [">=", 4]}]
  }
}

I generated sample findings and... nothing happened. Zero Step Functions executions.

The debugging process:

# Check EventBridge invocations
aws cloudwatch get-metric-statistics \
  --namespace AWS/Events \
  --metric-name Invocations \
  --dimensions Name=RuleName,Value=ThreatContainmentTrigger \
  --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 300 --statistics Sum

# Result: {"Datapoints": []}  -- No invocations!

When I manually tested Step Functions, it worked perfectly. The issue was the EventBridge-to-Step Functions connection.

Two problems discovered:

• IAM Role permissions hadn't propagated: Always verify with:

aws iam get-role-policy \
  --role-name ThreatContainmentEventBridgeRole \
  --policy-name InvokeStepFunctions

• Sample finding severity was too low: UnauthorizedAccess:EC2/SSHBruteForce has severity 2.0, which doesn't match >= 4!

Finding Type	Severity	Matches >= 4?
UnauthorizedAccess:EC2/SSHBruteForce	2.0	❌
Backdoor:EC2/C&CActivity.B	8.0	✅
CryptoCurrency:EC2/BitcoinTool.B	8.0	✅

The fix:

aws guardduty create-sample-findings \
  --detector-id $DETECTOR_ID \
  --finding-types "Backdoor:EC2/C&CActivity.B"

The Lambda Policy Engine

Here's my Cedar-inspired policy logic:

def lambda_handler(event, context):
    enriched = event.get('enriched', {})
    memory = event.get('memoryContext', {})

    ctx = {
        'severity': enriched.get('severity', 0),
        'falsePositiveRate': memory.get('falsePositiveRate', 0),
        'isSampleFinding': enriched.get('isSampleFinding', False),
        'correlationScore': enriched.get('correlationScore', 0)
    }

    # Policy 1: Sample findings - forensics only
    if ctx['isSampleFinding']:
        return {
            'action': 'PERMIT_NON_DESTRUCTIVE',
            'policyName': 'sample-finding-safe-mode',
            'allowDestructiveActions': False
        }

    # Policy 2: High false positive rate - require review
    if ctx['falsePositiveRate'] > 0.3:
        return {
            'action': 'REQUIRE_APPROVAL',
            'policyName': 'high-false-positive',
            'requiresHumanApproval': True
        }

    # Default: permit
    return {
        'action': 'PERMIT',
        'policyName': 'default-permit',
        'allowDestructiveActions': True
    }

This works, but it's brittle. Compare to AgentCore Policy:

"Allow isolation only when severity >= 7 
 AND correlation score >= 1 
 AND resource is not tagged critical-infrastructure"

Natural language, automatically converted to Cedar, validated against schemas.

---

Successful Execution

After fixing the issues:

$ aws stepfunctions list-executions --state-machine-arn $STATE_MACHINE_ARN

Name                                    Status     
29412f07-f4f5-..._a25c994c-b3cd-...    SUCCEEDED  
29412f07-f4f5-..._38d9c825-0538-...    SUCCEEDED  

DynamoDB captured the episodes, SNS delivered alerts with full context.

---

Path to Production: AgentCore Upgrades

Current (POC)	AgentCore (Production)
Lambda policy engine	Policy (Cedar + NLP)
DynamoDB queries	Memory (semantic search)
Direct Lambda invocation	Gateway (MCP discovery)
No quality monitoring	Evaluations (continuous)

Cost Comparison

Component	POC	Production
Orchestration	~$0.025/1K	AgentCore Runtime
Memory	~$1.25/1M writes	AgentCore Memory
Testing	FREE (samples)	FREE
Total POC	~$0.15	~$50+

---

Try It Yourself

Full source code available on GitHub:

lshw54 / aws-threat-containment-agent-demo

Autonomous threat containment agent built with AWS native services

AWS Threat Containment Agent

A cost-effective, serverless autonomous threat containment system built on AWS. This POC demonstrates how to automatically detect, analyze, and respond to security threats using native AWS services—inspired by the agentic AI patterns announced at AWS re:Invent 2025.

🎯 Overview

This project implements an autonomous security response pipeline that:

1. Detects threats via Amazon GuardDuty
2. Enriches findings with correlated signals from Security Hub
3. Evaluates containment policies (Cedar-inspired rules)
4. Checks incident memory for similar past events
5. Executes containment actions (isolation, forensic snapshots)
6. Notifies the security team via SNS
7. Records episodes for future learning

Why This Project?

After attending AWS re:Invent 2025 and seeing the Amazon Bedrock AgentCore announcements, I wanted to validate the agentic security patterns without committing to expensive managed services upfront. This POC cost approximately $0.15 to build and test.

🏗️ Architecture

┌─────────────────────────────────────────────────────────────────────────┐
│                     GuardDuty (Sample Findings for Testing)             │
└────────────────────────────────┬────────────────────────────────────────┘
                                 │
                                 ▼
┌─────────────────────────────────────────────────────────────────────────┐
│              EventBridge Rule

…

View on GitHub

Deploy in minutes:

git clone https://github.com/lshw54/aws-threat-containment-agent-demo.git
cd aws-threat-containment-agent-demo
./deploy.sh

---

What's Next?

• Add handlers for S3, IAM, Kubernetes threats
• Implement rollback automation
• Build SOC feedback UI
• Migrate to AgentCore when patterns are battle-tested

The AWS re:Invent 2025 announcements have given us a clear vision. The infrastructure is ready. From here, it's about exploring what works for your specific use case.