c3.8 Detect threats against your AI runtime
Generative-AI services are now attack targets — LLMjacking with stolen credentials, anomalous model invocations, prompt injection, and tampering with logging or guardrails. Being aligned means these runtime threats are actually detected and routed to response, primarily by enabling Amazon GuardDuty AI Protection.
Implementation guidance
Why the AI runtime is a target
Attackers who obtain AWS credentials increasingly pivot to Amazon Bedrock and Amazon SageMaker to abuse model inference ("LLMjacking" — running up large inference bills or reselling access), exfiltrate data, or tamper with models and their logging. Detecting this needs runtime signals from the AI control plane and data plane, not just build-time checks.
Enable GuardDuty AI Protection (the primary control)
Amazon GuardDuty AI Protection is the managed way to get this coverage. When enabled, GuardDuty automatically analyzes AWS CloudTrail data events from Amazon Bedrock, Bedrock AgentCore, and SageMaker AI (it creates a service-linked channel for you — no trail to set up) and detects:
- Anomalous model invocations — calls that deviate from the identity's or account's baseline (unusual IP, API, or model).
- Cost harvesting (LLMjacking) — computationally expensive inputs inflating token consumption and cost.
- Direct prompt injection — malicious prompts that try to override a model's instructions. This detection requires Amazon Bedrock Guardrails; enforce prompt-attack guardrails org-wide via AWS Organizations Bedrock policies.
The GuardDuty Foundational plan adds detections from management events — unusual removal of Bedrock guardrails, training-data-source changes (data poisoning), disabled model-invocation logging (evasion), and exfiltrated EC2 credentials calling Bedrock/SageMaker — and Lambda Protection helps detect threats in Bedrock agents.
Route detections to response
Detection only matters if someone acts. Send AI Protection findings into your act-on-findings workflow and SIEM / Security Lake, and make sure your incident-response playbooks cover a compromised AI workload (for example, revoke the identity, disable the affected key, and review invocation logs).
Go deeper with the AI Security Maturity Model
This is a Cloud control covering the runtime-detection basics for AI. Because securing AI at depth is its own discipline, use the dedicated AI Security Maturity Model for the full journey across the AI attack surface.
How to validate
- Is Amazon GuardDuty AI Protection enabled across all accounts and Regions where Bedrock/SageMaker run?
- Are Bedrock Guardrails enforced org-wide so direct-prompt-injection detection works?
- Is the GuardDuty Foundational plan on to catch guardrail removal, disabled logging, training-data changes, and exfiltrated credentials used against AI services?
- Are AI Protection findings routed into your act-on-findings workflow / SIEM, with alerting on anomalous invocations and cost spikes?
- Do your incident-response playbooks cover a compromised AI workload?
Threats addressed
- Stolen credentials can be used for LLMjacking — running expensive model inference on your account — driving up cost and potentially exfiltrating prompt or training data.
- Attackers can disable model-invocation logging or remove guardrails to evade detection, and can poison training data; without runtime detection these actions go unseen until they appear on the bill or as a breach.
AWS services
Amazon GuardDuty 
Amazon Bedrock 
Amazon SageMaker Pricing
Amazon GuardDuty AI protection is billed on the volume of CloudTrail data events analyzed (GB); the service-linked channel adds no separate CloudTrail charge. See Amazon GuardDuty pricing.