A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
Expanded Definition
Broken Object-Level Authorization, often shortened to BOLA, is a per-object access control failure where a valid identity can reach a record, file, device, or API object that should be out of scope. It is distinct from authentication failure because the token, key, or session is real; the authorization check is incomplete. In NHI environments, that distinction matters because service accounts, API keys, agents, and workload identities often operate at machine speed and can enumerate objects far faster than human users.
Definitions vary across vendors on whether BOLA is treated as a subtype of broken access control or as a separate API risk category, but the operational meaning is consistent: entitlement is checked too broadly, or not at all, at the object layer. The NIST Cybersecurity Framework 2.0 reinforces the need for enforceable access control and continuous governance, which is exactly where BOLA failures surface when object checks are missing or inconsistent. The most common misapplication is assuming that a valid NHI token implies permission to read or modify every object in the same tenant, namespace, or queue, which occurs when developers rely on identity alone and omit per-record authorization.
Examples and Use Cases
Implementing object-level authorization rigorously often introduces design and performance overhead, requiring organisations to weigh faster development against tighter entitlement checks on every request.
- An API key tied to a backup agent can list every customer archive because the endpoint checks only whether the key is active, not whether the archive belongs to the correct account.
- An AI agent with delegated tool access can retrieve another team’s ticket or document when the application trusts the agent session but does not validate object ownership.
- A CI/CD service account can download secrets for unrelated environments because the vault path is accepted as a string input without a per-object policy check.
- A cloud workload identity can modify another namespace’s resource because the platform enforces role membership but not the specific resource identifier being targeted.
These patterns are common in API design reviews and are easier to spot when teams compare object access logic against the identity and secret handling guidance in the Ultimate Guide to NHIs. The same issue is frequently discussed in OWASP-style broken access control guidance, and the practical lesson is always the same: the object itself must be authorized, not just the caller.
Why It Matters in NHI Security
BOLA is especially dangerous in NHI security because machines are granted durable access, reused credentials, and automation paths that can turn a single logic flaw into broad exposure. When an NHI is overprivileged, a broken object check can reveal entire datasets, configuration trees, or device fleets instead of one record. That risk aligns with the broader NHI problem set described in the Ultimate Guide to NHIs, where 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface. In practice, BOLA becomes more damaging when token scope, RBAC, and object ownership are treated as interchangeable controls rather than separate layers.
For governance teams, the relevant question is not whether an identity authenticated successfully, but whether every object request was independently authorized and logged. The NIST Cybersecurity Framework 2.0 is useful here because it frames access control as an ongoing risk-management function, not a one-time implementation detail. Organisations typically encounter BOLA only after a service account, API key, or agent has already accessed the wrong object at scale, at which point authorization review becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Broken object checks map to broken access control in NHI and API threat models. |
| NIST CSF 2.0 | PR.AC-4 | Object-level authorization supports least-privilege access governance and enforcement. |
| NIST Zero Trust (SP 800-207) | JIT | Zero Trust requires continuous authorization decisions for each resource access. |
Enforce per-object authorization on every NHI request, not just identity validation.
