Listen to this Post
Introduction
AWS AgentCore enables agentic workloads to exchange identity and retrieve access tokens for cross-service operations. However, when IAM policies use wildcard (“) permissions instead of scoped workload identity ARNs, any agent within the account can impersonate another—exposing OAuth2 tokens and API keys stored in the token vault. The official GitHub examples inadvertently promote this overprivileged pattern, creating a silent supply-chain risk for developers and AI coding assistants that copy-paste insecure configurations.
Learning Objectives
- Understand the AgentCore Identity token exchange flow and its reliance on IAM least privilege
- Identify wildcard-based IAM policies that enable lateral token theft across workload identities
- Implement scoped IAM policies, auditing commands, and automated guardrails to prevent token vault breaches
You Should Know
1. The Anatomy of AgentCore Identity Token Vault
AgentCore Identity introduces a token vault where workload identities can store and retrieve OAuth2 tokens and API keys. The critical API calls are:
– `CreateWorkloadIdentity` – creates or updates a workload identity
– `GetWorkloadAccessToken` – obtains a short-lived token for the agent
– `GetResourceOauth2Token` – returns the OAuth2 token for a specific resource
Step‑by‑step exploitation scenario with a wildcard policy:
- Attacker compromises Agent A (low privilege, but with wildcard permissions).
- Agent A calls `GetWorkloadAccessToken` for Agent B’s identity.
- Agent A then calls `GetResourceOauth2Token` to extract API keys from the vault.
4. Attacker exfiltrates tokens and moves laterally.
Audit command (Linux): List all IAM policies containing a wildcard resource:
aws iam list-policies --scope Local --output text | \
while read line; do policy_arn=$(echo $line | awk '{print $2}'); \
aws iam get-policy-version --policy-arn $policy_arn --version-id $(aws iam list-policy-versions --policy-arn $policy_arn --query 'Versions[bash].VersionId' --output text) --query 'PolicyVersion.Document.Statement[?Resource==<code>""</code>]' --output table; done
Windows (PowerShell):
Get-IAMPolicies -Scope Local | ForEach-Object {
$versions = Get-IAMPolicyVersionList -PolicyArn $<em>.Arn
$latest = $versions.Versions[bash].VersionId
Get-IAMPolicyVersion -PolicyArn $</em>.Arn -VersionId $latest | Select-Object -ExpandProperty Document | ConvertFrom-Json | Select-Object -ExpandProperty Statement | Where-Object { $_.Resource -eq "" }
}
- Wildcard Warnings: From GitHub Example to Production Breach
The official `agentcore-samples` repository contains a notebook that configures IAM roles with `”Resource”: “”` instead of a scoped ARN likearn:aws:bedrock-agentcore:${Region}:${Account}:workload-identity-directory/default/workload-identity/agent-a. This example is indexed by AI coding assistants and copied into production pipelines.
Mitigation – rewrite the policy to scoped permissions:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"bedrock-agentcore:GetWorkloadAccessToken",
"bedrock-agentcore:GetResourceOauth2Token"
],
"Resource": "arn:aws:bedrock-agentcore:us-east-1:123456789012:workload-identity-directory/default/workload-identity/agent-b"
}]
}
Check for wildcards in CloudFormation templates:
grep -r '"Resource"[[:space:]]:[[:space:]]"\"' --include=".yaml" --include=".yml" --include=".json" .
- Auditing Your AWS Environment for Overprivileged Workload Identities
Use IAM Access Analyzer and policy simulation to detect wildcard‑based trust.
Step‑by‑step audit:
- Enable IAM Access Analyzer with custom policy checks (resource type:
AWS::IAM::Policy).
2. Run a validation using AWS CLI:
aws accessanalyzer validate-policy --policy-type IDENTITY_POLICY --policy-document file://policy.json
3. Simulate a call from Agent A to Agent B’s token endpoint:
aws iam simulate-principal-policy --policy-source-arn arn:aws:iam::123456789012:role/agent-a --action-names bedrock-agentcore:GetWorkloadAccessToken --resource-arns arn:aws:bedrock-agentcore:us-east-1:123456789012:workload-identity-directory/default/workload-identity/agent-b
If the simulation returns `”allowed”: true` without a specific resource ARN in the policy, you have a wildcard risk.
4. Least-Privilege Policy Hardening for Agent-to-Agent Trust
Implement explicit trust between agent identities using condition keys.
Step‑by‑step hardening:
- Create a customer-managed policy for Agent A that only allows token retrieval for Agent B:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "bedrock-agentcore:GetWorkloadAccessTokenForJWT", "Resource": "arn:aws:bedrock-agentcore:us-east-1:123456789012:workload-identity-directory/default/workload-identity/agent-b", "Condition": { "StringEquals": { "bedrock-agentcore:RequestedWorkloadIdentity": "agent-b" } } } ] }
2. Attach the policy to Agent A’s role:
aws iam attach-role-policy --role-name agent-a-role --policy-arn arn:aws:iam::123456789012:policy/ScopedTokenRetrieval
3. Repeat for each agent pair, never using “ in Resource.
5. Monitoring and Detecting Token Vault Abuse
CloudTrail records every `GetWorkloadAccessToken` and `GetResourceOauth2Token` call. Set up alerts for anomalous cross‑identity token requests.
Create a CloudWatch Logs Insights query:
fields @timestamp, eventName, userIdentity.arn, requestParameters.workloadIdentityId | filter eventName in ["GetWorkloadAccessToken", "GetResourceOauth2Token"] | sort @timestamp desc | limit 200
Command to search recent token access from unexpected roles (Linux):
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=GetWorkloadAccessToken --start-time "$(date -d '1 hour ago' --iso=seconds)" --query 'Events[].CloudTrailEvent' --output text | jq '.userIdentity.arn, .requestParameters'
Set up an SNS alarm using CloudWatch metric filter on `”eventName”: “GetResourceOauth2Token”` with a threshold of 5 calls per minute from a single workload identity.
6. Automated Remediation with Infrastructure as Code
Prevent wildcard IAM policies from ever reaching production using cfn-guard or Open Policy Agent (OPA).
cfn-guard rule to deny any `”Resource”: “”` in IAM policies:
let resource = Resources.[ Type == 'AWS::IAM::Policy' ]
rule deny_wildcard_resource when resource.Properties.PolicyDocument.Statement[?Resource == '' ] {
message("Wildcard resource not allowed in IAM policy")
}
Terraform validation using `check` block:
check "no_wildcard_iam" {
data "aws_iam_policy_document" "check" {
source_json = data.aws_iam_policy_document.policy.json
}
assert {
condition = !can(regex("\\"Resource\\"\s:\s\\"\\\"", data.aws_iam_policy_document.check.json))
error_message = "IAM policy contains a wildcard resource"
}
}
7. Secure Development Practices for AI Coding Assistants
AI assistants like GitHub Copilot are trained on public repositories, including insecure AWS examples. Mitigate by:
- Creating a `.cursorrules` or `.github/copilot-instructions.md` file:
Never generate IAM policies with "Resource": "" for AgentCore actions. Always expand to full workload identity ARN.
- Pre‑commit hook scanning for wildcards (
.git/hooks/pre-commit):!/bin/bash if grep -r '"Resource"[[:space:]]:[[:space:]]"\"' --include=".yaml" --include=".json" .; then echo "ERROR: Wildcard IAM resource detected. Please use scoped ARNs." exit 1 fi
What Undercode Say
- Wildcard permissions in AgentCore turn the token vault into a free‑for‑all – any compromised agent becomes a token oracle for all other workloads.
- Vendors must treat example code as security product documentation. A single GitHub notebook with a `””` can cascade into thousands of production breaches via AI‑assisted copy‑paste.
- Trust boundaries in agentic AI must be explicit and verifiable. The industry must move from “we recommend least privilege” to automated enforcement at CI/CD and deployment time.
- Monitoring token vault API calls is non‑negotiable. Most organizations log only S3 and EC2 – but token exchange APIs are the new authentication backbone.
Prediction
Within 12 months, attackers will weaponize leaked AgentCore wildcard samples to build automated token harvesters targeting CI/CD pipelines and LLM‑powered agents. Cloud providers will respond by introducing “security linters” directly into AWS Console for IAM policy creation, and AI coding assistants will be fined‑tuned to reject wildcard templates. The real shift will be toward zero‑trust workload identity where every token request requires explicit, resource‑scoped authorization—and where documentation examples are treated with the same rigor as production firewall rules.
▶️ Related Video (84% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Marjansterjev I – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
