Birthright Access vs Least Privilege: Scoping Defaults

Every identity starts with defaults it never asked for, and those defaults are where least privilege is most often lost without anyone making a decision. Birthright access gives people what their role predictably needs on day one; least privilege says nobody should hold access they do not need. The two are compatible only if the default is scoped deliberately, removed by rule and measured against use. This guide covers where they conflict, how role creep and movers erode the default, what auditors test, and the defaults platforms hand to workloads, pipelines and AI agents. It is for IGA architects, IAM engineers and platform owners. The mechanics of building birthright layers are in the Birthright Access Design Guide, and the time dimension of privilege in Zero Standing Privilege vs Least Privilege.

Key takeaways

Birthright is least privilege applied to a population, not an exception to it. NIST SP 800-53 AC-6 allows only access necessary to accomplish assigned tasks; birthright is valid where that need is predictable for everyone in a group.
The risk is accumulation, not the default. A tightly scoped day-one bundle becomes standing excess when movers keep old access, requests stack on top and rules add without removing.
Auditors test the rule and the exceptions. Expect to show the policy that defines the default, evidence that rules remove access on move, and reviews of everything granted outside the rule.
Platforms give machines birthright too. Default service accounts, default workflow tokens and default directory permissions are birthright for non-human identities, and some are broader than any human bundle you would approve.
Agents should start with nothing. OWASP LLM06:2025 Excessive Agency names excessive functionality, permissions and autonomy as root causes, so an agent's default is an empty tool list plus a scoped, owned identity.

The short answer

Keep birthright, but define it as the smallest set of low-impact access that nearly everyone in a defined population uses, grant it from authoritative attributes, and make the same rule remove it. Everything else, including access most of a team wants but not all of them use, goes behind a request with an owner and an end date. For non-human identities the default should be no access at all: turn off platform defaults that grant broad roles, give each workload or agent its own identity, and grant only what its declared purpose needs. Least privilege is the test you apply to the birthright design; birthright is the delivery mechanism for access that passes the test.

Where the two principles conflict

Dimension	Birthright access	Least privilege	How to reconcile
Unit of decision	A population (worker type, department, location)	An individual task or identity	Only include access whose need is true for the whole population
Trigger	Attribute change, no request	Demonstrated need, usually a request	Attribute rules for the predictable core; requests for the rest
Approval	Pre-approved once, at design time	Approved per grant	Owner signs off the rule and re-certifies it on a schedule
Removal	Automatic when the attribute changes, if designed that way	On review, expiry or revocation	Same rule adds and removes; requested access carries an end date
Scope tendency	Grows, because adding is popular and removing is not	Shrinks, because each grant is challenged	Usage data decides what stays in the default
Review burden	Low per user, high per rule	High per user	Certify rules and exceptions, not every birthright assignment

The real conflict is the grey zone of access that most, but not all, of a population uses. Usage data settles it: if a measurable share of the population never touches the entitlement within a set period, it does not belong in the default.

Scoping the default: a least privilege test for birthright

The Birthright Access Design Guide uses a three-part test (breadth, low impact, deterministic). Applying least privilege adds questions about the shape of each entitlement, not just whether to include it.

Question	Birthright-safe answer	If the answer is no
Is the access read-only, or scoped to the user's own data?	Yes: self-service, own mailbox, read access to a team space	Split it: read in birthright, write by request
Does it touch regulated or confidential data classes?	No	Request with data owner approval
Can the holder change something other people rely on?	No	Request; consider time-bound access
Can it be used to grant further access (create groups, register apps, invite others)?	No	Remove from the default and delegate to a role
Does it participate in a segregation of duties rule?	No	Never birthright; request with SoD check
Will more than a set share of the population use it within 60 to 90 days?	Yes, shown by usage data	Move to request with a pre-approved fast path
Is the driving attribute authoritative and coded?	Yes: department code, worker type from HR	Fix the data before automating the rule

