Beyond the Frontier Agent: A Defense-in-Depth AWS Security Architecture for MSPs

Security Agent is the newest layer, not the only one. This article covers the AWS-native services an MSP still needs underneath it, and how to price the whole stack by client tier.

A single agent, however capable, is not a security practice — it is a layer. AWS Security Agent covers the application layer: design, code, and runtime exploitability. Everything below that — account posture, network perimeter, and cross-account threat correlation — still runs on the AWS-native security services that predate the agentic wave and remain the actual foundation an MSP builds on.

1. The Three Layers Below the Agent

Perimeter. AWS WAF now sits in front of Amazon Bedrock AgentCore Gateway, which matters the moment your own practice starts running agent workloads on behalf of clients — the agent’s tool-calling interface is itself a surface that needs the same perimeter controls as any public endpoint.

Detection and posture. GuardDuty for continuous threat detection across accounts, workloads, and EKS runtime; Security Hub aggregating findings into one view; Security Lake normalizing that data into OCSF format for long-term correlation and, increasingly, for feeding third-party detection signals (Check Point, Zscaler, Rubrik, Netskope, and SentinelOne integrations were added to AgentCore-adjacent workflows in 2026); Config and IAM Access Analyzer for continuous posture and least-privilege drift detection.

Application. Security Agent, covered in depth in Article 1, sitting atop all of the above.

Figure 2. Four layers, one architecture — the SI partner’s actual deliverable.
Technical deep-dive — the correlation that makes four layers act as one architecture. The layering only pays off commercially if findings cross layer boundaries, not just sit side by side in four separate consoles. Security Lake normalizes GuardDuty, Config, and Security Hub findings into OCSF (Open Cybersecurity Schema Framework), and Security Agent’s application-layer findings are tagged with the same account and resource identifiers used across that OCSF data. A practical example: GuardDuty raises a low-confidence finding on unusual API call volume from an EC2 instance role; independently, Security Agent’s code-review checkpoint had flagged that the same role is attached to a service with a known input-validation gap. Correlated on the shared resource ARN, that becomes one incident timeline instead of two disconnected alerts in two different tools — the difference between an analyst noticing a pattern by luck and a SOC seeing it by design.

2. Why the Layering Matters Commercially

Selling Security Agent alone invites an obvious client question: what happens to an attacker who never touches the application layer at all — a leaked credential, a misconfigured S3 bucket, a compromised third-party integration? The honest answer is that Security Agent does not see any of that; it is scoped to application security. An MSP that sells only the agent is selling a partial answer to a full-estate problem, and a technically literate buyer will notice.

The correct commercial framing is the full stack: perimeter, detection, posture, and application, packaged as one managed offering with Security Agent as the newest and most visible component — not the whole product.

3. Tiering the Practice

Enterprise — custom SOC integration: Security Lake feeding the client’s existing SIEM or a dedicated tenancy, GuardDuty and Security Hub findings correlated against Security Agent’s application-layer findings for a single incident timeline.

SMB — a managed baseline across GuardDuty, Security Hub, and Config, with Security Agent’s managed-cadence tier from Article 1 layered on top. This is the volume tier: standardized, not customized.

DNB — self-serve API-first guardrails: Config rules and IAM Access Analyzer findings exposed via API for the client’s own platform team to consume, with the partner’s value concentrated in guardrail design and quarterly review rather than day-to-day operation.

What changes for the SI partner

The pitch stops being “we run your SOC” and becomes “we run the four-layer stack, and the layer you can see — Security Agent’s pentest reports and remediation PRs — is backed by three layers you don’t have to think about.” That framing sells the agent and the foundation as one motion instead of two separate line items competing for the same budget line.

Business Value Mapping

Technical capabilityBusiness outcomeMetric / KPIPrimary stakeholder
WAF in front of AgentCore GatewayAgent tool-calling surface does not become an unguarded attack vectorBlocked malicious requests per monthCISO
GuardDuty + Security Hub + Security Lake correlationOne incident timeline instead of four disconnected consolesMean time-to-correlate an incidentSOC lead
Config + IAM Access Analyzer continuous posture checksDrift caught before it becomes an exploitable gapDays of posture drift before remediationCloud security architect
Application-layer findings tagged to shared resource identityCross-layer correlation instead of siloed alerts% of incidents correlated across >1 layerCISO
Four-layer stack sold as one managed offeringSingle retainer replaces multiple point-tool contractsNet revenue per client vs. point-solution pricingPartner CRO / sales

An agent is a capability. A defense-in-depth architecture is what a client is actually buying when they sign a security retainer.

Sources: AWS Security Agent GA (AWS What’s New, March 2026) · AWS WAF adds support for Amazon Bedrock AgentCore Gateway (AWS What’s New, June 2026) · Amazon Bedrock AgentCore Policy and third-party detection integrations (AWS re:Invent 2025 announcements)

We are now live on AWS Marketplace.
The integrated view of your cloud infrastructure is now easier than ever!