Marcelo Acosta Cavalero for AWS Community Builders

Posted on May 25 • Originally published at buildwithaws.substack.com

Steal These 25 Compliance and Security Agent Patterns for AWS

#devops #security #aws #webdev

Originally published on Build With AWS. Subscribe for weekly AWS builds.

The security team got paged at 2am.

An IAM role in the production account had been granted S3 full access.

The CloudTrail event showed when it happened and who did it.

What it did not show was whether this change violated their least-privilege policy, which compliance framework required remediation within 24 hours, whether other roles in the same account had similar drift, and what the correct permission set should have been.

The analyst spent three hours cross-referencing IAM policies against their access matrix spreadsheet, checking the SOC 2 control mapping in Confluence, and writing the finding into GRC tool.

The violation was straightforward.

The investigation and documentation ritual was not.

This is the fifth and final edition of a five-part series cataloging real AI architecture patterns running on AWS.

Edition 1 covered customer-facing agents.

Edition 2 covered internal knowledge and productivity agents.

Edition 3 covered workflow automation and process agents.

Edition 4 covered data and analytics agents.

This edition addresses the domain where agents face the highest stakes and tightest constraints: compliance, security, and governance.

Agents that audit configurations, detect violations, investigate incidents, manage regulatory obligations, and maintain the control posture that keeps organizations out of trouble.

If you missed the earlier editions, go back to Edition 1 for the “Agent or Not?” scoring framework and the AgentCore vs Quick breakdown.

Edition 3 introduced the hybrid Step Functions + AgentCore pattern for workflow automation.

Edition 4 introduced the answer-versus-query decision for analytics agents.

Both concepts apply here, with additional constraints unique to high-stakes environments.

The Trust Boundary for Compliance Agents

Compliance and security agents operate under a fundamentally different trust model than every other category in this series.

A customer support agent that makes a mistake generates a bad experience.

A compliance agent that makes a mistake generates a regulatory finding, a failed audit, or a missed breach notification deadline.

The blast radius is organizational, not transactional.

Three principles govern how these agents should operate.

Recommend, do not remediate by default.

Most compliance and security agents should generate findings, recommendations, and draft responses rather than taking autonomous action.

The human-in-the-loop is not a limitation of the technology - it is a control requirement.

Auditors want to see that a qualified person reviewed the finding before action was taken.

Agents that auto-remediate should be restricted to pre-approved, bounded actions (blocking a known-malicious IP, revoking a compromised credential) with full audit trails and rollback capability.

Evidence preservation is non-negotiable.

Every agent decision must produce an audit trail that shows what data the agent examined, what reasoning it applied, and what recommendation or action it produced.

This is not logging for debugging.

This is evidence for auditors.

The trail needs to be immutable (S3 with object lock, or equivalent), timestamped, and retained according to your regulatory requirements.

AgentCore Observability provides agent execution traces.

Supplement with explicit evidence capture at each decision point.

Policy as code, not policy as prompt.

Agent behavior boundaries should be defined in AgentCore Policy (which uses natural-language authoring to generate candidate Cedar authorization policies, validates them, and checks safety conditions) or equivalent deterministic enforcement, not in system prompts that the model might drift from.

Policy enforcement applies primarily to tool interactions routed through AgentCore Gateway - actions outside the Gateway path still need explicit IAM constraints, application-level logic, or workflow controls.

The prompt tells the agent what to analyze and how to reason.

Policy tells the agent what it is allowed to do through Gateway-mediated tools.

These are different concerns with different reliability requirements.

Unless otherwise noted, all references to AgentCore Policy in this edition assume enforcement through actions exposed via AgentCore Gateway.

The Continuous Compliance Model

Traditional compliance operates on a cycle: prepare for the audit, scramble to collect evidence, pass the audit, relax until next year.

This edition’s patterns enable continuous compliance - agents that monitor controls in real-time, detect drift immediately, generate evidence continuously, and maintain audit readiness as a steady state rather than a periodic event.

The shift matters because regulatory environments are moving toward continuous assurance.

SOC 2 Type II already evaluates controls over a period, not at a point in time.

PCI DSS 4.0 introduces continuous monitoring requirements.

DORA (Digital Operational Resilience Act) requires ongoing ICT risk assessment.

Agents that maintain continuous compliance posture position organizations ahead of where regulatory expectations are heading.

Reference Architectures for Compliance and Security Agents

Compliance and security agents integrate with security tooling, GRC platforms, policy engines, and audit systems rather than the CRM and data warehouse APIs from earlier editions.

Evidence preservation, policy enforcement, and audit trail requirements add architectural components that did not feature in previous editions.

Reference Architecture N - Compliance Monitoring Agent

Platform:

AgentCore

When to use:

The agent continuously monitors compliance controls, detects violations, investigates context, generates findings with evidence, and routes to the appropriate remediation workflow.

Triggers from AWS Config rule evaluations, Security Hub findings, GuardDuty alerts, CloudTrail events, or scheduled scans.

AgentCore Policy constrains the agent to read-only operations and pre-approved bounded remediations.

Evidence flows to an immutable S3 bucket with object lock for audit retention.

Covers compliance monitoring, control drift detection, finding investigation, evidence collection, and regulatory reporting automation.

Reference Architecture O - Security Investigation Agent

Platform:

AgentCore

When to use:

The agent investigates security alerts by correlating data across multiple sources, building a timeline of events, assessing blast radius, and producing an investigation report.

AgentCore Memory maintains investigation context across multi-step analysis.

The agent reads broadly but acts narrowly - investigation is read-heavy, and any containment actions require explicit policy authorization.

