Privileged Access Management: Securing People and Machines

Privileged access is the shortest path from one compromised credential to a compromised organisation. Privileged access management (PAM) is the discipline of finding every identity that can change, read or destroy what matters most, then controlling how that power is granted, used, watched and removed. Much privileged activity is now performed by machines: pipelines deploying infrastructure, service accounts with administrative roles, automation calling cloud APIs and AI agents with write access. This guide explains what PAM covers, how its core capabilities work, why session-centric PAM struggles with non-human identities (NHIs), and how to design privilege controls for people, machines and agents together.

Key takeaways

Privilege is defined by what an identity can do, not what it is called. Service accounts, CI/CD deploy identities, cloud owner roles, secrets managers and AI agents with write access all belong in PAM scope.
The core capabilities are discovery, vaulting and rotation, checkout, session brokering and recording, just-in-time elevation and approvals. Zero standing privilege is the target state they work towards.
Classic PAM was built around interactive human sessions. Machines call APIs, have no session to broker and keep secrets in code and pipelines, so machine privilege needs short-lived credentials, workload identity federation and scoped tokens.
In the cloud, the most dangerous privileges are often indirect: passing a role, minting credentials for another identity or rewriting access policies. Guardrails cap what any single grant can do.
Break-glass accounts and AI agents sit at opposite edges of privilege design: one must work when everything else fails, the other must never exceed its task without a human decision.

What counts as privileged access

An identity is privileged when its permissions let it bypass or change security controls, administer other identities, or alter or destroy critical systems and data at scale. NIST SP 800-53 addresses this in two control families. Account management enhancement AC-2(7), privileged user accounts, asks organisations to administer privileged accounts under a role-based or attribute-based scheme, monitor privileged role assignments and changes, and revoke access that is no longer appropriate. Least privilege, AC-6, asks that users, and processes acting on their behalf, receive only the access their tasks need.

A realistic privileged inventory includes:

Human administrators: directory, database, network and cloud admins, plus developers who hold production access “temporarily” for months.
Break-glass accounts: emergency accounts that bypass normal controls by design.
Service accounts with admin rights: backup agents, monitoring tools and integration accounts granted broad roles because narrower ones were hard to define. These are among the non-human identities most often left out of PAM programmes.
Cloud root and owner identities: the AWS account root user, owners of Azure subscriptions and management groups, and organisation or project owners in Google Cloud.
CI/CD deploy identities: pipeline credentials that push code and infrastructure to production. Anyone who can edit the pipeline can usually borrow that privilege.
Secrets managers and PAM systems: an identity that can read the vault, change its policies or administer the PAM platform holds everything the vault protects.
OAuth and SaaS integrations: applications granted tenant-wide permissions to read every mailbox, file or record.
AI agents with write access: agents whose tools can modify code, infrastructure, records or payments.

The Uber breach write-up shows why these categories overlap: attackers found PowerShell scripts containing hard-coded credentials for a domain admin account linked to the company’s PAM solution, which gave them administrative control over secrets and reach into many internal systems. Excessive privilege is one of the top 10 NHI issues, and the OWASP Non-Human Identities Top 10 lists it as NHI5:2025 Overprivileged NHI.

Core privileged access management capabilities

Discovery

Discovery scans directories, servers, databases, cloud accounts, SaaS tenants and code repositories for admin accounts, service accounts, SSH keys, API keys and role assignments. It must resolve effective permissions, because a deeply nested group or a role that can grant itself more roles is as privileged as a direct admin assignment. It must also run continuously.

Credential vaulting and rotation

Vaulting moves privileged passwords, keys and secrets out of spreadsheets and scripts into an encrypted store with access control and an audit trail. Rotation then changes the credential on a schedule, after use, or when someone who knew it leaves. The challenges of rotating non-human identities are largely dependency problems: nobody knows every consumer of the secret.

Checkout

Checkout releases a vaulted credential to an authorised user or process for a limited time. The request is logged, may need a reason or ticket, and can trigger rotation at check-in so the value the user saw stops working. For machines, checkout is an authenticated API call at runtime rather than a copy stored in configuration.

Session brokering, recording and monitoring

A session broker (a privileged access proxy or jump host) sits between administrator and target. The user authenticates to the broker, the broker injects the credential so the user never sees it, and the session is recorded as video, keystrokes or command logs. NIST SP 800-53 AC-6(9) asks organisations to log the use of privileged functions; session recording meets it for interactive work.

