ACL Whoami
You run acl whoami to check the username bound to your active database session. The server reads the current session state and returns the logged-in account name. Engineering teams often use this check to confirm which role an app uses. Still, teams often share one broad database account across many apps and engineers. When everyone logs in with the same shared account, identity checks lose value. You can see the active role name, but not the real person behind it. How acl whoami works in an a
Whoami: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You run acl whoami to check the username bound to your active database session. The server reads the current session state and returns the logged-in account name. Engineering teams often use this check to confirm which role an app uses. Still, teams often share one broad database account across many apps and engineers. When everyone logs in with the same shared account, identity checks lose value. You can see the active role name, but not the real person behind it.
How acl whoami works in an active session
Data stores use access control lists to manage user accounts and command rules. When a client logs in, the server checks the username and secret key. Once that check passes, the server binds that user profile to the session. Every action inside that session then runs under that single bound account.
Running acl whoami asks the server to return that bound account name. The server does not check external directories or identity providers during this step. It only looks at its own internal memory for the active session state. It then replies with a plain text string showing the active user name.
This check helps engineers debug permission errors when an app fails to write data. If a script fails, an engineer checks the active user to find the cause. Often, the client forgot to log in and stayed on the default user. Other times, the app logged in with a read-only role by mistake. A quick identity check shows which account holds the session right now.
What native user checks solve and what they miss
Native access control lists help teams split duties between different services and apps. You can create one role for a billing worker and another for analytics. You can also turn off dangerous admin commands for normal app accounts. Checking the active user confirms that your login logic picked the right profile.
Yet this native setup only decides who can open a session at login. It does not solve accountability when five engineers share one admin role for fixes. If an engineer runs acl whoami during an incident, it returns the shared admin name. Your audit logs will also show that shared role name instead of the person. You cannot tell which team member ran a bad write command during the outage.
Whoami: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Static access lists also cannot inspect what individual commands do to live data. Once a role has permission to read keys, it can read every allowed record. The native permission model cannot spot or rewrite sensitive customer fields inside the reply. If a key holds emails, phone numbers, card numbers, or national IDs, raw data returns. Native user checks also cannot pause a risky command to ask for peer approval.
Managing shared roles and sensitive data in flight
Relying only on internal database accounts creates heavy work for security and platform teams. You have to rotate passwords across every app whenever an engineer leaves the team. You also have to build custom scripts to track who holds which static password. If you create one database user per person, every server needs constant rule updates.
A better pattern ties every database session directly to your central identity provider. Instead of handing out static database passwords, engineers log in with work accounts. Each command in flight then links back to an individual person, not a shared role. Data masking can also rewrite matched fields in results before they reach the client.
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
What does the acl whoami command return by default?
If a client has not logged in with a specific user, it returns default. Once the client logs in, it returns the exact username tied to that session.
Does acl whoami show the permissions of the current user?
No, the command only returns the name of the active account in plain text. To see allowed commands or keys, you must query the full access control list.
Why do audit logs still show a shared username after running acl whoami?
The data store only knows the local account used to start the session. If ten engineers share one admin password, the server sees all ten as one user.