AWS Bedrock abuse reveals the hidden NHI attack surface

At a glance

What this is: This article shows how stolen AWS credentials can be used against Bedrock to enable model access, suppress logging, enumerate assets, and generate inference abuse without exploiting the model itself.

Why it matters: It matters because identity teams need to govern the credentials and control plane behind GenAI services, not just the model layer, or Bedrock abuse will look like legitimate use until the damage is already underway.

Context

AWS Bedrock abuse is not a model compromise problem first. It is a cloud identity and control-plane problem in which valid credentials can be used to enable access, enumerate models, tamper with logging, and run inference at scale.

The article’s core point is that CloudTrail and CloudWatch each expose only part of the sequence. That makes Bedrock a governance blind spot for NHI programmes that still assume authentication alone is enough to establish trust.

When a single long-lived key can unlock hosted foundation models, the control question shifts from model security to NHI lifecycle, logging integrity, and platform-level guardrails. That is the right frame for IAM, PAM, and cloud security teams.

Key questions

Q: What breaks when Bedrock access is governed only by valid cloud credentials?

A: The assumption that authentication equals trust breaks immediately. A valid IAM key can still be stolen, resold, or reused to enable models, enumerate assets, and run inference at scale. That is why Bedrock access needs NHI lifecycle controls, not just successful login events.

Q: Why do stolen Bedrock credentials create such a large security impact?

A: Because the credential can reach both control-plane and runtime actions. One key may enable models, invoke expensive foundation models, touch knowledge bases, and tamper with logging, so the damage follows the identity’s reach rather than the model’s own security posture.

Q: How do teams know if Bedrock logging is failing them?

A: Look for mismatches between positive invocation activity and missing or degraded model invocation logs. If CloudTrail shows Bedrock use while CloudWatch delivery drops to zero, visibility is being reduced, redirected, or disabled, and the detection model is no longer complete.

Q: Should security teams prioritise CloudTrail or CloudWatch for Bedrock abuse detection?

A: Neither source is sufficient on its own. CloudTrail is stronger for identity and control-plane actions, while CloudWatch is stronger for prompts, responses, and token usage. The correct approach is to correlate both so the same identity, action chain, and content can be evaluated together.

Technical breakdown

Why Bedrock abuse starts with valid credentials

Bedrock abuse does not require prompt injection or a model jailbreak to begin. An attacker who gets a valid IAM key or assumed role can call Bedrock control-plane APIs, enable model access, enumerate models, and then issue inference requests through the same identity. The important technical point is that AWS management events capture who called the API, from where, and when, but not the prompt body. That makes identity provenance visible while leaving the payload invisible unless model invocation logging is enabled. In practice, the attacker is using ordinary cloud authentication paths to reach GenAI infrastructure as if they were an authorised workload.

Practical implication: Treat Bedrock access as a governed NHI path and restrict who can obtain, use, or enable model credentials.

Why CloudTrail and CloudWatch each miss part of the attack

CloudTrail and CloudWatch are complementary, not interchangeable. CloudTrail records management activity such as InvokeModel, ListFoundationModels, and logging configuration changes, but it does not show prompts or outputs. CloudWatch model invocation logs capture the content, token counts, and model response, but they do not preserve the original network identity in the same way. That split is why Bedrock abuse can hide in plain sight when defenders rely on only one telemetry source. The attacker can also tamper with logging before scaling up usage, which breaks the assumption that a single log stream will show both identity and intent.

Practical implication: Correlate control-plane and invocation telemetry, and alert on any change that reduces visibility into Bedrock activity.

How LLMjacking progresses from enablement to scale

The attack sequence in the article is methodical. First, the attacker enables or confirms model access. Next, they probe credentials, enumerate available models, and verify that the key works. Then they run inference at scale, often across regions, while using proxy tooling or logging changes to reduce detection. This is operationally closer to credential abuse and platform misuse than to a classic application exploit. The control lesson is that a valid identity can be the attack vector even when the model and its prompts remain uncompromised. The abuse window begins at credential exposure and expands through control-plane actions.

Practical implication: Detect chained Bedrock phases from one identity within a short window and treat that sequence as suspicious rather than isolated API noise.

Threat narrative

Attacker objective: The attacker wants to monetise stolen Bedrock access, hide their activity, and use an authorised identity to extract value from GenAI infrastructure without breaking the model itself.

1. Entry occurs when an attacker obtains a long-lived IAM access key, exposed .env credentials, compromised CI secrets, or other stolen cloud credentials.
2. The attacker then confirms access, enumerates available Bedrock models, and probes InvokeModel or related APIs to verify that the credentials are valid.
3. They suppress visibility by deleting or redirecting model invocation logging, then run inference at scale across regions or through proxy tooling.
4. The impact is unauthorised model consumption, hidden prompt and response abuse, and potential exfiltration or manipulation of data exposed through hosted agents and knowledge bases.

Breaches seen in the wild

