AWS Who Am I
You run an aws who am i check by calling the Security Token Service. This call returns your active account number, user ID, and role name. Engineering teams run this check before they change cloud resources. Developers often hold keys for test accounts and live accounts on one machine. If you use the wrong profile, a script can delete live data. Broad cloud roles make this mistake much worse for your team. How an aws who am i check works under the hood Every request to the cloud needs a valid
AWS IAM Policies: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You run an aws who am i check by calling the Security Token Service. This call returns your active account number, user ID, and role name. Engineering teams run this check before they change cloud resources. Developers often hold keys for test accounts and live accounts on one machine. If you use the wrong profile, a script can delete live data. Broad cloud roles make this mistake much worse for your team.
How an aws who am i check works under the hood
Every request to the cloud needs a valid key and secret. Your local tool looks for these keys in several places. It checks shell variables first, then reads local profile files. In cloud servers, it can also read the role attached to the machine. Because keys live in many places, developers often lose track of the active profile.
The caller identity call goes straight to the Security Token Service. This request works even if your role has zero permissions attached. The cloud service reads the signature on your request and finds the owner. It then sends back three core facts about your current session.
First, you get the twelve-digit account number that owns the identity. Second, you receive a unique identifier for the user or assumed role session. Third, you see the full resource name that shows your exact path. Teams read this output to confirm they are in the right account.
Why local profile management causes identity mistakes
Most engineers store several cloud profiles on their work laptops. One tab in a terminal might point to a sandbox account. A second tab might hold active keys for the main customer database. A developer switches tabs, skips the identity check, and runs a bad script.
Long-lived keys on laptops also create a big security risk. If an attacker steals a laptop file, they gain that same role. Even with temporary roles, a session often lasts for several hours. During that window, the user holds full power for that role.
AWS IAM Policies: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native identity checks solve and what they miss
Checking your active cloud identity confirms who you are at login time. It prevents simple mistakes when a person remembers to run the check first. Build scripts also use this check to stop deploys to the wrong account. It is a good first step for basic cloud hygiene.
Still, an identity check only tells you who holds the keys. It does not check or limit the commands you run next. Once a developer assumes a broad admin role, every action is open. Native identity checks cannot stop a bad database drop or a wide delete.
Cloud logs record the API call, but they miss inside details. If a user connects to a database, cloud logs only show the network start. They do not record the actual SQL queries or shell commands inside. Teams also struggle when raw emails, phone numbers, or card numbers return in outputs.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Does the caller identity check need special permissions?
No, the Security Token Service allows this call for any valid key. Even if an explicit deny policy exists, this identity check still works. You can always check which user or role your session uses.
Why does my identity check show an assumed role instead of my user name?
When you use single sign-on or switch roles, you get temporary keys. The cloud sees your session as that temporary role, not your base user. The returned resource name includes both the role name and your session name.
Can I use this check to verify keys in automated pipelines?
Yes, teams often put an identity check at the start of deploy jobs. The script reads the returned account number and compares it to a target value. If the account numbers do not match, the job stops right away.