Principle of Least Privilege

The principle of least privilege (PoLP) states that every user, process, service, and credential should have exactly the permissions required to perform its function — and no more. By minimizing what each identity can do, you minimize what an attacker who hijacks it (or a buggy component) can damage. It is one of the oldest and most universally endorsed security principles.

How It Works

Least privilege is applied by scoping permissions tightly and by default denying everything not explicitly granted. In practice this means: human accounts get role-appropriate access rather than admin; service accounts get narrowly scoped IAM policies tied to the specific resources and actions they need; database users get only the tables and operations relevant to their app; and processes run as unprivileged users, not root. Permissions are reviewed and revoked as roles change (avoiding "privilege creep").

Modern implementations layer on just-in-time access (privileges granted temporarily and expiring automatically), just-enough access scopes, and separation of duties so no single identity can complete a sensitive action alone. Cloud IAM, Kubernetes RBAC, and OS file permissions are all vehicles for enforcing it.

When to Use It

Apply least privilege everywhere, always — it is a default posture, not a special-case control. It is especially critical for service-to-service credentials, CI/CD pipelines (which often hold powerful tokens), database access, cloud IAM roles, and any third-party integration. Compliance regimes (PCI DSS, SOC 2, HIPAA) explicitly require it.

Trade-offs

Fine-grained permissions are more work to design, grant, and maintain; over-restriction breaks workflows and pushes frustrated users toward workarounds or broad "temporary" grants that become permanent. Determining the true minimal set of permissions for a complex service is genuinely hard, often requiring iteration and access analyzers. There is tension between security and developer velocity, which just-in-time and self-service access tooling aims to ease. The cost is justified because least privilege dramatically shrinks the blast radius of any compromise.

Related Patterns

Least privilege is a core layer of defense in depth and a foundation of zero-trust segmentation, which assumes no implicit trust and enforces per-request authorization. Secrets rotation limits the lifetime of the credentials least privilege scopes. Secure-by-default ensures new resources start locked down rather than open.

Example

// AWS IAM policy: a service that may only read one S3 prefix
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::reports-bucket/daily/*"
  }]
}

The role can read objects under one prefix and nothing else — no write, no delete, no other buckets — so a leak of its credentials exposes only that narrow slice of data.