Just-in-time elevation and approvals

Just-in-time (JIT) access replaces permanent admin rights with eligibility: the user may request a role and activates it for a bounded period when needed. Microsoft Entra Privileged Identity Management (PIM) is a platform example, offering eligible and time-bound assignments across Microsoft Entra ID, Azure, Microsoft 365 and Intune, with activation that can require MFA, justification and approval, plus notifications, access reviews and audit history. NIST SP 800-53 AC-2(6), dynamic privilege management, expresses the same idea. Approvals add a second person to high-risk actions, and work best when they are rare enough that approvers actually read them.

Zero standing privilege

Zero standing privilege (ZSP) is a target state in which no identity, human or machine, holds persistent privileged permissions. Privilege exists only while it is used: granted at the time of need, scoped to a task and resource, short-lived, and removed automatically afterwards. ZSP is a design principle, not a product feature, and is rarely absolute: break-glass accounts are a deliberate exception. The practical aim is to make standing privilege the documented exception and to shrink the window in which a stolen credential is useful.

Human versus machine privileged access

The principles are shared, but the mechanics differ at almost every step. The governance processes behind role assignment, such as access requests, certification and reviews, are covered in IAM and IGA Basics.

Aspect	Human privileged access	Machine privileged access
How it is granted	Role assignment or eligibility tied to a named person and a joiner, mover, leaver process	Role or policy attached to a service account or workload at creation, often by an engineer, with no lifecycle trigger
How it is used	Interactive sign-in, console, remote desktop or SSH	API calls, SDK requests and scheduled jobs, with no person present
Session or API	Discrete sessions a broker can proxy, record and terminate	No interactive session; a continuous stream of requests signed with a key or token
Authentication	Password plus MFA, ideally phishing-resistant	API key, client secret, certificate, platform-issued token or federated workload identity
Rotation	Credential rotated at checkout and check-in	Rotation risks outages unless consumers fetch credentials dynamically; best replaced by short-lived credentials
Monitoring	Session recording, command logs, sign-in anomalies	Cloud audit logs and API telemetry compared with expected workload behaviour
Review	Periodic review by manager or role owner	Needs an accountable owner first; compares permissions used with permissions granted
Typical failure	Permanent admin rights, shared admin accounts, weak MFA	Over-scoped roles, hard-coded secrets, orphaned accounts, humans reusing machine credentials

The last row matters. When a person signs in with a service account’s credentials, the machine identity becomes an unmonitored human admin account. OWASP lists this as NHI10:2025 Human Use of NHI.

Why classic PAM struggles with non-human identities

Traditional PAM assumes a person requests access, a session opens and is recorded, and the credential rotates when it ends. Little of that holds for machines.

Access is API-driven. A pipeline or backup agent calls APIs directly; there is no desktop session to broker or watch.
There is no session end. Machine credentials are used continuously, so “rotate after use” has no natural trigger.
Secrets live where they are consumed. Keys end up in code, configuration, container images and CI/CD variables. Every copy is a privileged credential outside the vault, which is how secret sprawl undermines vaulting.
Scale and churn. Automation creates and destroys machine identities faster than an onboarding process designed for named administrators can follow.
Unclear ownership. If nobody owns a service account, nobody approves its rotation or retirement. The key challenges and risks of NHIs apply directly to machine privilege.

Privileged tooling is itself a target. In the BeyondTrust API key breach, attackers obtained an API key for a remote support SaaS service that allowed them to reset passwords for local application accounts, and the US Treasury later reported a major incident. One machine credential for a privileged access tool opened customer environments.

Approaches that fit machine privilege

Secrets managers with runtime retrieval. Workloads authenticate with their own identity and fetch secrets on demand instead of holding copies, which centralises audit and allows rotation without redeployment.
Short-lived dynamic credentials. Credentials are issued per workload or request and expire on their own. AWS documents that temporary security credentials from AWS STS last from minutes to hours, need not be embedded in applications and cannot be reused after expiry. The trade-offs are covered in static versus dynamic secrets.
Workload identity federation. A workload presents a token issued by its platform, such as a Kubernetes service account token or a CI/CD job’s OIDC token, and exchanges it for short-lived cloud credentials, so no long-lived secret exists. See the Cloud Workload Identity Guide.
Scoped tokens. Tokens restricted by audience, resource and action mean a stolen credential grants little. The NHI Authentication Guide covers audience restriction and token binding.
Pipeline controls as privilege controls. Protected branches, required review of pipeline definitions and environment approval gates are PAM controls. The CI/CD pipeline exploitation case study describes plain-text SSH credentials in a pipeline configuration and a modified pipeline used to gain SSH access to a production server.

