Resource-Level Authorisation

Expanded Definition

Resource-level authorisation is the practice of making the access decision inside the application, API, or service that owns the resource, rather than relying on coarse network trust. It evaluates who the subject is, what they are trying to do, and the current context, then enforces the policy at the point of use.

In NHI environments, this matters because service accounts, API keys, and agents often operate at machine speed and across many downstream systems. The control is closely aligned with NIST Cybersecurity Framework 2.0 because it turns policy into an enforceable runtime decision rather than a perimeter assumption. Guidance varies across vendors on how much logic belongs in the app versus an API gateway, so no single standard governs this yet. NHI Management Group treats the core requirement as consistent: the resource owner must be able to evaluate access independently of network position, shared secrets, or inherited trust.

The most common misapplication is treating a front-door gateway check as resource-level authorisation, which occurs when downstream services accept requests without re-evaluating the subject and action against the actual resource policy.

Examples and Use Cases

Implementing resource-level authorisation rigorously often introduces design and latency overhead, requiring organisations to weigh stronger isolation against more complex policy enforcement and testing.

• A payments API checks whether a service account may read one customer record but not another, even though both requests arrive from the same workload.
• An internal agent is allowed to create tickets in one queue but is blocked from exporting incident data unless the policy explicitly permits it.
• A storage service validates that a CI/CD token can write to a single bucket prefix, not the entire object store, reducing the blast radius of compromise.
• As described in ASP.NET machine keys RCE attack, weak trust boundaries can turn one exposed control into broad application compromise when downstream checks are missing.
• In zero-trust designs, resource owners pair per-request checks with policy engines so that identity and context remain visible at the point of decision.

This pattern is especially useful when service-to-service calls need different permissions for different tenants, records, or actions. It also supports better auditing because the decision can be logged with the resource identifier, action, and subject identity.

Why It Matters in NHI Security

Resource-level authorisation is one of the few controls that meaningfully limits what a stolen NHI can do after compromise. If an API key, workload identity, or agent token is overbroad, an attacker can move from a single valid credential to data exfiltration, privilege escalation, or destructive writes. That is why NHI Management Group reports that 97% of NHIs carry excessive privileges, a condition that makes coarse access checks especially dangerous. The same research also notes that 80% of identity breaches involved compromised non-human identities, showing how often weak authorisation becomes the real failure point after credential theft.

Practically, this control reduces the impact of secrets leakage, misissued tokens, and agent misuse by forcing every request to prove entitlement against the target resource. It also makes least privilege measurable, which is essential when NHIs outnumber humans by orders of magnitude and manual review cannot keep up. Organisations typically encounter the consequences only after a token is replayed or an agent is abused, at which point resource-level authorisation becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Sequence-Level Authorisation
• What is MCP Step-Up Authorisation and how does it implement least privilege for agents?
• What are MCP Authorisation Extensions and why do they matter for enterprise governance?
• When does AI agent access become a board-level security concern?