A shared admin password in a team vault, a DBA account that never expires, a cloud key copied into a CI job: each one is privileged access that nobody is watching. Privileged access management (PAM) is the discipline that finds that access, takes the standing part away and records what happens when someone, or something, uses it.
What does privileged access management do?
Privileged access management (PAM) controls who can use privileged access, when, and what they can do with it, and it records every privileged session for audit. PAM in cybersecurity covers both people (admins, DBAs, SREs) and non-human identities (service accounts, CI pipelines, AI agents) that can change systems or read sensitive data.
NIST defines a privileged user as a user that is authorized, and therefore trusted, to perform security-relevant functions that ordinary users are not authorized to perform. A privileged account is a system account with the authorizations of a privileged user. PAM is the set of policies, processes and tools that govern those accounts and the access they grant.
In practice, a PAM program answers four questions for every privileged action: who is doing it (a named person, not a shared account), whether they should have that access right now, what they’re allowed to do once connected, and what they actually did.
What counts as privileged access?
Privileged access is any access that can change a system’s configuration, bypass its normal controls or read data that ordinary users can’t. It’s broader than the word “admin” suggests:
- Operating system superusers: root on Linux hosts, local Administrator on Windows servers, and anyone with sudo rights.
- Database administrators and production database users: accounts that can read customer tables, change schemas or delete data.
- Cloud and infrastructure admins: cloud IAM roles with broad permissions, Kubernetes
cluster-admin, network device admins. - Service accounts and secrets: application database users, API keys and tokens used by CI/CD pipelines and scripts. They often hold broad access and get reviewed less often than human accounts.
- Break-glass accounts: emergency accounts that skip normal approval. You need them, and they’re the first thing to monitor.
- AI agents and automation: coding agents and other AI agents that run SQL, shell commands or API calls with real credentials.
How does privileged access management work?
PAM works by putting a control point between privileged identities and the systems they reach, then applying the same few building blocks at that point, whatever the tool.
Credential vaulting and brokering
Privileged passwords, SSH keys and tokens live in a vault or broker, not on laptops or in wikis. The stronger version is brokering: the PAM system authenticates the person, then supplies the credential to the upstream connection itself, so the person never sees it. The credential can then be rotated without telling anyone.
Just-in-time access instead of standing privileges
Standing privileges are permissions held all the time, whether they’re used or not. Just-in-time (JIT) access grants them for a specific task and a limited time, usually after an approval, then removes them automatically. Just-in-time access has its own explainer.
Least privilege on each action
Least privilege means restricting access to the minimum needed for the task. For privileged sessions, it goes below the login: read-only by default, destructive commands blocked and sensitive columns masked, even when the underlying account could do more.
Session monitoring and recording
Privileged sessions are logged and, for interactive protocols like SSH, recorded so a reviewer can replay them. Live monitoring lets the security team end a session that goes wrong while it’s still running.
Audit and access review
Every privileged action is tied to a named person in an audit trail, and periodic access reviews remove privileges nobody needs anymore.
Deployment models differ. Some PAM tools check passwords out of a vault, some install an agent on each host, and some run as a proxy or gateway that every privileged connection passes through. A proxy sees the traffic, so it can inspect and control individual queries and commands; a vault on its own controls the credential, not what happens after the connection opens.
Why is PAM security important?
Privileged credentials are the shortest path from an initial foothold to the data and systems an attacker wants. PAM security limits how much damage one stolen credential, one mistake or one misdirected agent can do.
- Smaller blast radius: with no standing access, a stolen laptop or leaked token doesn’t carry live production access.
- Accountability: shared accounts make every action anonymous. PAM ties each action to a person.
- Faster investigations: session logs show what was read or changed, instead of reconstructing it from scattered system logs.
- Compliance: frameworks expect controls on privileged access. NIST SP 800-53, for example, includes control AC-6 (Least Privilege) with enhancements to restrict privileged accounts (AC-6(5)), review user privileges (AC-6(7)) and log the use of privileged functions (AC-6(9)).
PAM vs IAM: what is the difference?
Identity and access management (IAM) manages every identity and what it can access: accounts, single sign-on, MFA, roles and provisioning. PAM is the part of identity security focused on the small set of access that can do the most damage, with extra controls that IAM alone doesn’t apply.
| IAM | PAM | |
|---|---|---|
| Scope | Every user and application | Privileged users, privileged accounts and non-human identities |
| Main question | Who are you, and which apps and roles can you use? | Should you have this access right now, and what are you doing with it? |
| Typical controls | SSO, MFA, provisioning, role-based access | Credential brokering, JIT access, session recording, command and query controls |
| Access model | Mostly standing role assignments | Time-bound, approved, revoked automatically |
| Audit focus | Who holds which account or role | What each privileged session did |
The two work together: the identity provider authenticates the person, and the PAM layer uses that identity to decide on, and record, each privileged session. That’s why “is this product PAM or IAM?” often gets the answer “both”: many identity platforms include some PAM features, and PAM tools depend on an identity provider.
PAM vs PIM: are they the same thing?
Not quite, though the terms overlap. Privileged identity management (PIM) usually means managing which identities hold privileged roles: who is eligible, who can activate a role, for how long and with whose approval. PAM is broader: it also governs the sessions those roles open, with credential brokering, command and query controls, and session recording.
The best-known use of the term is Microsoft Entra Privileged Identity Management, a service in Microsoft Entra ID. As of November 2026, Microsoft documents time-based and approval-based role activation, just-in-time access and audit history for resources in Microsoft Entra ID, Azure and other Microsoft Online Services. Privileged role assignments in those services are one part of a PAM program.
Privileged access vs privileged account management
Privileged account management focuses on the accounts: finding every privileged account, vaulting its credentials, rotating them and removing the ones nobody uses. Privileged access management is broader. It also controls how and when those accounts get used: who gets access, for how long, what they can run and what gets recorded.
Many vendors and analysts use the two terms interchangeably, and both shorten to PAM. The difference that matters in practice: managing accounts tells you who could act; managing access tells you who did act, and what they did.
Privileged access management for AI agents
AI agents that query databases, run shell commands or call internal APIs hold privileged access, often in a riskier form than people do. An agent works fast, can be steered by instructions hidden in the content it reads (prompt injection), and often runs with a credential nobody has reviewed.
The common shortcut, a shared database password or long-lived API key in the agent’s environment, gives every agent session standing access with no record of who asked for what. The PAM principles still apply, adapted to a non-human identity acting on someone’s behalf:
- Its own short-lived identity: the agent authenticates with a token that expires, such as an OIDC token issued by its platform, not a static secret.
- Tied to a human: every session records the person who started the agent, so policy and audit can use both identities.
- Blocked by default, approved per task: the agent requests access for a task, a person approves it, and the access expires on its own.
- Every action checked: each query or command is evaluated against policy, and read-only rules and masking still apply after approval.
Formal’s docs walk through this pattern for Devin, a cloud coding agent (guide). Devin authenticates with its own short-lived OIDC token, which Formal maps to a machine user and to the person who started the session. A policy blocks that machine user by default. When Devin needs data, the requester approves in Slack, which suspends the block for that requester and Devin session only, until the requested duration expires.
How to implement privileged access management
Order the work by risk and start with the most sensitive systems. A practical sequence:
- Inventory privileged access. List the databases, hosts, clusters, cloud roles, service accounts and agents that hold privileged credentials, and who uses each one.
- Remove shared credentials. Move passwords and keys into a broker, so people and agents authenticate as themselves and never handle the upstream secret.
- Tie every session to a person. Use your identity provider for authentication, including for agents acting on someone’s behalf.
- Replace standing access with JIT. Make production access time-bound and approved.
- Enforce least privilege inside the session. Default to read-only, block destructive operations and mask sensitive fields.
- Record and review. Keep session logs, alert on risky activity, and review who holds privileged access on a regular schedule.
How does Formal approach privileged access management?
Formal PAM is built on the Formal Connector, a protocol-aware reverse proxy that sits between users and protected resources such as Postgres, MySQL, Snowflake, MongoDB, SSH servers and Kubernetes clusters (Connector docs). People and agents connect with their own identity. The Connector authenticates upstream with Native Users, so Formal identities never need to know the upstream credentials.
Policies written in Rego can block, mask, filter or rewrite requests and responses. Sessions are logged, with recordings for SSH and Kubernetes. Time-bound policy suspensions, which a Workflow can create after an approval in Slack, provide just-in-time access. At Cursor, engineers have no standing production access: they request just-in-time access for a specific operational need instead of holding permanent production permissions.
Comparing PAM tools? See the Teleport alternative and StrongDM alternative pages, which Formal publishes.