The shift is from protecting a secret to removing the need for one.

Cloud privilege: root, owners and escalation paths

Root and owner identities

The AWS account root user has complete access to the account and should be used only for tasks that require it. AWS’s root user best practices include a strong password, MFA, no root access keys, multi-person control that separates custody of the password from custody of the MFA device, a group email address, restricted access to recovery mechanisms, and monitoring of root activity. For member accounts in AWS Organizations, AWS recommends centralising root access and removing member account root credentials altogether. Treat equivalent top-level identities in every cloud as break-glass or JIT identities, never daily working accounts.

Privilege escalation through IAM permissions

Many escalation paths use permissions that only look administrative on close reading:

Passing a role to a service. In AWS, iam:PassRole lets an identity attach a role to a service such as EC2 or Lambda. AWS warns that if the role has more permissions than the user, the service can act with those permissions on the user’s behalf.
Minting credentials for another identity. Permissions to create keys for, or tokens as, another identity let the holder become it. In Google Cloud, iam.serviceAccounts.getAccessToken, part of the Service Account Token Creator role, allows impersonation of a service account.
Rewriting policy. An identity that can edit IAM policies, role definitions or resource policies can grant itself more access.
Changing access to secrets stores. The Azure Key Vault privilege escalation exposure describes the Key Vault Contributor role, meant for managing vaults, including Microsoft.KeyVault/vaults/write, which lets a holder change vault access policies and grant itself access to secrets, keys and certificates. Microsoft classified this as by design and updated its documentation.
Controlling code that runs with privilege. Write access to a function, VM, pipeline or image that runs under a privileged identity is effectively that privilege.

Platform flaws can also collapse boundaries. The Microsoft Entra ID flaw write-up describes legacy actor tokens that could be reused across tenants to impersonate any user, including Global Administrators, without being logged, before Microsoft patched it.

Guardrails that cap privilege

AWS permissions boundaries set the maximum permissions an identity-based policy can grant a user or role. They grant nothing themselves; effective permissions are the intersection.
AWS service control policies limit the maximum permissions of users, roles and the root user in member accounts. They do not apply to the management account, which therefore needs especially tight control.
Google Cloud IAM deny policies attach at organisation, folder or project level, are inherited, and are checked before allow policies, so a denied permission cannot be used whatever roles a principal holds.
Microsoft Entra PIM can make Azure resource roles eligible rather than permanent, adding activation controls to the highest cloud privileges.

Point guardrails at the escalation permissions above, and deny changes to the guardrails themselves.

Break-glass and emergency access design

Break-glass accounts exist for the day normal access fails: the identity provider is down, MFA is broken, a policy locks every administrator out. NIST SP 800-53 AC-2(2) addresses automated management of temporary and emergency accounts.

Microsoft’s guidance on emergency access accounts in Microsoft Entra ID is a clear platform example. It recommends more than one emergency account; cloud-only accounts on the .onmicrosoft.com domain with no dependency on federation; the Global Administrator role assigned as active permanent rather than eligible in PIM; phishing-resistant passwordless authentication such as passkeys (FIDO2) or certificate-based authentication; exclusion from Conditional Access policies that could block sign-in; alerts on every use; and regular validation.

Principles that apply on any platform:

Independence: the account must not depend on the systems it is meant to recover.
Split custody: no single person can use it alone, as AWS recommends for root password and MFA.
Loud use: every sign-in pages the security team. Silent use is an incident.
Regular testing: test sign-in on a schedule, then review and, where applicable, rotate.
No routine work: a convenient break-glass account becomes standing privilege without controls.

Accounts outside normal governance attract attackers. The Microsoft Midnight Blizzard breach write-up describes password spraying against a legacy test tenant account without MFA, followed by access to OAuth applications that granted escalated privileges and reached executive mailboxes.

Privileged access for AI agents