Covers alert triage, incident investigation, threat hunting, and forensic analysis where the agent augments the analyst rather than replacing them.

Reference Architecture P - Policy and Document Analysis Agent

Platform:

AgentCore

When to use:

The agent analyzes documents (policies, contracts, regulatory texts, audit reports) against compliance requirements, control frameworks, or organizational standards.

Uses Bedrock’s long-context capabilities for document analysis and Bedrock Knowledge Bases for retrieval against regulatory corpora.

Produces structured outputs (gap analyses, control mappings, risk assessments) rather than taking operational actions.

Covers regulatory change analysis, policy gap assessment, contract compliance review, and audit evidence evaluation.

Reference Architecture Q - Multi-Agent Governance Coordinator

Platform:

AgentCore (multi-agent)

When to use:

Complex governance scenarios that span multiple domains: a single security event might require configuration analysis, log investigation, policy evaluation, and compliance impact assessment.

Specialist agents focus on their domain (infrastructure configuration, log analysis, policy interpretation) while the coordinator manages sequencing, evidence aggregation, and final report generation.

Reference Architecture R - Hybrid Compliance Workflow (Step Functions + Agent)

Platform:

Step Functions + AgentCore

When to use:

The compliance workflow has deterministic steps (collecting evidence from APIs, running config checks, pulling audit logs) mixed with judgment steps (interpreting findings, assessing severity, generating remediation guidance).

Step Functions orchestrates data collection and report assembly.

The agent handles the analysis that requires contextual reasoning.

Identical in concept to Architecture H from Edition 3, applied to compliance workflows where the deterministic evidence collection and the AI-powered analysis are clearly separable.

The 25 Use Cases

Configuration and Infrastructure Compliance

#101 - Cloud Configuration Compliance Agent

Pattern: Modernization from RPA

Platform: AgentCore

Complexity: Quick Win

Reference Architecture: N

What the agent does:

Continuously monitors AWS account configurations against compliance frameworks (SOC 2, HIPAA, PCI DSS, CIS Benchmarks).
Goes beyond AWS Config’s rule-based checks by adding contextual analysis.
When Config flags a non-compliant resource, the agent determines whether the finding represents actual risk or an acceptable exception (a public S3 bucket that serves static website assets versus one containing customer data).
Pulls resource tags, account context, and the organization’s exception registry to make this determination.
For genuine violations, generates a finding with the specific control requirement violated, the evidence (current configuration versus required state), a severity assessment based on data sensitivity and exposure, and a recommended remediation with step-by-step instructions.
Tracks remediation progress and escalates unresolved findings based on SLA timers.

AWS services: Bedrock (Claude), AgentCore Runtime, AgentCore Policy (read-only + bounded remediation via Gateway), AWS Config, Security Hub, S3 (evidence store with object lock), DynamoDB (finding state and exceptions registry), EventBridge, SNS (escalation)

You need this if: Your compliance team manually reviews AWS Config findings, spends hours determining which findings are real violations versus acceptable configurations, and maintains a spreadsheet of exceptions that nobody cross-references consistently.

#102 - Infrastructure as Code Policy Agent

Pattern: New build

Platform: Step Functions + AgentCore (hybrid)

Complexity: Strategic Bet

Reference Architecture: R

What the agent does:

Analyzes infrastructure as code (Terraform, CloudFormation, CDK) changes before deployment for compliance violations.
Triggers from pull requests or CI/CD pipeline events.
Step Functions collects the planned changes (terraform plan output or CloudFormation changeset), resource context from the target account, and applicable compliance policies.
The agent analyzes the planned changes against security baselines, compliance requirements, and organizational standards.
Catches issues that static linting misses: a security group rule that technically passes CIS benchmarks but violates your organization’s more restrictive internal policy, or a combination of configuration changes that individually look fine but collectively create an exposure.
Returns a structured review with approve, block, or require-justification decisions.
Approved changes proceed through the pipeline.
Blocked changes include the specific policy violation and remediation guidance.

AWS services: Step Functions, Bedrock (Claude), AgentCore Runtime, AgentCore Policy, CodePipeline/CodeBuild, Bedrock Knowledge Bases (policy corpus), S3 (plan artifacts), DynamoDB (review history), SNS (notifications)

You need this if: Your cloud security reviews are manual bottlenecks in the deployment pipeline, static policy tools (OPA, Checkov, tfsec) catch syntax-level violations but miss context-dependent risks, and teams wait days for security approval on infrastructure changes.

#103 - Drift Detection and Remediation Agent

Pattern: New build

Platform: AgentCore

Complexity: Quick Win

Reference Architecture: N

What the agent does:

Detects configuration drift between the declared state (IaC repositories) and actual state (running infrastructure).
Runs on a schedule and compares deployed resources against their source-of-truth definitions.
For each drift instance, determines whether the drift is benign (auto-scaling adjusted instance count, which is expected), potentially harmful (someone manually modified a security group), or critical (encryption was disabled on a database).
Generates a drift report with severity classification and recommended remediation: reimport the resource to update state, revert the manual change, or update the IaC to reflect an intentional modification.
For pre-approved bounded remediations (reverting security group changes that violate baseline), executes the fix automatically with full audit trail.

AWS services: Bedrock (Claude), AgentCore Runtime, AgentCore Policy (bounded auto-remediation via Gateway), CloudFormation Drift Detection, AWS Config, S3 (drift history), DynamoDB (baseline registry), SNS (alerts)

You need this if: Manual changes to production infrastructure accumulate between audits, your IaC state files diverge from reality, and you discover drift reactively when something breaks rather than proactively through monitoring.

