Skip to content

CONCEPT Cited by 4 sources

Least-privileged access

Each actor — user, service, operator — sees only the data and gets only the capabilities strictly required for their current interaction. Longstanding security principle; in modern platforms it increasingly means enforcement at the data layer (not just the UI or API gateway) so bugs in any one path can't leak more than the policy allows.

Seen in

  • sources/2026-04-14-airbnb-privacy-first-connections — Airbnb applies least-privileged access across fellow travelers, hosts, and Airbnb support personnel. Enforcement lives in systems/himeji at the data layer, so privacy holds even if a specific endpoint is buggy.
  • sources/2026-04-21-figma-enforcing-device-trust-on-code-changes — Figma builds its commit-signature verifier as a GitHub App scoped to the minimum two permissions it needs: read code + write commit status checks. Named as team principle: "we use GitHub Apps to build secure, least privileged tools that interact with the GitHub API." Enforcement at the integration-scope layer — a compromise of the App can post bad statuses, but cannot touch code or settings.
  • sources/2026-02-05-aws-convera-verified-permissions-fine-grained-authorization — Convera applies least-privileged access at the API layer via fine-grained Cedar policies evaluated per request by AVP. Across four usage modes (customer UI + API, internal customer-service apps, machine-to-machine, multi-tenant SaaS) only-what-you-need is enforced by (1) role/attribute-gated policies (a payment initiator may see a Transfer button only when the account is BUSINESS + ACTIVE), (2) narrow-scope internal-user policies (view-only basic profile, edit only contact preferences, block sensitive financial data), (3) per-service policy stores limiting each service's callable operations, and (4) per-tenant policy stores plus backend re-verification so a bug in any single tier cannot widen privilege beyond the policy.
  • sources/2025-03-25-cloudflare-opkssh-open-sourcing — OPKSSH applies least-privileged on the temporal axis: default 24h-lifetime SSH keys instead of the long-lived accumulation pattern that leaves ~10% of historical keys granting root. Each login mints a fresh key, paired with identity-based ACL so off-boarding is one IdP-directory update, not a fleet-wide authorized_keys sweep. Canonical ephemeral-credentials instantiation for user SSH access.
Last updated · 200 distilled / 1,178 read