The fourth question is the one most often missed, because the capability is granted by platform defaults rather than by an access package anyone designed. Microsoft's documentation on default user permissions lists, for member users in Microsoft Entra ID, the ability to register applications, invite B2B guests, create security groups and Microsoft 365 groups and read most directory information. Each lets any user create new identities or grant access, and each is restrictable in User settings (see the NHI table below). Review equivalent tenant-wide defaults in every identity platform and collaboration suite.

How the default turns into standing excess

Birthright fails in predictable ways. The threat model: a compromised ordinary account carries more access than its owner's current job needs, widening the blast radius of phishing, token theft or insider misuse.

Movers who keep both bundles: the new department's layer is added but the old one is not removed, often because removal was never configured or because a grace period has no end. Two moves later the person holds three departments' drives.
Requests stacked on birthright: access granted by request sits outside the rule, so a department change does not touch it. The rule removes only what the rule granted; Microsoft's automatic assignment documentation, for example, describes assignments being removed when an identity no longer matches the rule, which says nothing about access granted by other routes.
Overlapping rules: two rules that grant the same access to overlapping populations behave unpredictably on move. Microsoft recommends one automatic assignment policy per access package and states that overlap is not supported and can cause access to be lost when a user leaves one scope but not the other.
Rule logic that depends on other groups: nested or chained membership hides why someone has access. Microsoft's automatic assignment page notes that the preview memberOf operator ends on 3 November 2026, after which policies using it are quarantined and stop adding or removing assignments, a reminder that rule dependencies need their own inventory.
Non-human identities caught by human rules: service and test accounts created in a department OU or with HR-like attributes inherit human birthright they do not need.

See the Joiner-Mover-Leaver Guide for lifecycle controls and the Role Mining and Role Design Guide for keeping role bundles small.

What auditors look for

Auditors rarely object to birthright as a concept. They object when it cannot be explained, when it never shrinks, and when it is used to avoid approvals for sensitive access. Prepare evidence along these lines.

Audit question	Evidence that answers it	Control reference
Who decided what is in the default, and when was it last reviewed?	Approved birthright policy listing each layer, its attribute, contents and owner, with a dated re-certification	NIST SP 800-53 AC-6; CSF 2.0 PR.AA-05
Does the default exclude privileged and SoD-sensitive access?	Rule definitions showing no admin roles or SoD entitlements; automated check that fails a rule change adding them	AC-6(7) Review of User Privileges; ISO/IEC 27001:2022 A.8.2
Is access removed when people move or leave?	Sample of movers showing old layer removed within the stated window; leaver sample showing disablement	AC-2 Account Management; AC-2(3) Disable Accounts
How is access outside birthright controlled?	Request records with approver and end date; review campaigns covering requested access on move	AC-6(7); ISO/IEC 27001:2022 A.5.18
Is provisioning automated and logged?	Rule engine logs of add and remove events tied to attribute changes	AC-2(1) Automated System Account Management
Are non-human identities excluded from human rules and separately owned?	Inventory of service accounts and agents with owners; rule filters excluding them	AC-2; CSF 2.0 PR.AA-01

Certify the rules and the exceptions, not every birthright assignment: re-approving email access for every report each quarter trains managers to approve everything. See the Access Reviews Guide.

Birthright for non-human identities and agents

Non-human identities rarely receive birthright from an IGA rule. They receive it from platform defaults: what a new workload, pipeline or application identity gets automatically, before anyone grants anything. The table shows documented defaults and the customer-side setting for each. Platforms are listed alphabetically; this is a reference, not a comparison.

Platform	Default identity or token	Documented default	Customer-side control
GitHub Actions	GITHUB_TOKEN created per job	Repository or organisation setting chooses permissive (read and write for all scopes) or restricted (read for contents and packages); new personal repositories default to restricted, organisation repositories inherit the organisation setting	Settings, Actions, General, Workflow permissions; per workflow or job permissions key; "Allow GitHub Actions to create and approve pull requests" left off unless needed
Google Cloud	Compute Engine and App Engine default service accounts, created automatically when the services are enabled	Depending on organisation policy, may be granted the Editor role on the project automatically	Enforce the constraint iam.automaticIamGrantsForDefaultServiceAccounts (enforced by default for organisations created after 3 May 2024); replace Editor with narrower roles after checking impact with Policy Simulator
Kubernetes	ServiceAccount named default in every namespace, assigned to any Pod that does not name one	No permissions beyond the API discovery granted to all authenticated principals when RBAC is enabled; credentials mounted into Pods by default	Dedicated ServiceAccount per workload with minimal RBAC; automountServiceAccountToken set to false where the workload does not call the API
Microsoft Entra ID	Default permissions of member users (which also shape what users can create for applications)	Members can register applications, invite guests, create security and Microsoft 365 groups and read most directory information	User settings: Register applications set to No with the Application Developer role for named users; restrict group and tenant creation

