Cloud Security Wire
AWS Azure GCP RSS
AWS Hardening Guide high

ARTEX Agents Hunt AI API Keys: Hardening AWS AI Gateways, Bedrock Access and Secrets Against Automated Credential Theft

Amazon Threat Intelligence observed ARTEX AI agents harvesting AI model credentials at scale. What Amazon reported, and the AWS CLI checks we suggest for exposed LLM gateways, secrets, metadata access and spend.

By Cloud Security Wire · ·
#ARTEX#Amazon Threat Intelligence#AI credentials#LLM gateway#Bedrock#Secrets Manager#IMDSv2#SSRF#hardening
High Severity

This issue has been assessed as high severity. Review affected configurations immediately.

On 13 November 2026 Amazon Threat Intelligence (CJ Moses, AWS Security Blog) described cybercrime campaigns run with ARTEX, an open-source agentic penetration-testing framework. Amazon collected the activity through MadPot decoy sensors between 3 October and 5 November, capturing agents’ prompts, tool histories and findings. It did not observe the activity against victims directly and could not verify the agents’ reported outcomes. It assesses, with moderate confidence, that the operators are disparate China-nexus groups.

What Amazon reported

Campaign 1 targets AI credentials. The agents hunted API keys and credentials for AI models. Credentials were graded L1 (a lead), L2 (a confirmed working API call) and L3 (quantified impact), and keys exposed publicly for more than 30 days were treated as low value.

Named weaknesses: uninitialized installs that could be claimed; anonymous management and provider-configuration endpoints; default administrator credentials including the LiteLLM default master key; CVE-2025-3248 (Langflow); CVE-2026-28797 (RAGFlow); an isCliRequest header authentication bypass in One API family systems; SSRF through URL-fetch features to reach cloud metadata services; and secrets in client-side JavaScript, source maps, debug routes and environment files.

Campaign 2 used deepfakes against know-your-customer checks at two cryptocurrency exchanges. It is outside this guide’s scope.

Amazon’s defender guidance centers on basic hygiene. The rest of this guide is our suggested checklist, not Amazon’s, built from the weaknesses it names. The commands are standard AWS CLI calls; we have not run them against your account, so test in a non-production profile first.

1. Find your exposed AI gateways and apps

Inventory anything running LiteLLM, One API, Langflow, RAGFlow, Dify, Open WebUI or similar on EC2, ECS or EKS, and check what is internet-facing.

aws ec2 describe-security-groups \
  --filters Name=ip-permission.cidr,Values=0.0.0.0/0 \
  --query 'SecurityGroups[].{id:GroupId,name:GroupName,ports:IpPermissions[].FromPort}' --output table

For each hit, confirm the admin and configuration endpoints require authentication, the default master key or admin password has been changed, and the instance was not left in a first-run, claimable state.

2. Block the SSRF-to-metadata path

Amazon names SSRF through URL-fetch features to reach cloud metadata. Require IMDSv2 so a simple request-forwarding bug cannot read role credentials.

aws ec2 describe-instances \
  --query 'Reservations[].Instances[?MetadataOptions.HttpTokens!=`required`].[InstanceId]' --output text
aws ec2 modify-instance-metadata-options --instance-id <id> \
  --http-tokens required --http-put-response-hop-limit 1

Setting the hop limit to 1 stops containers on the host from reaching the metadata service unless you deliberately allow it.

Breakage warning: AWS documents that requiring IMDSv2 can break applications and tools that still use IMDSv1, and that a hop limit of 1 can break containerized workloads that need metadata access. Test on one instance first and see the linked AWS documentation. Note also that the security-group query above covers only IPv4 rules in the current region and only EC2 security groups; check other regions and non-EC2 resources.

3. Shrink what a stolen role can reach

Keep application roles narrow: allow only the model ARNs a workload needs (for Amazon Bedrock, the specific bedrock:InvokeModel resources), and scope secret access to named secrets.

aws iam simulate-principal-policy --policy-source-arn <role-arn> \
  --action-names bedrock:InvokeModel secretsmanager:GetSecretValue ssm:GetParameter \
  --resource-arns <resource-arn>

4. Remove secrets from code and public artifacts

Amazon names secrets in client-side JavaScript, source maps, debug routes and environment files, and says keys exposed publicly for more than 30 days were graded low value by the agents. Scan builds and repos before publishing and rotate anything that has appeared publicly.

5. Watch for AI service misuse

Amazon recommends monitoring for unexpected spend and unusual usage. Set a budget alert on AI services and review model-invocation activity.

aws budgets describe-budgets --account-id <account-id>
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventSource,AttributeValue=bedrock.amazonaws.com --max-results 50

Bedrock model-invocation logging, if you have enabled it, will show calls by principal and model. Amazon’s published post did not list CloudTrail event names, so tune alerts to your own baseline.

6. Treat AI apps like production systems

Our checklist (not a quote from Amazon’s post): put AI applications, gateways and inference endpoints under the same controls as other production systems: patching, authentication, network restriction and logging. Check your Langflow and RAGFlow versions against CVE-2025-3248 and CVE-2026-28797 in the vendors’ advisories.

Limits

Amazon provides an indicator list in its post (we have not reproduced it); load it from the source. Absence of a hit is weak evidence.

References

← All Analysis Subscribe via RSS