Skip to content

CONCEPT Cited by 9 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-09-24-databricks-how-i-built-agent-based-security-reviews-on-databricks — least privilege applied to agent authority. Rather than one agent with broad authority to "act as a security reviewer," the system gives each of seven agents a bounded responsibility (collect context, assess risk, map to standards, draft requirements, manage follow-ups, or prepare a handoff) — no single agent can approve on its own, and automated completion is confined to predefined low-risk request classes. This is the least-privilege principle applied at the agent-capability layer: scope each reasoning component to the minimum authority its job requires, so a fault in one cannot escalate into an unauthorized approval. Pairs with patterns/specialized-agent-decomposition and concepts/human-in-the-loop. (Source: sources/2026-09-24-databricks-how-i-built-agent-based-security-reviews-on-databricks)

  • 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.
  • sources/2026-07-23-databricks-intent-based-authorization-omnigent — Databricks extends least privilege to the purpose axis for AI agents: intent-based authorization restricts what an agent may do for this session even when identity allows more. Least privilege at identity layer narrows the ceiling; intent narrows the effective floor per task.
  • sources/2026-09-24-atlassian-how-we-automated-feature-flag-cleanup-with-agentic-pipelines — least privilege on the per-pipeline-step CI-agent axis. Atlassian's feature-flag-cleanup coding agent runs as a Bitbucket Agentic Pipeline step whose auth.system.scopes declare exactly read:repository, write:repository, write:pullrequest — nothing more — and repositories are configured with branch restrictions preventing agents from pushing directly to main. Stated rationale: "the agent only needs to read and write the specific ticket system and open pull requests. Task-specific auth tokens limit the damage if a run goes wrong." Scoping the blast radius of a misbehaving agent run to a PR-open capability, never a direct-to-main write. See patterns/dispatcher-coding-agent-closer.

Cloudflare Workers: resource-scoped roles for agents and CI (2026-09-15)

Cloudflare Workers applies least privilege on the per-resource + non-human-identity axis: you grant a teammate or agent access to one specific Worker via a role × scope grant, rather than account-wide access. The explicit motivation is the AI-agent failure mode — "the last thing you want is for an agent to make a change in production, just because it was granted more access than it needs." An agent (or a CI/CD workflow) is handed an API token scoped to one Worker with the least role that lets it do its job — Metadata Read-Only to debug from logs/traces without seeing source, Content Read-Only for a review agent, Editor for a CI deploy that must not be able to delete. A leaked token's blast radius is bounded to that one application. Two supporting mechanisms keep grants minimal: permission composition (a route change needs Editor-on-Worker and Workers-Routes-on-zone, never broad zone access, and subsequent version deploys need neither if the connection is unchanged), and contextual 403 errors that name the exact missing permission so callers request the minimal grant instead of over-provisioning. See fine-grained authorization for the role×scope model. (Source: sources/2026-09-15-cloudflare-workers-granular-authorization)

  • systems/himeji — authorization substrate
  • identity-decoupling — complementary privacy primitive
  • concepts/ephemeral-credentials — the temporal axis of least privilege (short credential lifetimes bound the blast radius of a leak)
  • concepts/fine-grained-authorization — the evaluation model that expresses least-privileged at API + data boundaries
  • concepts/tenant-isolation — least-privileged at the tenant-boundary scope
  • systems/amazon-verified-permissions — managed Cedar engine for runtime enforcement
  • concepts/fine-grained-authorization — least privilege at the session-purpose layer: constrains what the agent may do for this task, complementing identity-layer restrictions
  • systems/omnigent — Databricks agent framework implementing session-scoped least privilege via intent policies
  • optional-oauth-scopes — least privilege on the consent axis: the resource owner narrows the grant at authorization time
  • partial-grant-handling — the runtime obligation that makes consent-time narrowing safe

Cloudflare OS: initial grant plus downstream-use constraint (2026-08-05)

Cloudflare OS adds an agent-workspace axis to least privilege. Agents and generated apps start with access to nothing; a Gatekeeper grants a resource-specific typed capability and retains the credential. That initial narrow grant is not treated as sufficient forever: resources subsequently observed by the agent are recorded and checked before collaboration, output viewing, hand-off, external writes, and egress. See observed-resource-provenance and observation-coupled-authorization. (Source: sources/2026-08-05-cloudflare-os-an-open-platform-for-agents-apps-and-work)

Cloudflare's optional OAuth scopes move a slice of least-privilege enforcement to the user, at consent time. A client marks some requested scopes optional; the consent screen lets the user deselect them and grant a narrower subset, evaluated against the current authorization request. This is least privilege chosen by the resource owner rather than baked into a policy engine or the client's registration. It pairs with a runtime obligation — partial-grant-handling — where the client must operate within whatever subset it receives instead of assuming the full request. Cloudflare frames graceful partial-grant handling (notably for agents / MCP servers, which tend to over-request) as a trust signal: an app that respects the user's narrowing is one users are comfortable authorizing. (Source: sources/2026-08-20-cloudflare-from-all-or-nothing-to-task-based-oauth-consent)

Merged aliases

  • least-privilege- data-minimization
  • permission-creep
  • separation-of-duties-data-governance
  • token-scoped-access

Seen in

Last updated · 766 distilled / 2,225 read