A default with no permissions can still be a risk if its credential is distributed everywhere: the Kubernetes default ServiceAccount has almost no rights, but the moment someone binds a role to it, every Pod in the namespace inherits that role. Conversely, a default with broad rights turns every new workload into a privileged one: a Google Cloud default service account with Editor gives any VM using it wide write access to the project, which is why Google strongly recommends disabling the automatic grant. See How to find GCP default service accounts in use, the Kubernetes Service Account Token Guide and the GitHub and GitHub Actions Security Guide.

AI agents: start from zero

OWASP's LLM06:2025 Excessive Agency describes the root causes as excessive functionality (tools the agent does not need, including ones left over from development), excessive permissions (an identity with update or delete rights when it only needs to read) and excessive autonomy (high-impact actions without human approval). Each is a birthright problem.

Default tool list: empty. Tools are added per declared use case, and a tool that exposes write or delete operations is separate from its read-only equivalent.
Default identity: a dedicated identity per agent with an owner, never a shared service account and never the deploying user's own access. See AI Agent Identity vs Service Account.
Default data scope: the minimum dataset for the use case, read-only unless a write is the purpose.
Default autonomy: human approval for any action that changes state outside the agent's own workspace until monitoring shows it is safe to relax.
Template, not copy: a new agent gets a reviewed permission template for its class, never a copy of another agent's grants. The AI Agent Permission Matrix Template is a starting point, and the Agent Permission Drift guide covers how grants grow afterwards.

Decision guidance

Situation	Put in birthright?	Alternative
Access used by nearly all of a department, read-only, no regulated data	Yes, department layer	None needed
Tool most of a team uses, showing customer personal data	Read-only or redacted view only	Full view by request with data owner approval
Write access to shared engineering repositories	No	Request with team owner approval; pre-approved fast path for the job family
Ability to register applications or create groups	No	Delegated role for named users
Contractors in the same department as employees	Separate, smaller contractor layer	Sponsor-approved requests with end dates
New workload or pipeline identity	No platform default with broad roles	Dedicated identity, minimal role, short-lived credentials
New AI agent	No default access at all	Class template, owner, approval for state-changing actions

Small organisations: one enterprise layer and a handful of department rules are enough; spend effort on turning off broad platform defaults, which is usually a one-time setting change. Large organisations: the grey zone is where effort goes; use usage data to prune the default annually, and certify rules rather than assignments so reviewers can focus on requested and privileged access.

Worked scenarios

Scenario 1: an engineer who moved twice

A review finds an engineer with write access to finance shared drives and a customer support tool. The history shows a move from support to finance operations and then to engineering. Department birthright was removed on each move, but the support tool and a finance reporting role had been granted by request, so no rule removed them. The fix is twofold: requested access now carries an end date at grant time, and every department change triggers a manager review of requested access within 14 days. The support tool is split into a redacted view, which stays in the support layer, and a full view by request.

Scenario 2: a new agent and a new pipeline in the same week

A team deploys a document summarisation agent and a build pipeline. The pipeline's repository sits in an organisation that still uses the permissive GITHUB_TOKEN default, and its deploy job runs on a VM using a Google Cloud default service account with Editor. The agent was given a copy of the platform team's service account. Applying the zero default: the organisation switches workflow permissions to restricted and the pipeline declares only the scopes each job needs; the VM moves to a dedicated service account with a deployment role; the agent receives its own identity with read access to one document library and a single summarise tool, with an owner recorded.

