A control approach that reviews and certifies permissions inside an individual application object, such as an Airtable base, rather than stopping at the directory or workspace boundary. It is necessary when application-native sharing creates access that central identity tools do not fully see.
What Base-Level Governance Does
Base-level governance closes the gap between central identity controls and application-native sharing. It treats the object itself, such as a workspace, base, or other in-app container, as the unit of review so that permissions are certified where access actually exists.
This matters because directory- or workspace-level policies can look compliant while nested application permissions continue to grant broader access than intended. The core idea is simple: if the application can create its own sharing boundary, governance has to inspect that boundary directly.
Why It Exists in Modern SaaS
SaaS products increasingly allow fine-grained sharing inside objects, not just at the account or group level. That means the real exposure may be hidden inside an app’s native permission model, even when the surrounding identity system is well controlled.
Base-level governance is most useful where collaboration features are powerful, but the application does not fully surface those grants back into central access tooling. In those environments, the review target has to shift from “who can access the app” to “who can access this specific object inside the app.”
What It Reviews and Certifies
The governance process usually looks for direct object membership, inherited access, link-based sharing, editor rights, and any delegated permissions that can expand control beyond the intended audience. It also checks whether the object owner, business owner, and approver still match the current business purpose of the data.
That review should be precise enough to answer three questions: who has access, why they have it, and whether that access is still justified. A base-level control is not just a listing exercise; it is a certification step that confirms the object’s internal sharing state is acceptable for its sensitivity and use case.
Where the Control Boundary Becomes Visible
In practice, this control boundary appears wherever an application can bypass the directory as the authoritative source of truth. A central IAM or workspace policy may still be necessary, but it is not sufficient when the application itself creates additional, durable access paths.
That is why base-level governance is best understood as an object-scoped extension of access governance. It does not replace enterprise identity controls, it narrows the blind spot created by app-native permissions that sit below the level those controls usually observe.
Risk and Threat Considerations
Base-level governance reduces the risk of silent overexposure inside collaborative applications, especially where sharing links, nested collaborators, or object-specific roles can outlast the original business need. The danger is not only accidental oversharing; it is also the persistence of access that central review never sees.
Failure mechanism: A user gains or retains access through an application object-level grant that is invisible, under-reviewed, or no longer covered by directory-level certification, so excessive access remains active after the legitimate need has ended.
Impact: Confidential data can be disclosed to the wrong audience, insiders can retain unauthorized edit or export capability, and incident response may miss the true access path because the control failure sits inside the application rather than at the directory boundary.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Object-scoped access reviews depend on accurate account and entitlement governance across the app. |
| AC-6 — Least Privilege | Base-level governance enforces least privilege at the object level, not just the directory level. | |
| AU-6 — Audit Review, Analysis, and Reporting | Certified object permissions require review of access evidence and anomalous sharing activity. | |
| Recommendation — Review and revalidate application object access as part of account and entitlement management. Limit object permissions to the minimum required for each role and purpose. Monitor and review application-level access events for unexpected or excessive object sharing. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Base-level governance is a finer-grained access control practice for application objects. |
| Recommendation — Define and enforce access control rules that extend to in-application object permissions. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | This control family covers managing and reviewing access paths, including application-native permissions. |
| Recommendation — Inventory and review application object access paths as part of access control management. | ||
Practitioner Guidance
Why practitioners should care: The governance question is not whether the app is in scope, but whether the specific object permissions are being reviewed with the same discipline as enterprise entitlements. If the application can create access the directory cannot fully describe, the object itself becomes the audit unit.
What to watch for: Pay attention to apps with link sharing, embedded collaboration, delegated ownership, or manual permission grants that bypass standard approval flows. Those patterns usually indicate where base-level governance needs to be explicit rather than assumed.