#104 - Multi-Account Governance Agent

Pattern: New build

Platform: AgentCore

Complexity: Strategic Bet

Reference Architecture: N

What the agent does:

Manages compliance posture across an AWS Organization with dozens or hundreds of accounts.
Aggregates Security Hub findings, Config evaluations, and GuardDuty alerts across all accounts into a unified compliance view.
Identifies patterns that span accounts: the same misconfiguration appearing in multiple production accounts (suggesting a flawed baseline), accounts that consistently drift from guardrails (suggesting a team that needs training or tooling), and privilege escalation paths that cross account boundaries.
Generates per-account compliance scorecards and organization-wide trend reports.
Prioritizes remediation by combining severity with blast radius: a medium-severity finding in a production account with customer data ranks higher than a high-severity finding in a sandbox account.

AWS services: Bedrock (Claude), AgentCore Runtime, Security Hub (cross-account aggregation), AWS Organizations, AWS Config (aggregator), CloudFormation StackSets, S3 (compliance reports), DynamoDB (account metadata and scores), EventBridge

You need this if: Your organization manages 20+ AWS accounts, compliance posture varies wildly between accounts, and your security team lacks a consolidated view of where the highest-priority gaps exist across the organization.

#105 - Container and Workload Security Agent

Pattern: New build

Platform: AgentCore

Complexity: Strategic Bet

Reference Architecture: N

What the agent does:

Monitors container workloads for security compliance across ECS, EKS, and Fargate environments.
Scans container images for vulnerabilities using Amazon Inspector, evaluates runtime configurations against CIS Kubernetes benchmarks, monitors pod security policies and network policies, and detects containers running with elevated privileges or without resource limits.
For each finding, provides context that static scanners lack: whether the affected container is internet-facing or internal-only, whether the elevated privileges are documented as required for the workload’s function, and how the finding compares to the organization’s risk tolerance for that environment tier.
For organizations with mature SBOM pipelines and runtime telemetry, the agent can additionally assess whether a vulnerable package is reachable in the application’s execution path, though this requires instrumentation most teams lack initially.
Generates remediation PRs with updated Dockerfiles or Kubernetes manifests for straightforward fixes.

AWS services: Bedrock (Claude), AgentCore Runtime, Amazon Inspector, Amazon ECR, EKS/ECS APIs, GuardDuty (EKS Runtime Monitoring), S3 (scan results), DynamoDB (workload inventory), CodeCommit/GitHub API (remediation PRs)

You need this if: Your container security consists of scanning images at build time but not monitoring runtime configuration, you have no systematic way to prioritize which vulnerabilities actually matter for your workloads, and container security findings pile up faster than your team can triage them.

Identity and Access Governance

#106 - IAM Least-Privilege Analysis Agent

Pattern: New build

Platform: AgentCore

Complexity: Quick Win

Reference Architecture: N

What the agent does:

Analyzes IAM policies across the organization to identify over-permissioned roles, unused permissions, and privilege escalation paths.
Compares granted permissions against actual usage from CloudTrail and IAM Access Analyzer.
For each role, generates a recommended policy that maintains the permissions actually used while removing unused grants.
Identifies risky patterns: roles with wildcard actions, cross-account assumptions without conditions, policies that allow privilege escalation through iam:PassRole or sts:AssumeRole chains.
Produces a prioritized list of remediation actions ranked by risk (a production service role with unused admin permissions ranks above a developer’s sandbox role with broad S3 access).

AWS services: Bedrock (Claude), AgentCore Runtime, IAM Access Analyzer, CloudTrail (usage history), IAM Policy Simulator, S3 (policy analysis reports), DynamoDB (permission inventory)

You need this if: Your IAM policies accumulated through copy-paste-and-expand over years, nobody knows which permissions are actually needed, and your last access review revealed that 60% of permissions granted are never used.

#107 - Access Review and Certification Agent

Pattern: Migration from RPA

Platform: Step Functions + AgentCore (hybrid)

Complexity: Strategic Bet

Reference Architecture: R

What the agent does:

Manages the periodic access review process that SOC 2, HIPAA, and ISO 27001 require.
Step Functions orchestrates the review cycle: extracting current access grants from identity systems, generating review packages for each manager, tracking certification responses, and processing revocation requests.
The agent handles the judgment layer: comparing each user’s access grants against their role requirements, flagging unusual patterns (a marketing user with database access, a former contractor’s permissions still active), drafting recommendations for each access item (certify, revoke, or investigate), and generating the final certification report with evidence.
Reduces the review from a multi-week organizational burden to a focused exercise where managers review agent recommendations rather than raw access lists.

AWS services: Step Functions, Bedrock (Claude), AgentCore Runtime, IAM/SSO APIs, identity provider API (Okta/Azure AD), S3 (review evidence), DynamoDB (review state and decisions), SES (manager notifications)

You need this if: Your quarterly access reviews take 3+ weeks, managers rubber-stamp certifications because reviewing raw access lists is overwhelming, and your compliance team spends days chasing incomplete reviews.

#108 - Service Account and Non-Human Identity Agent

Pattern: New build

Platform: AgentCore

Complexity: Strategic Bet

Reference Architecture: N

What the agent does:

Manages the lifecycle of service accounts, API keys, machine identities, and other non-human credentials that proliferate across cloud environments.
Maintains an inventory of all non-human identities with their purpose, owner, creation date, last usage, and associated permissions.
Detects orphaned service accounts (no recent usage, owner left the organization), over-provisioned machine roles (granted broad access for initial setup, never scoped down), and credentials approaching expiration without rotation plans.
Generates ownership attribution by correlating service account creation events with CI/CD pipeline configurations, Terraform state, and application deployment records.
Produces a non-human identity risk report with specific remediation actions: revoke, scope down, rotate, or reassign ownership.