• 230M AWS environment compromise: 230M AWS environments compromised via exposed .env files with cloud credentials.
• Amazon AWS Hacked Accounts Crypto-Mining: Compromised IAM credentials across multiple AWS accounts fuel large-scale crypto-mining campaign.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Bedrock abuse exposes an identity-layer problem, not a model-layer problem: The decisive control issue is whether a valid cloud credential can be trusted to use GenAI infrastructure without tighter lifecycle and context controls. Bedrock abuse works because the platform accepts legitimate identities before the organisation has verified that those identities are still governed, intended, or safe. The practitioner conclusion is that GenAI access must be managed as NHI access, not as an isolated application permission.

CloudTrail visibility without invocation content creates a false sense of coverage: Management-plane logs can show model enablement, enumeration, and logging changes, but they cannot reconstruct the prompt or the business intent behind the call. CloudWatch fills part of that gap, yet it also depends on logging being enabled and unmodified. The governance failure is assuming one telemetry source can prove both identity legitimacy and usage legitimacy. The practitioner conclusion is to design detection around correlated evidence, not single-source certainty.

Long-lived cloud keys create hidden trust debt for GenAI services: Long-lived secrets were designed for stable service access, not for rapidly changing AI usage patterns that can be repurposed across regions and proxy layers in minutes. That assumption fails when a Bedrock credential can be copied, sold, and reused without the original owner’s awareness. The implication is that NHI governance must reclassify these credentials as high-blast-radius assets, with stronger issuance, restriction, and revocation discipline.

Logging tamperability is part of the attack surface: If an attacker can disable, redirect, or selectively blind Bedrock invocation logging, they are not just hiding evidence, they are reshaping the detection model itself. That means logging configuration belongs inside the privileged control boundary, not outside it as an afterthought. The practitioner conclusion is that log integrity for AI platforms needs explicit governance, not optimistic default trust.

Identity blast radius is the right concept for Bedrock governance: One credential can unlock model access, invoke expensive inference, touch knowledge bases, and alter observability. That is a much larger operational blast radius than many teams assign to a single service account or IAM user. The practitioner conclusion is to measure GenAI access by what the identity can reach, not by whether authentication succeeded.

What this signals

Bedrock governance should now be treated as an NHI control problem: The practical risk is not whether a model can be tricked, but whether a stolen or over-permissioned identity can walk the control plane, disable observability, and consume inference at scale. Teams that still separate GenAI oversight from IAM will miss the real failure mode.

Detection has to move from single events to chained behaviour: One model call is noisy; a sequence of model enablement, enumeration, probing, and cross-region invocation from the same identity is not. That pattern should drive correlation rules, containment playbooks, and account-level guardrails around Bedrock.

Logging integrity is part of identity assurance: If an attacker can tamper with invocation logging, the organisation loses both forensic depth and behavioural context. Practitioners should treat log configuration, delivery health, and access to logging changes as privileged assets in the same way they treat credential stores.

For practitioners

• Enforce short-lived credentials for Bedrock access Replace long-lived IAM keys with temporary role credentials wherever Bedrock is used, and remove direct use of static access keys from GenAI workflows.
• Lock down model enablement and logging controls Restrict PutUseCaseForModelAccess, CreateFoundationModelAgreement, DeleteModelInvocationLoggingConfiguration, and PutModelInvocationLoggingConfiguration to a narrowly approved change role.
• Correlate identity and content telemetry Join CloudTrail management events with CloudWatch invocation logs so model enablement, enumeration, prompt content, and response volume are analysed in one detection path.
• Alert on chained Bedrock phases from one identity Trigger on sequences such as ListFoundationModels, ValidationException, and InvokeModel within a short window from the same access key or assumed role.
• Protect log delivery as a control objective Monitor for ModelInvocationLogsCloudWatchDeliverySuccess dropping to zero while invocations remain positive, because that pattern indicates visibility tampering or redirected logging.

Key takeaways

• Bedrock abuse shows that valid cloud credentials can be turned into GenAI access, model enumeration, and logging tampering without defeating the model itself.
• The article’s detection logic depends on correlating control-plane events with invocation logs because neither source is complete in isolation.
• The most effective limiting control is not model hardening alone, but tighter NHI governance over long-lived keys, logging changes, and access scope.

Key terms

• LLMjacking: Abuse of cloud AI services through stolen machine credentials rather than human user accounts. The attacker uses valid non-human identities such as API keys or tokens to enumerate model access, invoke endpoints, and create cost, data, or policy exposure under the victim's tenancy.
• CloudTrail Data Event: A CloudTrail data event records service activity such as model invocations, agent actions, and object-level changes rather than broad control-plane administration. For AI services, it is often the only practical way to reconstruct what an identity actually did inside a workspace.
• Model invocation logging: Model invocation logging captures prompts, responses, token counts, and model metadata for AI calls. For Bedrock-style services, it is the only place where content is visible, which makes it essential for detection, cost analysis, and abuse investigation when paired with identity logs.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.