Sts Get-caller-identity
You run the sts get caller identity call to check which AWS user or role is active. It returns your user ID, AWS account number, and Amazon Resource Name without needing extra permissions. Platform teams use this check to confirm their local keys before they run scripts. Yet confirming who you are does not restrict what a broad role can do next. Many teams hand out wide admin roles so developers can fix bugs fast. A quick identity check confirms the role, but every risky action remains wide open
Identity and Access Management (IAM): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You run the sts get caller identity call to check which AWS user or role is active. It returns your user ID, AWS account number, and Amazon Resource Name without needing extra permissions. Platform teams use this check to confirm their local keys before they run scripts. Yet confirming who you are does not restrict what a broad role can do next. Many teams hand out wide admin roles so developers can fix bugs fast. A quick identity check confirms the role, but every risky action remains wide open.
How sts get caller identity works in AWS
The AWS Security Token Service runs this check whenever an engineer or app sends a request. You do not need to set up any special rules to let users run it. AWS allows every valid key or temporary token to call this action at any time. Even if a policy blocks all other actions, this specific call still works.
When the service gets the request, it reads the signature attached to the call. It matches that signature against the central AWS directory for that specific account. Then the service sends back three plain pieces of data to the caller. You see the account ID, the unique caller ID, and the full resource name.
Engineers run this check inside build jobs and local terminals to avoid mistakes. An engineer might work across five different accounts during a single busy afternoon. Checking the active profile before making changes stops teams from breaking the wrong system. If the response shows the prod account when you expected staging, you stop right there. It acts as a fast sanity check before a script runs a bigger job.
What native identity checks solve and what they miss
Running a caller check solves one problem very well for cloud teams. It proves that your local tool holds valid keys for a specific AWS role. It also records the lookup event inside your central cloud audit trail. Security teams can read those logs later to see when a key became active.
Still, checking the caller only tells you who logged in at the start. It does not govern what individual commands or queries do during the work session. Once a developer assumes a powerful role, AWS trusts every valid API call that follows. If that role can delete tables or read customer secrets, nothing stops a bad command.
Identity and Access Management (IAM): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Static cloud roles also force teams to store keys on laptops or build servers. Those keys sit in plain text files where local scripts can read them anytime. If an attacker steals a token, they will run the exact same caller check first. They use it to map out the account before they steal data. Also, cloud logs only show high-level API events, not the actual database queries inside a session. When a developer opens a shell on a server, the role check cannot see the commands typed inside.
Why role checks are not enough for live sessions
Cloud roles work at the account boundary, not inside your actual data tools. You might use an AWS role to log in to a cluster or a host. Once that session starts, the cloud identity check is completely done. It cannot pause a dangerous delete command and ask a lead for approval. It cannot rewrite sensitive fields like emails, phone numbers, or card numbers in query results.
Teams try to fix this by writing hundreds of tiny, complex role policies. That approach breaks down fast when engineers need to fix an urgent outage at night. Instead of maintaining fragile role files, teams need controls that inspect actions in flight.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Does sts get caller identity need IAM permissions?
No, AWS allows any valid user or role to make this call without extra rules. Even an explicit deny policy cannot block this specific check from returning your details.
Can attackers use sts get caller identity?
Yes, attackers often run this call first after they find a leaked cloud key. It tells them which account they breached without triggering a permission error alert.
Does this check log an event in AWS CloudTrail?
Yes, AWS records every caller check inside CloudTrail as a normal read event. Security teams often watch these logs to spot unusual activity from stolen keys.