Broken Access Control

Expanded Definition

Broken access control is the failure to enforce what an authenticated user, service, or workload is allowed to do after identity has already been established. In NHI environments, that often means a service account, API key, or agent can reach data, endpoints, or admin functions that were never intended for it. The control problem is not authentication; it is authorization fidelity across every request path, token scope, and execution context.

Definitions vary across vendors on whether mis-scoped tokens, missing object-level checks, and privilege escalation paths are all separate issues or one access-control failure category. In practice, NHI teams treat them as one governance problem because enforcement gaps often appear across application code, infrastructure policy, and automation pipelines. The OWASP Non-Human Identity Top 10 frames these failures as a direct exposure pattern for service identities and machine credentials. The most common misapplication is assuming a valid token equals valid authorization, which occurs when teams trust authentication success without verifying resource-level permissions on each action.

Examples and Use Cases

Implementing access control rigorously often introduces latency, policy complexity, and review overhead, requiring organisations to weigh tighter containment against faster automation.

• A CI/CD runner receives broad cloud permissions and can create production resources because its role was copied from a human administrator rather than designed for a workload.
• An API key can read every customer record because object-level checks are missing, even though the calling service was only meant to access one tenant.
• A chatbot agent with tool access can invoke privileged operations beyond its intended scope because the action layer does not validate each command against policy.
• A secret stored in code inherits the permissions of the deployment pipeline, turning a simple leak into lateral movement across environments, a pattern often discussed in the Ultimate Guide to NHIs.
• A payment workflow fails a PCI review when a service account can retrieve cardholder data it never needs, which is why PCI DSS v4.0 emphasises least privilege and access restriction.

For broader breach patterns, the 52 NHI Breaches Analysis shows how over-permissioned machine identities can turn a single weakness into repeated compromise paths.

Why It Matters in NHI Security

Broken access control is one of the fastest ways for a machine identity incident to become a business incident. NHIMG reports that 97% of NHIs carry excessive privileges, which means the underlying condition for authorization failure is already common in enterprise environments. Once a service identity, token, or agent can move beyond its intended boundary, attackers do not need to break cryptography; they only need to trigger a permitted identity into an unpermitted action. That is why access-control design must cover service accounts, API scopes, policy enforcement points, and agent tool permissions together.

This matters especially in Zero Trust and NHI governance programs, where the goal is not just to verify identity but to constrain every action continuously. The Ultimate Guide to NHIs — Key Challenges and Risks and Ultimate Guide to NHIs — Standards are useful references for mapping that control gap to operational governance. Organisations typically encounter the consequence only after a service account is abused, at which point broken access control becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is the difference between broken access control and security misconfiguration in NHI environments?
• When do AI-assisted automation mistakes become an access control problem?
• When is a reverse proxy better than a VPN for access control?
• When does policy-based access control reduce risk for NHI environments?