AWS services: Bedrock (Claude), AgentCore Runtime, IAM APIs, AWS Secrets Manager, CloudTrail (credential usage), Organizations (account context), S3 (identity inventory reports), DynamoDB (identity registry), EventBridge (lifecycle events)

You need this if: Nobody knows how many service accounts exist in your environment, orphaned credentials from decommissioned projects remain active, and your last audit flagged non-human identity management as a material finding.

#109 - Privilege Escalation Path Detection Agent

Pattern: New build

Platform: AgentCore

Complexity: Foundation Build

Reference Architecture: O

What the agent does:

Maps and periodically reassesses privilege escalation paths across your AWS environment.
Analyzes interactions between IAM policies, resource policies, trust relationships, and service-linked roles to identify non-obvious paths from low-privilege starting points to high-privilege outcomes.
Detects scenarios like: a developer role can assume a deployment role that can modify IAM policies, creating an indirect path to admin access.
A Lambda function’s execution role can write to an S3 bucket that triggers another Lambda with broader permissions.
Goes beyond IAM Access Analyzer’s individual policy analysis by modeling multi-step chains.
Produces a privilege escalation graph showing identified paths, prioritized by the starting privilege level required and the target privilege reached.
The depth of analysis depends on the maturity of your asset inventory, IAM documentation, and resource policy coverage - the agent identifies paths it can observe, but cannot map escalation vectors through services it lacks visibility into.

AWS services: Bedrock (Claude), AgentCore Runtime, AgentCore Memory (graph analysis state), IAM APIs, IAM Access Analyzer, Resource Policy APIs (S3, SQS, Lambda, KMS), Organizations (trust relationships), Neptune or DynamoDB (escalation graph), S3 (analysis reports)

You need this if: Your penetration tests regularly find privilege escalation paths that your access reviews missed, you lack visibility into cross-account trust relationship chains, and you cannot answer “what is the blast radius if this role is compromised?”

#110 - Just-In-Time Access Provisioning Agent

Pattern: New build

Platform: AgentCore

Complexity: Strategic Bet

Reference Architecture: N

What the agent does:

Implements just-in-time (JIT) access for elevated permissions.
When an engineer needs production database access for an incident investigation, they request it through the agent.
The agent evaluates the request against context: is there an active incident? Does the requester’s role normally interact with this resource? Is the requested scope proportional to the stated need? What peer approvals are required? For approved requests, provisions time-bounded access (1 hour, 4 hours, configurable per resource type) with the minimum permissions needed.
Automatically revokes access when the window expires or the stated reason resolves.
Logs every request, decision, and access session for audit.
Denies requests that violate policy constraints and explains why.

AWS services: Bedrock (Claude), AgentCore Runtime, AgentCore Policy (approval rules), IAM (temporary credentials), STS (session policies), SSO (permission sets), DynamoDB (request and session state), CloudTrail (session logging), SNS (approvals and notifications)

You need this if: Your engineers have standing access to production systems they rarely need, your audit logs show persistent access being used for brief investigation tasks, and your compliance framework requires time-bounded privileged access but your current process involves Slack messages and manual IAM changes.

Incident Response and Threat Detection

#111 - Security Alert Triage Agent

Pattern: New build

Platform: AgentCore

Complexity: Quick Win

Reference Architecture: O

What the agent does:

Triages the flood of security alerts from GuardDuty, Security Hub, and third-party tools that overwhelm SOC teams.
For each alert, pulls contextual data: the resource involved, its business criticality, recent changes to the resource, the identity that triggered the alert, historical alerts for the same resource or identity, and threat intelligence enrichment.
Classifies each alert as true positive (investigate), false positive (suppress with justification), or informational (log and monitor).
For true positives, assigns severity based on business context (not just the alert’s native severity), identifies the most likely attack stage (reconnaissance, initial access, lateral movement, exfiltration), and routes to the appropriate analyst with a pre-built investigation package.
Tracks suppression patterns to identify when a previously-suppressed alert type starts appearing in new contexts that warrant re-evaluation.

AWS services: Bedrock (Claude), AgentCore Runtime, AgentCore Memory (investigation context), GuardDuty, Security Hub, CloudTrail, VPC Flow Logs, DynamoDB (alert enrichment and suppression rules), SNS (routing)

You need this if: Your SOC receives 500+ alerts daily, analysts spend more time triaging than investigating, false positive rates exceed 70%, and genuine threats get buried in alert noise.

#112 - Incident Timeline Reconstruction Agent

Pattern: New build

Platform: AgentCore

Complexity: Strategic Bet

Reference Architecture: O

What the agent does:

Reconstructs the timeline of a security incident by correlating events across CloudTrail, VPC Flow Logs, application logs, authentication logs, and DNS query logs.
An analyst provides a starting point (a suspicious API call, a compromised credential, a malware detection) and the agent works backward and forward in time to build a complete narrative.
Identifies the initial access vector, lateral movement between resources, data access patterns, and exfiltration indicators.
Produces a structured timeline with timestamps, actors, actions, and affected resources.
Highlights gaps in the timeline where visibility is missing (a period with no CloudTrail events for a known-compromised identity suggests log tampering or activity in an unmonitored account).
Uses AgentCore Memory to maintain investigation state across multiple analysis sessions.

