Vaultless PAM
You set up vaultless pam by replacing stored static passwords with temporary identity assertions. Your team logs into databases and servers using their existing single sign-on accounts. Most engineering teams start this setup by linking cloud identity providers to host roles. They map group memberships to admin roles across every production database and server. When these mapped roles stay active all day, one stolen laptop puts data at risk. Broad role permissions also let users run destructive
CyberArk PAM: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up vaultless pam by replacing stored static passwords with temporary identity assertions. Your team logs into databases and servers using their existing single sign-on accounts. Most engineering teams start this setup by linking cloud identity providers to host roles. They map group memberships to admin roles across every production database and server. When these mapped roles stay active all day, one stolen laptop puts data at risk. Broad role permissions also let users run destructive commands once a session starts.
How vaultless pam works at the architecture level
Old privileged tools store root passwords in a central database and rotate them on schedule. Users check out a password, log into a target server, and run their work. That model still relies on static secrets sitting on a network host.
A vaultless pam design removes the central password store from your login workflow. Instead, your identity provider issues a signed claim after a user passes multi-factor checks. The server or database checks that signed claim against a trusted public key. If the signature matches, the host starts a user session right away. No long-lived password sits in a vault waiting to be leaked or rotated.
Teams often configure cloud IAM roles or short-lived SSH certificates to handle this step. An engineer logs into their identity provider at the start of a shift. The provider verifies their group membership and issues a temporary certificate or role binding. The engineer then uses their normal terminal or database client to open a session. When the timer on that certificate runs out, the login credential stops working.
Why temporary login credentials still leave an operational gap
Removing stored passwords solves a huge part of the credential theft problem. Attackers do not receive unmasked a root password database if no password database exists. Security teams also spend less time fixing broken scripts caused by failed password rotations.
Still, a temporary certificate or cloud role only controls the initial login handshake. Once the database or server accepts the login, the host grants the full role. An engineer mapped to a read-write role can drop a table by mistake. A developer running a quick fix can read millions of customer records in one query.
CyberArk PAM: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Native role bindings cannot tell a safe query from a destructive command in flight. They do not ask for peer approval when someone runs a dangerous shell script. They also return raw sensitive fields like emails, phone numbers, and card numbers in results. If an AI agent uses that same temporary role, it can pull sensitive data too. To stay safe, teams need controls that inspect and filter individual commands and queries.
How to plan a move away from static secret stores
Start your migration by listing every shared admin account across your servers and databases. Group these accounts by the daily tasks that engineers perform during support shifts. You will often find that most daily debugging only needs read access to specific tables.
Next, stop issuing shared database passwords and static SSH keys to new team members. Tie every human and automated agent login back to your central identity provider. Make sure your audit logs record the specific human user behind every single query. Finally, add runtime controls that check individual statements and rewrite sensitive fields in query results. Masking rewrites matched fields like national IDs in results before they reach the client screen.
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 runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values 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
What is the main difference between traditional vaults and vaultless pam?
Traditional vaults store static passwords and rotate them after a user checks them out. Vaultless setups remove standing passwords and use identity claims to start each session.
Does removing a password vault stop engineers from running bad queries?
No, because temporary login roles only check who logs in at the start. Once inside the session, the user can run any command allowed by that role.
How does data masking work during a live database session?
Masking inspects query results in flight and rewrites matched fields like emails or card numbers. This happens before the data ever reaches the engineer or automated tool.