How to implement

Inventory defaults: list every birthright layer and every platform default (directory user settings, cloud default service accounts, CI token defaults, Kubernetes service account usage, agent platform defaults) with what each grants.
Apply the scoping test: run each entitlement through the questions above; mark items to split, move to request or remove.
Measure use before removing: pull 60 to 90 days of usage for candidate items; communicate the change and the fast path before it lands.
Pilot in one population: change one department's layer or one cloud folder's defaults first; watch helpdesk tickets and request volume.
Fix removal paths: confirm that every rule removes on move, add end dates to requested access and trigger mover reviews.
Turn off broad platform defaults: enforce organisation policies and tenant settings, starting in audit or report mode where the platform offers it, then enforce.
Set the agent baseline: publish permission templates per agent class and block deployment of agents without an owner and a declared scope.
Roll back safely: keep the previous rule definition versioned; if a change breaks work, restore the item for the affected population with an expiry while the root cause is fixed, rather than reverting the whole layer.

Detection and measurement

Rule engine and provisioning logs: add and remove events per attribute change; alerts when a mover's old layer is still present after the overlap window.
Configuration monitoring: drift alerts when tenant user settings, organisation policies or CI token defaults are relaxed, and when a role is bound to a default service account.
Usage analytics: per-entitlement usage within each layer and cloud last-accessed data for workloads; AWS's IAM best practices recommend using last accessed information to remove unused permissions and generating policies from access activity.

Metrics:

Share of birthright entitlements used by at least the agreed share of their population in the last 90 days.
Median and 95th percentile time to remove the old layer after a move.
Requested entitlements without an end date, as a share of all requested access.
Count of workload identities using a platform default identity or default token setting.
AI agents without a named owner or declared permission template: target zero.
Entitlements per user by tenure band, which exposes accumulation in long-serving staff.

Common failure patterns

Using birthright to skip approvals: sensitive access is added to a department layer because the approval process is slow. Fix the process, not the default.
Copying a peer's access for a joiner: "same as a colleague" imports that colleague's history of moves and requests, the opposite of a scoped default.
Grace periods with no end: an overlap window meant for handover becomes permanent because nobody set the duration.
Ignoring tenant-wide defaults: the IGA team designs lean access packages while every user can still register applications and invite guests.
Treating the default service account as harmless: a role bound once for troubleshooting is inherited by every workload using that identity.
Cloning agent permissions: new agents copy an existing agent's grants, so the first agent's excess becomes everyone's baseline.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev 5	AC-6 Least Privilege; AC-6(7) Review of User Privileges	The test for what birthright may contain and the periodic review of it
NIST SP 800-53 Rev 5	AC-2 Account Management; AC-2(1) Automated System Account Management; AC-2(3) Disable Accounts	Rule-driven provisioning, removal on move and disablement
NIST CSF 2.0	PR.AA-05; PR.AA-01	Entitlements defined in policy with least privilege and SoD; identities for users and services managed
ISO/IEC 27001:2022 Annex A	5.15 Access control; 5.18 Access rights; 8.2 Privileged access rights	Access policy, provisioning and review of rights, and keeping privileged access out of defaults
OWASP Top 10 for LLM Applications 2025	LLM06:2025 Excessive Agency	Default functionality, permissions and autonomy for agents

Practitioner checklist

Publish a birthright policy listing each layer, its attribute, contents, owner and review date.
Run every birthright item through the scoping questions; split read from write and remove anything that can grant further access.
Confirm each rule removes access on move and that grace periods have a fixed duration.
Give requested access an end date and trigger a review of it on every move.
Review tenant-wide user defaults such as application registration, group creation and guest invitations.
Disable broad platform defaults for workloads: automatic Editor grants, permissive CI token defaults, roles on default service accounts.
Exclude service accounts, test accounts and agents from human birthright rules.
Give every AI agent its own owned identity, an empty default tool list and a class permission template.
Prune the default annually using usage data and report the metrics above.

Birthright Access vs Least Privilege: Default Entitlements Without Standing Excess