AWS's penetration testing page now lists Amazon Bedrock AgentCore among the services you can test without prior approval, alongside EC2, Lambda, API Gateway, RDS and others. The list keeps growing, so a cloud configuration review is a normal part of a pen test. The question buyers rarely plan for is how the tester gets in. Emailing a long-lived access key is the common answer and the wrong one.
What's affected
Any company that wants the tester to review its cloud account configuration in addition to the application: IAM, storage permissions, network rules, logging. A black box test of exposed endpoints does not need account access at all.
How to check if you're exposed
List the IAM users and keys your last tester used, and when you deleted them.
aws iam list-users --query 'Users[].UserName'
aws iam list-access-keys --user-name vendor-test-user
aws iam get-access-key-last-used --access-key-id AKIAEXAMPLE
If a vendor user still exists months after the report, you have a standing credential outside your normal joiner and leaver process.
What to do now
- Use an IAM role. AWS's guidance for third parties says a role lets them reach your resources without sharing your security credentials, and recommends temporary credentials over an IAM user's long-term keys.
- Ask for their AWS account ID and an external ID. The external ID guards against the confused deputy problem. AWS notes it is not a secret, so it adds protection against misuse of the role, not a password.
- Create the role with a trust policy like this:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::111122223333:root"},
"Action": "sts:AssumeRole",
"Condition": {"StringEquals": {"sts:ExternalId": "vendor-supplied-random-string"}}
}]
}
- Attach read-only permissions. For a configuration review, start with the AWS managed policy SecurityAudit, which AWS describes as granting access to read security configuration metadata. AWS last edited it on 30 September 2026, so use the managed policy itself rather than a copied document. Do not give write access unless the test needs it.
- Set a short session duration and a calendar end date. Delete the role when the retest is done.
- Turn on logging first. Confirm CloudTrail is recording in every region you use, so you can show what the tester did.
- Tell the tester the rules. AWS prohibits denial of service (including simulated), request and port flooding, DNS zone walking and S3 bucket and subdomain takeover. Red team, simulated phishing and malware testing need a Simulated Events form, submitted at least two weeks ahead.
- Check the other clouds. Microsoft's rules say tests must stay within your own tenant or assets, forbid denial of service and DDoS, and forbid using credentials that are not yours. Google says you do not need to notify it before testing your own projects, but you must follow its Acceptable Use Policy and Terms of Service.
How to avoid this trap
- Make the external ID unique per engagement, and generate it on the vendor side.
- Review the role with IAM Access Analyzer, which AWS points to for finding principals outside your zone of trust.
- Put the role name and end date in the rules of engagement so it is on the retest checklist.
Why it matters
Cloud account access is a privilege that is easy to hand out and easy to forget. A temporary role makes the grant visible, limited and short-lived. It also makes the audit trail simple: every API call the tester made is in CloudTrail under one role session name.
The test rules differ by provider, so write them into the scope sheet instead of assuming. A test plan that is fine on Google Cloud, with no notice required, can break AWS or Microsoft rules.
Try it yourself
Create a read-only role in a sandbox account, assume it from a second account with and without the external ID, and confirm the call without it fails.
Click through it at your own pace, or open it full screen.
Quick check
Why use a role instead of an IAM user for a vendor?
A role issues temporary credentials and can require an external ID, while a user's access key is long-lived and tends to outlast the engagement.
Do you have to notify Google Cloud before a penetration test of your own projects?
No. Google says you are not required to contact it, but you must follow its Acceptable Use Policy and Terms of Service.