AWS services: Bedrock (Claude), AgentCore Runtime, AgentCore Memory, CloudTrail (event history), CloudWatch Logs Insights, Athena (log querying at scale), VPC Flow Logs, Route 53 DNS logs, S3 (investigation artifacts), DynamoDB (timeline state)

You need this if: Incident investigations take days because analysts manually correlate events across 5+ log sources, critical context gets lost between shift handoffs, and post-incident reports reveal gaps where the team missed lateral movement because they did not check a specific log source.

#113 - Threat Intelligence Correlation Agent

Pattern: New build

Platform: AgentCore

Complexity: Strategic Bet

Reference Architecture: O

What the agent does:

Correlates internal security telemetry with external threat intelligence to identify whether observed activity matches known threat actor tactics, techniques, and procedures (TTPs).
Ingests indicators of compromise (IoCs) from threat feeds, maps them against internal logs (DNS queries matching known-malicious domains, network connections to flagged IPs, file hashes matching known malware), and assesses relevance to your specific environment.
Goes beyond simple IoC matching: analyzes sequences of events that match documented attack patterns from MITRE ATT&CK even when individual IoCs do not trigger.
Produces a daily threat briefing highlighting new intelligence relevant to your technology stack and industry, active threats detected in your environment, and emerging TTPs that your detection rules do not cover.

AWS services: Bedrock (Claude), AgentCore Runtime, GuardDuty (threat detection), Security Hub (finding aggregation), Athena (log analysis at scale), third-party threat intelligence APIs via AgentCore Gateway, S3 (intelligence archive), DynamoDB (correlation state)

You need this if: Your threat intelligence program consists of receiving feed updates that nobody correlates against internal data, your detection rules cover known IoCs but not behavioral patterns, and you lack the analyst capacity to proactively hunt for threats that match new intelligence.

#114 - Automated Containment Agent

Pattern: New build

Platform: Step Functions + AgentCore (hybrid)

Complexity: Foundation Build

Reference Architecture: R

What the agent does:

Executes pre-approved containment actions when security events meet defined severity thresholds.
Step Functions handles the deterministic containment playbook: isolating a compromised EC2 instance (modifying security groups to restrict network access while preserving forensic state), revoking compromised credentials (disabling IAM keys or SSO sessions), blocking malicious IPs (updating WAF rules or network ACLs), and preserving evidence (snapshotting EBS volumes, copying logs to a forensic bucket).
The agent handles the judgment calls within bounded parameters: determining whether the alert severity justifies automated containment, assessing blast radius (will isolating this instance break a production service?), choosing the appropriate containment level (full isolation versus restricted access), and notifying the on-call team with the containment summary and next-steps recommendation.
Every containment action is logged immutably, reversible by design, and constrained by AgentCore Policy to a pre-approved action set exposed through Gateway.

AWS services: Step Functions, Bedrock (Claude), AgentCore Runtime, AgentCore Policy (containment boundaries via Gateway), EC2 APIs (security groups, snapshots), IAM (credential revocation), WAF, Network Firewall, S3 (forensic evidence), CloudTrail, SNS (incident notifications)

You need this if: Your mean time to contain a confirmed threat exceeds 4 hours because containment requires manual intervention, your runbooks exist but are not automated, and after-hours incidents wait until morning because on-call responders are not comfortable executing containment steps manually.

#115 - Vulnerability Prioritization Agent

Pattern: New build

Platform: Both (AgentCore backend + Quick dashboards)

Complexity: Quick Win

Reference Architecture: N + K

What the agent does:

Transforms raw vulnerability scanner output (Amazon Inspector, third-party scanners) into a prioritized remediation queue that reflects actual risk rather than raw CVSS scores.
For each vulnerability, the agent adds business context: Is the affected resource internet-facing or internal-only? Does it process sensitive data? Is there a known exploit in the wild? What compensating controls exist (WAF rules, network segmentation)? For organizations with runtime telemetry or SBOM data, it can additionally assess whether the vulnerable component is loaded in production execution paths.
Recalculates priority based on this contextualized risk and groups vulnerabilities into remediation tickets that can be assigned to the responsible team.
Quick dashboards show vulnerability posture trends, mean-time-to-remediate by team, and SLA compliance.
Tracks whether patching one vulnerability introduces new issues by monitoring for regressions after remediation.

AWS services: Bedrock (Claude), AgentCore Runtime, Amazon Quick (Quick Sight), Amazon Inspector, ECR (container vulnerabilities), Systems Manager Patch Manager, S3 (vulnerability data), DynamoDB (prioritization state and SLA tracking), SNS (escalation)

You need this if: Your vulnerability backlog grows faster than your team can remediate, patching decisions are based on CVSS scores without business context, and your security team cannot answer “what are the 10 most important vulnerabilities to fix this week?”

Regulatory Compliance and Audit

#116 - Regulatory Change Impact Agent

Pattern: New build

Platform: AgentCore

Complexity: Strategic Bet

Reference Architecture: P

What the agent does:

Monitors regulatory and standards body publications for changes that affect your organization.
When a new regulation passes, a standard updates (PCI DSS 4.0, NIST CSF 2.0, ISO 27001:2022), or a regulatory guidance document issues, the agent analyzes the changes against your current control framework.
Produces a gap analysis: which new requirements your existing controls already satisfy, which require new controls, which require modifications to existing controls, and which require further legal interpretation.
Maps each requirement to specific AWS configurations, organizational processes, and documentation that would satisfy it.
Generates a remediation roadmap with relative effort sizing (small, medium, large) based on the type of gap, though accurate effort estimates require validated control mappings and organizational context that the agent uses as inputs rather than infers independently.
Bedrock Knowledge Bases stores the regulatory corpus and your control framework documentation for retrieval during analysis.