An AI agent that can write to production systems holds privileged access whether or not anyone labelled it that way. The OWASP Top 10 for LLM Applications calls the risk Excessive Agency (LLM06:2025), with root causes of excessive functionality, permissions and autonomy. NHIMG’s guide to the OWASP Top 10 for agentic applications covers agent-specific risks in depth.

Tool permissions

Treat each tool as a privilege. Give the agent only the tools the task needs, give each tool the narrowest downstream permissions, and prefer read-only tools. A tool that runs arbitrary shell or SQL is an admin credential in disguise. The Replit AI tool incident write-up describes an agent running destructive commands against a production database during a code freeze; the instructions not to make changes were not technically enforced, and no gated approval or role blocked the action.

Human approval for high-impact actions

Define high-impact actions (deletions, permission changes, payments, deployments, bulk export, fleet-wide device actions) and require a human decision before execution, enforced by the tool or target system rather than by a prompt. The same logic applies to human admins: the Stryker Microsoft Intune wiper attack write-up argues that one compromised administrator session should not be able to issue a fleet-wide wipe, and recommends multi-admin approval and separation of duties.

Delegation

When an agent acts for a user, it should act with that user’s authority narrowed to the task, not through a shared high-privilege service account. OWASP recommends executing extensions in the user’s context with minimum privileges. In practice: a distinct identity per agent, delegated short-lived tokens restricted by audience, logs that record both the agent and the user it represented, and write privilege held only for the duration of an approved task.

Measuring PAM coverage and common failure patterns

What to measure

Counting vaulted accounts says little about risk. Track these as trends instead:

Discovery coverage: the proportion of platforms, cloud accounts and SaaS tenants scanned for privileged human and machine identities.
Standing privilege: permanent versus eligible or JIT privileged assignments, split by human and machine.
Credential posture: privileged machine identities on long-lived secrets versus short-lived or federated credentials, and the age of the oldest privileged secret.
Ownership: privileged NHIs with a named, current owner.
Unused privilege: permissions granted but not exercised during a review period.
Escalation exposure: identities holding role-passing, credential-minting or policy-editing permissions outside approved administrators.
Detection and response: whether root, owner and break-glass activity raises alerts, and how quickly a privileged credential can be revoked.

Common failure patterns

Human-only scope: admin accounts are governed while service accounts, pipelines and OAuth applications with equal privilege are not.
Vault bypass: credentials are vaulted, then copied into scripts and CI/CD variables. Finding those copies is part of NHI lifecycle management.
An exposed control plane: admin credentials for the PAM platform or secrets manager are stored insecurely or granted widely, as the Uber breach showed.
Standing admin by exception: JIT is deployed, then permanent exceptions accumulate for convenience.
Unwatched cloud consoles and APIs: server sessions are recorded while more powerful cloud control-plane activity is not monitored with the same care.
Social engineering around PAM: help desk resets and MFA enrolment hand attackers privileged identities without touching the vault. The Storm-2949 Azure breach write-up describes self-service password reset social engineering, Microsoft Graph queries to find privileged identities, and a pivot into Key Vault, storage and virtual machines. Hardening those flows is part of workforce identity security.

Practitioner checklist

Define privilege by capability and include service accounts, CI/CD identities, cloud owners, secrets managers, OAuth applications and AI agents in scope.
Run continuous discovery of privileged identities and effective permissions.
Assign an accountable owner to every privileged machine identity.
Move human admins to eligible, just-in-time roles with MFA, justification and approval for the highest-impact roles.
Separate daily and privileged accounts, and stop people signing in with machine credentials.
Replace long-lived privileged machine secrets with short-lived or federated credentials; vault and auto-rotate the rest.
Scan code, images, pipelines and configuration for privileged secrets outside the vault.
Protect pipeline definitions with review and branch protection, and gate production deploys.
Remove root access keys, centralise or tightly control root and owner identities, and alert on their use.
Restrict role passing, credential minting, policy editing and secrets store policy changes, and enforce limits with guardrails.
Build break-glass accounts that are independent, split-custody, loud and regularly tested.
Give AI agents their own identities, minimal tools, delegated short-lived tokens and enforced human approval for high-impact actions.
Log every privileged function, review unused privilege regularly, and protect the PAM platform and secrets manager as tier-zero assets.

Standards and references

Related NHI Mgmt Group resources: The Ultimate Guide to Non-Human Identities · NHI Lifecycle Management Guide · NHI Breaches Report · Top 10 NHI Issues

Privileged Access Management Guide