In March 2019, a former Amazon employee exploited a misconfigured web application firewall at Capital One to reach an AWS IAM role that had far more access than the WAF needed — permissions to list and read every S3 bucket in the account. The breach exposed data on 106 million people and cost Capital One $80 million in regulatory fines. It's one of the clearest illustrations of what happens when the principle of least privilege (PoLP) is ignored: a security model where every user, process, and workload is granted only the minimum permissions required to perform its function, for the shortest time necessary, and nothing more. First formalized by Jerome Saltzer and Michael Schroeder in a 1975 paper on protecting information in computer systems, least privilege is now codified in NIST SP 800-53 (control AC-6) and sits at the core of zero-trust architecture. For teams managing cloud infrastructure, CI/CD pipelines, and third-party dependencies, it's one of the highest-leverage controls available.
What is the principle of least privilege?
The principle of least privilege is the rule that any user, application, service account, or system component should be granted access only to the specific data, resources, and actions it needs to complete its function — and no more. Saltzer and Schroeder's 1975 paper, "The Protection of Information in Computer Systems," described it as a design principle for operating systems, but it has since become foundational to nearly every security framework in use today: NIST SP 800-53 Rev. 5 (control AC-6), ISO/IEC 27001 Annex A.8.2, and CIS Controls v8 (Control 6) all require organizations to enforce it. In practice, PoLP means an application that only needs to read from one database table shouldn't have write access to the whole schema, and a CI job that builds a container image shouldn't hold credentials that can also delete production infrastructure.
How is least privilege different from zero trust?
Least privilege is a scoping rule; zero trust is the broader architecture that assumes no user, device, or network location is trusted by default. NIST SP 800-207, published in August 2020, defines zero trust as a model built on continuous verification of identity and context for every request, regardless of whether it originates inside or outside the network perimeter. Least privilege is one of the load-bearing components of that model — you can't have meaningful zero trust if every verified identity is then handed broad, standing access. Think of it this way: zero trust decides whether to trust a request right now, and least privilege decides how much access that request should be trusted with even after it's approved.
What happens when cloud identities violate least privilege?
When cloud identities hold more access than they need, a single compromised credential can turn into an organization-wide breach. In the September 2022 Uber incident, an attacker who social-engineered an employee's MFA found a PowerShell script on an internal share with hardcoded admin credentials for Uber's Thycotic privileged access management vault — that vault, in turn, held credentials with broad reach into Uber's AWS, GCP, Google Workspace, and Slack environments, letting the attacker post messages to company-wide channels within hours. Similarly, the SolarWinds SUNBURST campaign disclosed in December 2020 succeeded in part because compromised on-premises identity infrastructure was used to forge SAML tokens with sweeping Microsoft 365 API permissions, letting attackers read mail across an organization without ever touching a domain admin password directly. In both cases, the initial foothold was contained — the escalation came from downstream systems that trusted credentials with far more scope than the task at hand required.
What are the most common least-privilege violations in cloud and CI/CD environments?
The most common violation is the wildcard IAM policy — a permission statement using "Action": "*" or "Resource": "*" — which security teams still find attached to routine service roles during cloud audits years after AWS, Azure, and GCP all shipped scoped-permission tooling. A close second is long-lived static access keys issued to CI/CD systems instead of short-lived, auto-rotating tokens; the January 2021 Codecov breach began when attackers modified the company's Bash Uploader script to exfiltrate CI environment variables, and because many of those pipelines injected static cloud and source-control credentials with broad scope, the fallout spread to HashiCorp, which had to rotate a leaked GitHub signing key months later. A third recurring pattern is Kubernetes workloads running under the default service account, which historically carried more RBAC permissions than any given pod actually needed until the CIS Kubernetes Benchmark and the CISA/NSA Kubernetes Hardening Guide (updated March 2022) pushed teams toward explicit, minimal service-account bindings.
How do you implement least privilege in practice?
You implement least privilege by replacing broad, standing permissions with scoped, time-bound, and continuously right-sized access across every layer of the stack. In cloud IAM, that means using tools like AWS IAM Access Analyzer or GCP's Policy Analyzer to identify unused permissions and replace long-lived keys with short-lived STS or Workload Identity Federation tokens. In CI/CD, GitHub addressed this directly in 2021 by letting workflows set a permissions: block on the default GITHUB_TOKEN, scoping it down from repo-wide read/write to just the specific actions a given job needs (e.g., contents: read). In Kubernetes, that means defining Role-Based Access Control (RBAC) bindings per namespace and workload instead of granting cluster-admin, and applying Pod Security Admission to block containers from running as root. Across all of these, the discipline is the same: grant access just-in-time, scope it to the narrowest set of resources and actions, and revoke it automatically when it's no longer used.
What does poor privilege management cost organizations?
Poor privilege management makes breaches both more likely and more expensive to contain. IBM's 2023 Cost of a Data Breach Report put the global average breach cost at $4.45 million, and breaches involving stolen or compromised credentials were among the slowest to detect and contain — averaging roughly 328 days from intrusion to full containment, well above the 204-day mean time to identify a breach across all attack vectors that year. That gap exists because overprivileged accounts don't just get compromised — they let attackers move laterally through systems that trusted them, turning a single stolen token into access across databases, cloud storage, and source repositories before anyone notices the anomaly. Every layer of unnecessary access an identity carries is additional blast radius that a defender has to investigate during incident response, whether or not it was ever actually used.
How Safeguard Helps
Safeguard helps teams enforce least privilege at the points where it's hardest to verify by hand: dependencies, CI/CD pipelines, and runtime code paths. Reachability analysis traces whether a vulnerable function or overprivileged package is actually invoked by your application, so teams can prioritize the small set of findings where excess access or a risky dependency is genuinely exploitable instead of chasing every CVE in a lockfile. Griffin AI correlates SBOM data, pipeline permissions, and code paths to flag identities, tokens, and third-party actions that hold more scope than their observed usage requires. Safeguard generates and ingests SBOMs across your build pipeline to give security teams a live inventory of what has access to what, and its auto-fix PRs open scoped, reviewable changes — tightening an IAM policy, pinning a dependency, or narrowing a CI token — so least privilege becomes a continuous, enforced state rather than a one-time audit.