Start with the AssumeRoleWithWebIdentity event, which records the role your pipeline assumed. Then filter later events by the role session, which carries the name you set in the workflow. CloudTrail logs the calls, but some things, like PassRole, appear only indirectly.
What CloudTrail records for CI
AWS documents that CloudTrail logs all authenticated API requests to IAM and STS. It also logs the unauthenticated STS calls AssumeRoleWithSAML and AssumeRoleWithWebIdentity, including information provided by the identity provider. The web identity call is the one your OIDC based pipeline makes.
Without a trail, you can still view recent events in the CloudTrail console event history. For a lasting record, create a trail that delivers to a storage bucket. Plan for that before you need it, because investigations start from the log.
Steps to trace one pipeline run
- Note the time of the run and the role session name. Setting a clear
role-session-namein the workflow, such as the run ID, makes this easy. - In event history or your log search, find events with the event name AssumeRoleWithWebIdentity around that time.
- Open the event and read the role ARN, the provider, the audience and the subject from the web identity token.
- Note the assumed role session ARN in the response. It ends with your session name.
- Search for other events whose user identity is that assumed role session.
- Read them in order: what was listed, what was created, what was deleted.
AWS notes the logged information lets you map calls made by an OIDC federated principal with an assumed role back to the originating external caller. For a role used by an AWS user, the subsequent calls show the role identity only and not the person, so the session name carries more weight than you might expect.
Useful fields
| Field | Why you want it |
|---|---|
| eventName | What was called |
| userIdentity session issuer | Which role the session belongs to |
| roleSessionName in the request | Your pipeline run label |
| sourceIPAddress | Where the call came from |
| additionalEventData | For web identity, how AWS verified the provider connection |
What you will not see
Two limits come from AWS's documentation. CloudTrail does not log denied STS requests in the target account for cross account role assumptions. And some unauthenticated STS requests might not be logged if they are not valid enough to be trusted as a legitimate request. So a failing trust policy may leave less evidence than you expect, and you may need to look at the calling side for the failure.
PassRole is also not an API call, so no event exists for it. Read the event that created or changed the resource instead.
For object level storage activity, such as reads and writes of individual files, you need data events enabled on the trail. AWS's S3 guidance describes data events as records of operations performed on or within a resource, and notes they are opt in when you create a trail.
Make it routine
Write down two or three queries your team reuses: new roles created by the CI role, deletions of storage objects, and policy changes. Review them after a pipeline change and after any incident. Keep logs in a separate account if you can, so a compromised workload account cannot erase them.
Try it yourself
Audit trails are also compliance evidence. The framework mapping demo shows how a control and its supporting evidence line up.
Click through it at your own pace, or open it full screen.
Quick check
Which CloudTrail event shows a CI role assumption via OIDC?
AssumeRoleWithWebIdentity. AWS says CloudTrail logs it along with information from the identity provider.
Do I need a trail, or is event history enough?
Event history shows recent events. A trail gives a lasting record delivered to a bucket, which you want for investigations and evidence.
Safeguard does not manage your cloud accounts. It scans your code and dependencies, applies pull request policies and gates, and automates compliance evidence. Free scan: gold.safeguard.sh/scan.
Sources
- AWS IAM User Guide: Logging IAM and AWS STS API calls with AWS CloudTrail
- AWS IAM User Guide: Grant a user permissions to pass a role to an AWS service
- Amazon S3 User Guide: Security best practices
Last reviewed: 19 October 2026.
