Loading story…
AWS has introduced Amazon Bedrock API keys in addition to its broader push away from long-lived IAM access keys toward modern, temporary authentication mechanisms. Bedrock supports locally generated short-term keys from presigned URLs as well as long-term bearer tokens backed by IAM users; the latter can be created without an expiration date and are submitted directly in HTTPS headers. By default, long-term keys receive the AmazonBedrockLimitedAccess policy, which may grant more access than is necessary for narrowly scoped model-invocation workloads.
Researchers found long-term Bedrock API keys exposed in public GitHub repositories within two weeks of the feature's launch. AWS added the keys to its secret-scanning process and now quarantines associated IAM users and notifies affected customers when exposures are detected. Organizations should favor temporary, role-based credentials, restrict IAM-user creation through service control policies, and consider denying bedrock:CallWithBearerToken where Bedrock API keys are not required, blocking both long- and short-term API-key use.
See attribution, scope, and your downstream exposure.
4 events from the most recent confirmed update back to the earliest known activity.
AWS added the iam:ServiceSpecificCredentialAgeDays and iam:ServiceSpecificCredentialServiceName condition keys, enabling policy controls over Bedrock API-key age and service-specific credentials.
AWS added long-term Bedrock API keys to GitHub secret scanning. When detected in a public repository, AWS quarantines the associated IAM user and notifies the customer through a support case and email; AWS also investigated and quarantined previously committed keys it found.
Long-term Bedrock API keys were found exposed in public GitHub repositories within two weeks of their launch.
AWS introduced Amazon Bedrock API keys, including long-term bearer tokens backed by IAM users and short-term keys generated locally from presigned URLs. Long-term keys can be configured without expiration and receive the AmazonBedrockLimitedAccess policy by default.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See attribution, scope, and whether this vendor sits anywhere in your supply chain.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Amazon has introduced new security features and best practices for its Bedrock platform, focusing on both API key management and the protection of generative AI applications. The release of Amazon Bedrock API keys provides developers with new options for accessing the Bedrock API, but also introduces potential security risks if not managed properly. AWS recommends using temporary security credentials from AWS Security Token Service (STS) as the preferred authentication method, as these credentials are short-lived and reduce the risk of long-term exposure. In cases where API keys must be used, AWS advises choosing short-term API keys over long-term ones, as they have built-in expiration mechanisms that limit the window of vulnerability if a key is compromised. For scenarios requiring long-term API keys, such as with certain third-party software, AWS suggests implementing strict controls and monitoring to mitigate risks. Service control policies (SCPs) can be used to restrict the creation and use of API keys, further reducing the attack surface. In addition to credential management, AWS has launched Amazon Bedrock Guardrails, a suite of configurable safeguards designed to protect generative AI applications from sophisticated attacks, including encoding-based threats. These guardrails provide six key protections: content filters, denied topics, word filters, sensitive information filters, contextual grounding checks, and automated reasoning checks. Encoding-based attacks, where malicious actors encode harmful content to bypass detection, are a growing concern for organizations deploying generative AI. Bedrock Guardrails address this by implementing a defense-in-depth strategy that detects and blocks encoded threats, such as base64 or hexadecimal representations of forbidden words. The safeguards are designed to work across multiple foundation models, including those hosted outside of Amazon Bedrock, ensuring broad applicability. AWS provides detailed guidance on implementing these protections, emphasizing the importance of balancing robust security with usability to avoid friction for legitimate users. Monitoring and auditing of API key usage, as well as regular review of guardrail configurations, are recommended to maintain a strong security posture. The combination of secure API key management and advanced guardrails positions Amazon Bedrock as a platform capable of supporting secure, scalable, and responsible generative AI deployments. Organizations are encouraged to adopt these best practices to protect sensitive data and maintain compliance with internal and external security standards. By leveraging these new features, enterprises can mitigate the risks associated with both credential exposure and advanced AI-specific attack vectors. The comprehensive approach outlined by AWS reflects the evolving threat landscape and the need for proactive, layered defenses in modern cloud environments. Security teams should stay informed about updates to Bedrock's security capabilities and continuously adapt their strategies to address emerging threats. The integration of these controls into development and operational workflows is essential for safeguarding AI-driven applications and maintaining trust in automated systems.
Jun 29, 2026
FortiGuard Labs documented an **LLMjacking** intrusion in which attackers used a leaked, long-lived AWS IAM access key with `AdministratorAccess` to create a new IAM user, subscribe to premium foundation models through AWS Marketplace, and run inference charges against the victim organization. The financial exposure can be substantial: abuse of Claude 2.x may exceed **$46,000 per day**, while Claude 3 Opus usage may exceed **$100,000 per day**. The actors may create Amazon Bedrock service-specific API keys to conceal the activity and resell stolen model access through low-cost chatbot subscriptions promoted on Telegram and Discord. Because requests are made with valid AWS credentials, the abuse can resemble legitimate usage; organizations should eliminate long-lived privileged access keys in favor of short-lived assumed-role credentials, enable organization-wide CloudTrail and Bedrock invocation logging, and investigate new Bedrock activity alongside identity, IP, enumeration, and access-denied anomalies.
Sep 3, 2026
Truffle Security reported that more than **9,300 publicly exposed Amazon Web Services access keys** remained active and valid after being leaked between August 2022 and August 2026, highlighting a widespread cloud credential exposure problem. Across public sources, the researchers identified **64,024 unique AWS keys** and found that **88%** of a subset of **10,616** keys with complete credentials still successfully authenticated as of August 10. The leaked secrets included **526 root keys** and **242 IAM user keys** with **`AdministratorAccess`**, creating a path to full AWS account compromise. Researchers said the exposed credentials could allow attackers to steal or destroy data, take control of applications, establish persistence, and deploy cryptominers. **Hugging Face** was identified as the largest single source of leaked AWS keys in the dataset, while the persistence of valid credentials pointed to weak key rotation and poor credential hygiene across affected organizations. Truffle Security urged organizations to delete root access keys, rotate or revoke exposed credentials, review IAM key age and permissions, and enable AWS budget alerts to detect abuse.
Aug 24, 2026