AWS Bedrock abuse reveals the hidden NHI attack surface

At a glance

What this is: This analysis shows how attackers abuse valid AWS credentials to hijack Bedrock workloads, hide their activity, and monetise model access without breaking the model itself.

Why it matters: It matters because IAM, PAM, and NHI teams need to treat hosted AI platforms as credentialed infrastructure, not just application endpoints, or abuse will bypass traditional detection assumptions.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.

👉 Read Abstract Security's analysis of Bedrock abuse, LLMjacking, and detection

Context

AWS Bedrock is a useful example of how AI security problems often start as identity problems. If an attacker gets valid cloud credentials, they do not need a model exploit to cause damage; they can invoke models, query knowledge bases, tamper with logging, or enumerate custom model access through normal APIs.

For IAM and NHI teams, the important distinction is between the model and the control plane around it. The article argues that CloudTrail and CloudWatch each expose only part of the picture, so practical detection depends on correlating identity, logging, and invocation data rather than treating Bedrock as a single telemetry source.

Key questions

Q: How should security teams detect Bedrock credential abuse in cloud environments?

A: Correlate CloudTrail identity events with Bedrock invocation logs, then look for short bursts that combine model enumeration, validation failures, and inference calls from the same principal. Add a separate alert for changes to invocation logging configuration, because attackers often try to blind telemetry before scaling abuse.

Q: Why do valid AWS credentials create such a large Bedrock abuse risk?

A: Because they unlock the control plane, not just the application. A compromised key can enable model access, invoke inference, and sometimes alter logging or guardrail settings, which means one identity can produce billing abuse, data exposure, and evidence suppression without exploiting the model itself.

Q: What breaks when Bedrock logging is disabled or redirected?

A: Defenders lose the content needed to understand what was asked, what was returned, and how much the attacker consumed. CloudTrail still shows API metadata, but that is not enough to distinguish routine use from abuse at scale, especially when the attacker uses proxy tooling or multi-region calls.

Q: Who should be accountable for AI workload credentials and lifecycle controls?

A: Accountability should sit with the teams that own the business process and the identity controls together, not with security alone. The identity owner needs to be able to answer why the credential exists, when it must expire, and what happens if it is misused. That is the standard boards should expect for non-human access.

Technical breakdown

Why Bedrock abuse starts with valid AWS identity

LLMjacking is theft of hosted model access, not compromise of the model weights themselves. In Bedrock, a long-lived IAM key can unlock the control plane that grants model access, invokes foundation models, and reaches connected agents or knowledge bases. That means the attacker’s first requirement is usually a working cloud identity, often a leaked access key, compromised CI secret, or stolen local credential. Once inside, the attacker can move from access validation to model discovery and then to high-volume inference. The technical risk is therefore credential reach, not model fragility.

Practical implication: reduce the lifetime and scope of cloud identities that can invoke Bedrock or modify its logging and model access settings.

Why CloudTrail and CloudWatch each see only half the attack

CloudTrail records who called Bedrock, from where, and when, but not the prompt or response content. CloudWatch model invocation logs capture prompt and output content, plus token counts and model details, but they abstract away the original network identity. That split creates a detection gap if teams rely on only one source. An attacker can confirm credential validity with malformed requests, enumerate models, and then switch to high-volume inference while the observability stack remains fragmented. In practice, the control problem is not missing logs, but incomplete correlation across identity and content telemetry.

Practical implication: join CloudTrail and Bedrock invocation logs on identity and time window so model abuse cannot hide behind single-source monitoring.

How logging tampering and model abuse reinforce each other

The article shows a broader pattern than simple model invocation. Attackers may first inspect whether invocation logging is enabled, then disable it or redirect it before any large-scale abuse begins. That sequence turns the logging configuration itself into a target. When invocation volume rises but log delivery drops, the defender is looking at a control-plane compromise rather than a model issue. The same pattern also applies to guardrails, knowledge bases, and agents: once the surrounding configuration is writable by the compromised identity, the attacker can hide, reshape, or extend the abuse path.

Practical implication: treat logging configuration, guardrail changes, and model enablement APIs as high-risk administrative actions and alert on every non-change-management use.

Threat narrative

Attacker objective: The attacker wants to monetise or operationalise stolen Bedrock access while avoiding detection, billing the victim for model usage and using the environment as a reusable AI access channel.

1. Entry occurs when an attacker obtains a valid AWS access key or temporary credential with Bedrock permissions, often from a leaked repo, exposed .env file, compromised CI system, or stolen local secret.
2. Escalation occurs when the attacker confirms the key works, enumerates available models, disables or redirects logging, and expands from single calls to multi-region invocation and proxy-based resale workflows.
3. Impact occurs when the attacker runs inference at scale, uses the victim’s Bedrock account for uncensored chatbots or resale, and potentially exfiltrates prompts, responses, or model access without ever breaking the model itself.

Breaches seen in the wild

• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Bedrock abuse is an identity problem before it is an AI problem. The article makes clear that valid cloud credentials are enough to enable model access, logging tampering, and high-volume inference. That means the control boundary is the IAM principal, not the model endpoint, and practitioners should think about hosted AI platforms as privileged infrastructure.

Model invocation telemetry without identity telemetry is structurally incomplete. CloudTrail and CloudWatch each expose a different side of the same event, and neither one is sufficient alone. The governance lesson is that detection for AI workloads must be built around correlated identity and content evidence, or attackers will simply shift to whichever log path is blind at the moment.

Logging configuration has become part of the attack surface. When an identity can disable or redirect invocation logs, the defender loses the evidence needed to distinguish normal use from abuse. That turns observability into an access-control problem, not just a monitoring problem, and it should be governed with the same seriousness as model invocation permission.

Credential resale turns Bedrock access into a reusable criminal service. The article shows a market pattern where stolen access is proxied and resold rather than used once and discarded. That changes the practitioner’s threat model from single compromise to persistent monetisation, which is why NHI governance must include detection for proxy tooling, cross-region use, and abnormal token consumption.

Identity blast radius for AI workloads: once a single long-lived key can enable model access, disable logging, and reach connected agents, the governance assumption that AI infrastructure is safely segmented at the application layer fails. The implication is not just tighter access, but a redefinition of what counts as privileged AI infrastructure in the first place.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• That same survey found that only 44% of organisations have implemented any policies to manage their AI agents, even though 92% say governance is critical to enterprise security.
• For a deeper governance lens, see OWASP NHI Top 10 for the risks that emerge when AI systems are given broad runtime authority.

What this signals

Identity blast radius is now the right unit of measurement for AI platform risk. If a single credential can both invoke models and suppress logs, then traditional separation between application and infrastructure controls is too coarse. Teams should map every Bedrock-capable principal to its maximum possible effect and use that map to prioritise review and containment.

With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, according to The 2026 Infrastructure Identity Survey, the path to Bedrock abuse remains wide open wherever long-lived keys are still accepted.

The next governance question is not whether AI workloads will be targeted, but whether the surrounding identity and logging controls can survive abuse without losing evidence. That pushes NHI, IAM, and SecOps teams toward tighter boundaries, explicit admin roles, and telemetry correlation as a standard operating model.

For practitioners

• Inventory every Bedrock-capable identity Map all IAM users, roles, CI pipelines, and temporary credentials that can call Bedrock APIs or modify model logging settings. Separate human admin access from workload access and remove any long-lived AKIA keys that can reach inference or configuration paths.
• Correlate identity and invocation logs Join CloudTrail and Bedrock model invocation logs by principal, access key, and narrow time window so model enumeration, validation failures, and InvokeModel bursts appear as one incident instead of disconnected events. Use a 10-minute correlation window as a starting point.
• Lock down logging and guardrail changes Treat DeleteModelInvocationLoggingConfiguration, PutModelInvocationLoggingConfiguration, DeleteGuardrail, and UpdateGuardrail as high-severity administrative actions. Allow them only from a dedicated change-management role and alert on every other principal.
• Watch for proxy-style misuse patterns Flag repeated InvokeModel activity from unusual user agents, multi-region invocation bursts, and token burn that does not match the principal’s normal workload. Combine this with checks for malformed validation requests and the sequence of model discovery followed by inference.
• Use cost and delivery health as backstops Track token consumption spikes, expensive model usage, and drops in ModelInvocationLogsCloudWatchDeliverySuccess. If invocation volume remains positive while log delivery falls to zero, treat it as a probable tampering event rather than a telemetry glitch.

Key takeaways

• Bedrock abuse is enabled by compromised cloud identity, not by model compromise, which makes this a governance and access-control problem first.
• The most useful evidence is split across CloudTrail and CloudWatch, so detection depends on correlation rather than any single log source.
• Teams that allow long-lived credentials or writable logging settings for AI workloads are expanding the attacker’s blast radius before the first prompt is ever sent.

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.
• 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.
• Control Plane Abuse: Control plane abuse occurs when an attacker uses legitimate administrative interfaces to perform destructive or high-impact actions. In NHI terms, the problem is not malware execution but trusted authority that can scale changes across many systems at once.
• 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.

What's in the full report

Abstract Security's full article covers the operational detail this post intentionally leaves for the source:

• CloudTrail and CloudWatch detection logic for correlating Bedrock model abuse across identity and content telemetry
• Example event-name sequences for model enablement, reconnaissance, validation, and high-volume inference
• Concrete CloudWatch query patterns for spotting token burn, malformed prompts, and log delivery suppression
• Detection guidance for logging tampering, guardrail modification, and agent-related data events

👉 Abstract Security's full post covers the Bedrock kill chain, log-source gaps, and example detection logic.

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 identity security across human, machine, and AI workloads, it is worth exploring.