Base Permission

Expanded Definition

Base permission is the starting access posture a code hosting platform gives to a new member before repository-specific roles, team membership, or finer-grained restrictions narrow it. In practice, it functions as the default trust envelope for all ordinary users, so it shapes the baseline exposure of source code, project metadata, and sometimes internal collaboration surfaces.

The term is often confused with repository permissions, which are more specific, and with organisation-wide policy, which may override or constrain it. The important boundary is that base permission is not the final access decision; it is the default floor from which later controls subtract or add access. Where platforms allow broad defaults, the safest interpretation is that every new member inherits that breadth unless another control actively reduces it. That makes base permission a governance choice, not just a configuration detail.

For a broader control lens, the NIST control family around access enforcement helps frame why defaults matter: access should be granted only as required for the intended role, not because the platform ships with a permissive starting point. For authoritative control context, see NIST SP 800-53 Rev 5 Security and Privacy Controls.

A common implementation reality is that teams assume “we will tighten access later,” but the base permission itself may already expose repositories to every newly added member before that later tightening happens.

Examples and Use Cases

Base permission appears whenever an organisation on a code hosting platform decides how much access a new member should receive by default. The practical impact depends on whether the organisation uses open collaboration, segmented teams, or tightly governed internal repositories.

• A software group sets the base permission to read so new members can browse internal repositories without immediately changing individual access rules.
• A security-sensitive platform lowers the base permission to none, then grants access only through explicit team membership and repository assignments.
• A DevOps team uses a broader base permission for a short-lived migration, then later discovers that the temporary setting became the effective standing default.
• A compliance-driven organisation keeps the base permission minimal because the default should not expose source code, build logic, or adjacent project artefacts to every employee.

The main trade-off is administrative simplicity versus exposure. A broader default reduces onboarding friction, but it also increases the chance that access exists simply because no later control removed it. That is especially important in environments where repository inheritance or mirrored project structures make exposure harder to spot.

In mature platforms, base permission is rarely the only control that matters, but it is often the first control that determines whether least privilege exists at all.

Security Implications

When base permission is too broad, the immediate failure is overexposure. New members may gain access to repositories they do not need, including internal code paths, operational scripts, or configuration files that reveal system behaviour. In source-controlled environments, that can widen the blast radius of a routine onboarding mistake into unnecessary disclosure across many projects.

Misconfiguration can also create governance blind spots. If reviewers assume that access will be narrowed elsewhere, they may miss the fact that the platform’s default is already granting material reach. The result is not only confidentiality risk but also weaker accountability, because access becomes implicit rather than intentionally assigned. In practical terms, that makes access reviews less reliable and incident scoping harder, since investigators must distinguish inherited default access from deliberately approved access.

For organisations using code hosting as a collaboration hub, broad defaults can also increase the chance that secrets, deployment details, or internal design documents are visible to people who do not need them. The observable symptom is often not a dramatic breach but a persistent pattern of unnecessary read access that survives organisational growth, team churn, and platform expansion.

Domain and Governance Relevance

Base permission matters most in identity and access governance because it sets the starting condition for every new member. The control question is not only who should be added to a repository, but what every new member can see before a repository owner or administrator intervenes. That makes the setting a governance baseline, not a convenience preference.

From a non-human identity perspective, the same reasoning applies when automation, bots, or service-linked accounts are added to code hosting platforms and inherit the same default access patterns as human users. If base permission is too open, automated actors can inherit more reach than their role requires, which complicates repository segmentation and secret protection. The issue is not that all automation is risky, but that default access should not assume human-equivalent breadth for every actor class.

For NHIMG, the practical takeaway is that base permission should be treated as part of the access model that shapes repository trust boundaries. If the default is permissive, later controls must work harder to restore least privilege across both human and machine access paths.

Related resources from NHI Mgmt Group

• When should organisations revoke an OAuth grant or third-party app permission?
• What is the difference between client identity and permission scope in MCP governance?
• Why do permission boundaries fail as a scale control for cloud access?
• What is the difference between SCPs and permission boundaries in AWS governance?