AWS services: Bedrock (Claude), AgentCore Runtime, Bedrock Knowledge Bases (regulatory corpus + control framework), S3 (regulatory document archive), DynamoDB (control mapping and gap tracking), SES (stakeholder notifications)

You need this if: Your compliance team learns about regulatory changes from news articles instead of systematic monitoring, gap analyses take weeks of manual review, and you lack a maintained mapping between regulatory requirements and your actual controls.

#117 - Audit Evidence Collection Agent

Pattern: Migration from RPA

Platform: Step Functions + AgentCore (hybrid)

Complexity: Quick Win

Reference Architecture: R

What the agent does:

Automates the evidence collection process for SOC 2, HIPAA, ISO 27001, and PCI DSS audits.
Step Functions orchestrates the collection workflow: pulling screenshots of security configurations, extracting access review records, downloading change management logs, collecting policy documents, and retrieving system configurations.
The agent handles evidence that requires judgment: determining whether a collected artifact actually satisfies the specific control requirement (a screenshot of a security group is not useful evidence if it does not show the specific rules the auditor needs), identifying gaps where evidence is incomplete or stale, and generating the narrative descriptions that accompany each evidence artifact explaining how it demonstrates control effectiveness.
Organizes evidence by control framework, period, and control objective in a structure that maps directly to auditor requests.

AWS services: Step Functions, Bedrock (Claude), AgentCore Runtime, AWS Config (configuration snapshots), CloudTrail (activity evidence), IAM (access review data), S3 (evidence repository with object lock), DynamoDB (evidence catalog and status), SES (collection status notifications)

You need this if: Audit preparation takes your team 4+ weeks of manual evidence collection, you maintain evidence in scattered folders and screenshots, and auditors repeatedly request additional evidence because initial submissions do not precisely match the control being tested.

#118 - Compliance Questionnaire Response Agent

Pattern: Modernization from chatbot

Platform: AgentCore

Complexity: Quick Win

Reference Architecture: P

What the agent does:

Drafts responses to security and compliance questionnaires (vendor assessments, customer security questionnaires, RFP security sections, SIG/CAIQ self-assessments).
Maintains a knowledge base of previously approved responses, current certifications, architectural documentation, and security control descriptions.
For each question, retrieves the most relevant prior approved answer, evaluates whether it is still accurate given current state, and drafts a response.
Flags questions that reference capabilities you do not have, controls that have changed since the last approved response, and areas where the question’s scope is ambiguous.
Produces a draft questionnaire for the security team to review rather than generating final responses autonomously.
Tracks response reuse rates and identifies questions that consistently require manual rework (indicating a gap in the knowledge base).

AWS services: Bedrock (Claude), AgentCore Runtime, Bedrock Knowledge Bases (approved responses + security documentation), S3 (questionnaire archive), DynamoDB (response tracking and reuse metrics)

You need this if: Your security team spends 10+ hours per week responding to customer security questionnaires, the same questions recur across questionnaires with slight wording variations, and response quality is inconsistent because different team members write different answers to the same question.

#119 - Control Testing and Validation Agent

Pattern: New build

Platform: AgentCore

Complexity: Strategic Bet

Reference Architecture: N

What the agent does:

Performs continuous control testing rather than point-in-time audit checks.
For each control in your framework, maintains a test procedure and runs it on a defined schedule.
Tests are not just configuration checks (which AWS Config handles natively) but operational effectiveness tests: Does the incident response process actually trigger within the defined SLA? Does the change management approval workflow enforce separation of duties in practice? Do access revocations propagate within the required timeframe? The agent simulates control scenarios (creating test events, measuring response times, verifying workflow execution) within safe test boundaries defined by AgentCore Policy via Gateway-exposed tools.
Produces a continuous control effectiveness report showing which controls are operating effectively, which are degraded, and which have failed their most recent test.

AWS services: Bedrock (Claude), AgentCore Runtime, AgentCore Policy (test boundaries via Gateway), Step Functions (test orchestration), CloudWatch (SLA measurement), Config (configuration state), CloudTrail (process verification), S3 (test results), DynamoDB (control registry and test schedule)

You need this if: You only discover that a control is ineffective during the annual audit, your control testing is limited to checking configurations rather than verifying operational effectiveness, and you cannot demonstrate continuous compliance between audit periods.

#120 - Privacy and Data Protection Compliance Agent

Pattern: New build

Platform: AgentCore

Complexity: Foundation Build

Reference Architecture: N

What the agent does:

Monitors and enforces data protection requirements across GDPR, CCPA, HIPAA, and other privacy regulations.
Tracks data processing activities against the organization’s Record of Processing Activities (ROPA).
Monitors data flows for transfers that might violate cross-border transfer restrictions.
Detects new data collection or processing activities that lack proper legal basis documentation.
When a data subject submits an access request (DSAR) or deletion request, maps all systems where that individual’s data resides and generates a response package showing what data exists and where.
Validates that data retention policies are actually being enforced by checking for data older than its defined retention period.
Produces a privacy posture report showing compliance status by regulation, processing activity, and data category.

AWS services: Bedrock (Claude), AgentCore Runtime, AgentCore Policy (data access boundaries), Amazon Macie (PII discovery), Glue Data Catalog (data classification), S3 (ROPA and evidence), DynamoDB (processing activity registry, DSAR tracking), EventBridge (retention monitoring)

You need this if: Your privacy team maintains the ROPA in a spreadsheet that is perpetually outdated, DSAR responses take weeks because nobody knows all the systems where a person’s data lives, and you cannot prove that data retention policies are enforced rather than merely documented.

