AWS List-profiles
You can run an aws list profiles command to see all saved cloud accounts on your machine. The command line tool reads your local settings files and prints each profile name. Engineering teams often save dozens of named profiles to switch between test and live accounts. Still, storing long-lived keys with broad roles in plain text files creates serious security risks. One wrong profile choice can run a destructive script against a live cloud account. How aws list profiles works on your machine
AWS IAM Policies + Seccomp Profiles: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You can run an aws list profiles command to see all saved cloud accounts on your machine. The command line tool reads your local settings files and prints each profile name. Engineering teams often save dozens of named profiles to switch between test and live accounts. Still, storing long-lived keys with broad roles in plain text files creates serious security risks. One wrong profile choice can run a destructive script against a live cloud account.
How aws list profiles works on your machine
When you check your profiles, the command line tool looks in your home folder. It reads two specific plain text files that hold your settings and secret keys. One file stores general settings like your default region and output format for each named profile. The second file stores your raw access keys, secret keys, and temporary session tokens. The tool merges the profile names from both files into one clean list for you.
Each profile in that list maps to an identity or a specific cloud role. Some profiles hold static keys tied to a single user account in the cloud. Other profiles point to a role that your user account can assume for a short time. You can also set up profiles that work with single sign-on portals for your team. When you run a command, you tell the tool which profile name to use.
If you do not pick a profile, the tool falls back to the default profile. Many engineers put their most used keys in that default slot to save time. You can also set a shell variable to lock in a profile for your current terminal window. This local setup makes switching accounts fast, but it relies on manual human habits.
Why local profile files leave a security gap
Named profiles solve the problem of juggling multiple cloud accounts on one laptop. A developer can test code in a sandbox and then check logs in a live account. Using single sign-on profiles also stops teams from sharing static secret keys over chat apps. These native features help organize who can log in to which cloud account from a terminal.
Yet local profile management leaves a large operational gap once a session starts. A profile decides which role you assume, not what individual commands do in flight. To avoid permission errors, teams often grant broad admin or write roles to these profiles. Once an engineer activates a live profile, every command runs with full power.
AWS IAM Policies + Seccomp Profiles: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
A simple typo or a forgotten terminal variable can drop a table or delete cloud storage. Also, static keys sitting in local text files are easy targets for malware on a laptop. Cloud audit logs show which role ran a command, but they often miss the full context. Teams need a safer way to control active commands and protect sensitive data like emails or card numbers.
Safer habits for managing local cloud profiles
You can lower your risk by changing how you structure your local profile files. First, leave your default profile empty or point it to a safe sandbox account. This simple step prevents accidental runs against live systems when you forget to name a profile. Every action in a live account should require an explicit choice from the engineer.
Second, remove all static access keys from your local files as soon as possible. Switch your team to profiles that use short-lived tokens from your single sign-on provider. When a session expires after an hour, old tokens on a laptop cannot harm your cloud. Finally, split your roles into read-only profiles for daily checks and separate profiles for rare write tasks.
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
Where does the command line tool find my profile names?
The tool reads the config and credentials files inside the hidden cloud folder in your home directory. It collects every section header from both files and removes duplicates to build the final list.
Why is a newly added profile missing from my list?
Check the spelling of the section header in your local settings file. In the main config file, every profile except the default one must start with the word profile before the name.
How can I stop running commands in the wrong cloud account?
Remove keys from your default profile so the tool fails if you do not pick an account. You should also use separate read-only profiles for daily checks to limit damage from mistakes.