What GuardDuty and Defender for Cloud Are Built to Detect
GuardDuty generates findings by analyzing VPC Flow Logs, DNS query logs, CloudTrail management and data events, S3 data events, and EKS audit logs, applying machine learning and curated threat intelligence to flag unauthorized or malicious activity. Its findings are organized around AWS resource categories such as EC2, S3, IAM, EKS, Lambda, and RDS. Runtime Monitoring and Malware Protection extend this to OS and process-level signals on EC2, ECS, and EKS workloads. Defender for Cloud combines Cloud Security Posture Management and Cloud Workload Protection Platform capabilities, ingesting Azure Activity Logs, Azure AD/Entra ID sign-in data, and Defender for Endpoint telemetry, with protection plans structured around resource types including virtual machines, storage, databases, Kubernetes, and APIs. Both platforms are mature, well-documented systems, and both were designed before autonomous AI agents became a distinct workload category in enterprise environments.
Why Agent Tool-Calls Fall Outside This Scope
The detection logic in both platforms operates on infrastructure and control-plane telemetry: it can confirm that an API call occurred, which principal made it, and whether the network pattern looks anomalous relative to a baseline. It does not parse the semantic content of that call. When an AI agent invokes a tool through the Model Context Protocol, an open protocol for connecting models to external tools and data sources, the resulting traffic may appear as a routine API request or container process to the underlying cloud platform. Neither GuardDuty nor Defender for Cloud publishes support for inspecting MCP message payloads, tool schemas, or agent-to-agent delegation events. Defender for APIs, for example, focuses on endpoint discovery, exposure, and posture rather than the intent behind an individual invocation. This is not a missing feature so much as a boundary of what these systems were built to observe: infrastructure behavior, not application-layer reasoning.
Coverage Comparison
The table below summarizes what each layer is designed to observe, from cloud-native detection through application-layer agent governance.
| Detection Layer | Primary Focus | Scope |
|---|---|---|
| GuardDuty | AWS control-plane and network telemetry with ML-based anomaly detection | Resource-scoped findings (EC2, S3, IAM, EKS, Lambda, RDS) |
| Defender for Cloud | CSPM and CWPP across Azure, AWS, and GCP resources | Identity and endpoint signal ingestion |
| Trussed AI | Application-layer governance of agent identity and tool calls | MCP interactions and runtime policy enforcement |
Identity Anomaly Detection: Static Baselines vs Dynamic Agents
Both platforms model identity anomalies using detection logic built for human users, IAM roles, or service principals with relatively stable behavioral baselines. This works reasonably well when a service account performs a predictable set of actions over time. Autonomous agents complicate this model because they can legitimately vary tool sequences, chain multiple actions, and adjust permissions dynamically based on task context. A sequence of API calls that would trigger a baseline-deviation alert for a static service account may be entirely normal for an agent working through a multi-step task, and conversely, an over-provisioned agent identity performing within its granted scope may never trigger any anomaly signal at all, because the anomaly detection does not evaluate whether that scope was appropriate in the first place.
Where Runtime Governance Fits in the Stack
Agent runtime governance operates at the orchestration layer, where tool calls, prompts, and agent identities are defined, rather than at the infrastructure layer where GuardDuty and Defender for Cloud sit. This is a different control point: cloud-native tools generate findings for security teams to triage after an event has occurred, while runtime governance is positioned to enforce policy inline, at the moment a tool call is made. Trussed AI's runtime governance model addresses this by defining agent identity as a distinct class separate from the IAM role or service principal that provisions it, applying least-privilege policy at the tool and action level, and logging tool-call decisions as a discrete audit artifact. This does not replace GuardDuty or Defender for Cloud. It sits alongside them, typically integrated through log export, an API gateway, or a proxy layer, since neither cloud-native platform natively correlates with application-layer agent governance.