Security Operations and Posture Management

#121 - Security Posture Scoring Agent

Pattern: New build

Platform: Both (AgentCore backend + Quick dashboards)

Complexity: Quick Win

Reference Architecture: N + K

What the agent does:

Calculates and tracks a composite security posture score across the organization, breaking it down by account, team, service, and compliance framework.
Aggregates inputs from Security Hub findings, Config compliance, vulnerability scan results, IAM analysis, encryption status, and logging coverage into a weighted score that reflects actual risk posture.
The scoring model is configurable: different controls carry different weights based on your organization’s threat model and regulatory requirements.
Tracks score trends over time to show whether security posture is improving or degrading.
Identifies which specific findings have the largest impact on the score (fixing one critical IAM finding might improve the score more than fixing ten low-severity configuration issues).
Quick dashboards provide executive, team-level, and technical views of the same underlying data.

AWS services: Bedrock (Claude), AgentCore Runtime, Amazon Quick (Quick Sight), Security Hub (finding aggregation), AWS Config, Amazon Inspector, S3 (score history), DynamoDB (scoring model and weights), EventBridge (scoring schedule)

You need this if: Your CISO cannot answer “is our security posture better or worse than last quarter?” with data, security improvement efforts lack clear metrics, and team accountability for security is impossible without per-team visibility.

#122 - Third-Party Risk Assessment Agent

Pattern: New build

Platform: AgentCore

Complexity: Strategic Bet

Reference Architecture: P

What the agent does:

Manages the vendor security assessment lifecycle.
When a new vendor enters procurement or an existing vendor reaches its reassessment date, the agent collects their security documentation (SOC 2 reports, penetration test summaries, compliance certifications, security questionnaire responses).
Analyzes the documentation against your organization’s third-party risk requirements.
Identifies gaps between your requirements and the vendor’s demonstrated controls.
Assesses residual risk for each gap and recommends risk acceptance, contractual mitigation, or technical controls to compensate.
Tracks vendor risk scores over time, flags vendors whose certifications expire, and triggers reassessments based on risk tier and time since last review.
Correlates vendor risk levels with the data and access each vendor has to prioritize which assessments matter most.

AWS services: Bedrock (Claude), AgentCore Runtime, Bedrock Knowledge Bases (vendor documentation corpus + risk framework), S3 (vendor documentation archive), DynamoDB (vendor inventory, risk scores, assessment schedule), SES (vendor communications and internal notifications), EventBridge (assessment triggers)

You need this if: Your third-party risk program is backlogged by 6+ months, vendor assessments are inconsistent in depth depending on who performs them, and you cannot answer “which of our vendors with access to customer data have not been assessed in the last year?”

#123 - Security Runbook Automation Agent

Pattern: Migration from RPA

Platform: Step Functions + AgentCore (hybrid)

Complexity: Quick Win

Reference Architecture: R

What the agent does:

Executes security operational runbooks that currently require analysts to follow manual steps.
Step Functions handles the deterministic procedural steps: collecting data from specified sources, executing API calls in sequence, and routing outputs to designated destinations.
The agent handles the judgment steps within each runbook: interpreting the results of diagnostic commands, deciding which branch of the procedure applies based on the situation, and determining when the runbook’s scope has been exceeded and human intervention is needed.
Covers common security operations: investigating a failed login surge, triaging an unauthorized API call, assessing a new GuardDuty finding type, and performing routine security hygiene checks.
Each runbook is version-controlled with clear scope boundaries, pre-approved actions, and defined escalation criteria.

AWS services: Step Functions, Bedrock (Claude), AgentCore Runtime, AgentCore Policy (action boundaries per runbook via Gateway), CloudTrail, GuardDuty, IAM APIs, CloudWatch Logs, S3 (runbook definitions and execution logs), DynamoDB (execution state), SNS (escalation)

You need this if: Your security runbooks exist as wiki pages that analysts follow manually, execution consistency varies by analyst, after-hours incidents wait because junior analysts are not comfortable executing advanced runbooks, and you want to reduce mean time to respond without reducing investigation quality.

#124 - Cloud Cost and Security Trade-off Agent

Pattern: New build

Platform: Both (AgentCore backend + Quick dashboards)

Complexity: Strategic Bet

Reference Architecture: N + K

What the agent does:

Evaluates the cost implications of security decisions and the security implications of cost optimization recommendations.
When a FinOps tool recommends downgrading a Reserved Instance or consolidating workloads, the agent assesses whether the change affects security posture (moving workloads into a shared account might violate isolation requirements, downgrading a WAF tier might remove protections).
When the security team recommends enabling additional logging, encryption, or network segmentation, the agent estimates the cost impact with specificity: “Enabling VPC Flow Logs across all production VPCs will add approximately $2,400/month based on current traffic volumes.” Bridges the gap between security teams that recommend controls without cost awareness and finance teams that cut costs without security awareness.
Quick dashboards show the security cost of each compliance framework and the cost savings available at each risk tolerance level.

AWS services: Bedrock (Claude), AgentCore Runtime, Amazon Quick (Quick Sight), Cost Explorer, Security Hub, AWS Config, Pricing API, S3 (analysis reports), DynamoDB (trade-off registry)

You need this if: Security and finance teams operate in silos, cost optimizations occasionally degrade security posture without anyone noticing, and security recommendations get rejected for budget reasons without quantified risk-versus-cost analysis.

#125 - Compliance Communication and Reporting Agent

Pattern: New build

Platform: Both (AgentCore backend + Quick dashboards)

Complexity: Quick Win

Reference Architecture: N + K

What the agent does:

Generates compliance status reports for different audiences from the same underlying data.
The board receives a one-page risk summary with trend arrows and material findings requiring attention.
The CISO receives a detailed posture report with metrics, open findings by severity, remediation velocity, and control effectiveness trends.
Engineering teams receive their team-specific findings with remediation guidance and SLA status.
Regulators receive the specific evidence and attestations their framework requires.
The agent pulls from the same compliance data (Security Hub findings, Config evaluations, audit evidence, control test results) and formats for each audience’s information needs and technical depth.
Operates on a schedule for recurring reports and on-demand for ad hoc requests.
Quick dashboards provide the interactive exploration layer behind each report.

AWS services: Bedrock (Claude), AgentCore Runtime, Amazon Quick (Quick Sight), Security Hub, AWS Config, S3 (report archive), DynamoDB (report templates and distribution lists), EventBridge (reporting schedule), SES (report distribution)

You need this if: Your compliance team produces reports manually for different stakeholders, each report takes hours to compile, and different audiences receive the same level of detail regardless of whether they need a board summary or an engineering action list.

What These 25 Patterns Reveal

The trust model separates this edition from the previous four.

Every pattern in this edition operates under the principle that agent recommendations require human validation before becoming organizational decisions.

Customer support agents can auto-resolve tickets because a wrong answer affects one customer.

Compliance agents produce findings that affect audit outcomes, regulatory standing, and organizational risk posture.

The human-in-the-loop is a feature, not a limitation.

AgentCore Policy carries more weight here than in any other edition.

Fifteen patterns explicitly reference AgentCore Policy for constraining agent actions routed through Gateway.

In earlier editions, policy prevents the agent from doing something unexpected. In this edition, policy enforcement is itself a compliance requirement - demonstrating that the AI system operates within defined boundaries is part of the control framework.

The Cedar-based authorization model, generated from natural-language policy definitions and validated for safety conditions, produces an auditable record of what tool interactions the agent was authorized to perform.

For actions not routed through Gateway, standard IAM policies and application-level controls provide the enforcement boundary.

Both layers feed into audit evidence.

Evidence preservation is an architectural concern, not an operational one.

Nine patterns include an immutable evidence store (S3 with object lock or equivalent). This is not logging for debugging.

This is evidence for auditors that the system operated as designed.

The decision to use object lock with compliance mode versus governance mode, the retention period configuration, and the evidence catalog structure are design decisions that affect audit outcomes years after the agent runs.

The hybrid Step Functions + AgentCore pattern from Edition 3 reappears heavily. Five patterns use the hybrid approach.

Compliance workflows have significant deterministic components (collecting evidence from APIs, running scheduled checks, executing remediation playbooks) mixed with judgment components (interpreting findings, assessing severity, generating recommendations).

The hybrid approach keeps the deterministic parts auditable through Step Functions’ visual execution history while reserving the agent for reasoning steps.

Quick Wins cluster around reporting and analysis rather than automated action.

The ten Quick Win patterns (#101, #103, #106, #111, #115, #117, #118, #121, #123, #125) focus on analyzing existing data and generating insights rather than taking autonomous actions.

This reflects the trust boundary: starting with agents that help humans understand compliance posture is lower risk than agents that autonomously remediate findings.

The Strategic Bets and Foundation Builds introduce more automation as the organization builds confidence in agent accuracy and appropriate scoping.

Multi-agent architectures appear only for complex investigations.

Architecture Q shows up when an investigation spans multiple security domains (configuration, logs, policies, threat intelligence) and a single agent’s context window cannot hold all the relevant data.

Most compliance workloads are well-served by a single focused agent with the right tools.

125 Patterns Across Five Editions

This series cataloged 125 AI agent architectures across five domains: customer-facing service, internal productivity, workflow automation, data analytics, and compliance.

A few observations span all 125.

The platform choice follows the workload, not the hype cycle.

AgentCore dominates when the agent needs custom tool orchestration, multi-step reasoning, or fine-grained policy control.

Quick dominates when business users need self-service analytics or visualization.

Q Business dominates for enterprise knowledge retrieval with permission awareness. Step Functions handles deterministic workflows.

The agents that perform best in production use the simplest platform that meets their requirements, not the most architecturally impressive option.

Start with the agent that solves the pain you already measure.

The strongest implementations across all five editions share one trait: the team could quantify the problem before building the solution.

Hours spent triaging alerts, days spent collecting audit evidence, weeks spent waiting for analytics requests.

If you cannot measure the current cost, you cannot demonstrate the agent’s value after deployment.

Build the evidence layer before the reasoning layer. Agents are only as good as the data they can access. Knowledge bases, metadata catalogs, semantic layers, tool integrations, and policy definitions are the foundation that makes agent reasoning reliable.

Organizations that skip these prerequisites and build the agent first discover that their sophisticated reasoning engine produces unreliable outputs because the inputs are incomplete or incorrect.

Governance scales with autonomy.

A read-only agent that generates reports needs lightweight oversight. An agent that auto-remediates security findings needs comprehensive policy enforcement, audit trails, and bounded action sets.

The governance investment should be proportional to the agent’s ability to affect the organization.

Every edition in this series shows the progression: Quick Wins start with analysis, Strategic Bets add bounded actions, and Foundation Builds implement the governance infrastructure that enables broader autonomy later.

The 125 patterns exist so your next architecture discussion starts from a reference point rather than a blank whiteboard.

Pick the card that matches your problem, adapt the architecture to your environment, and build from there.

I publish every week at buildwithaws.substack.com. Subscribe. It's free.