A policy approach that decides access by looking at the specific resource being requested, not only the caller’s role. It uses object attributes such as owner, tenant, type, or state so the access decision can match the business rule for that exact item.
Expanded Definition
Resource-Based Authorization decides access by evaluating the specific object, record, API, or secret being requested, rather than relying only on coarse role membership. In NHI and agentic AI environments, the decision commonly depends on resource attributes such as owner, tenant, project, sensitivity label, environment, or lifecycle state. That makes it a closer fit for multi-tenant systems, delegated administration, and tool-using agents where the same caller may need different outcomes for different resources. It is often implemented alongside RBAC and policy engines, but it is not the same thing as role checking. The practical goal is to align the authorization decision with the business rule for that exact resource, as described in the NIST Cybersecurity Framework 2.0 under access control and governance outcomes. Definitions vary across vendors, but the core idea is consistent: the resource itself becomes part of the decision. The most common misapplication is treating a broad role as sufficient when the actual object belongs to a different tenant, owner, or state.
Examples and Use Cases
Implementing resource-based authorization rigorously often introduces policy complexity, requiring organisations to weigh fine-grained control against the cost of more detailed policy design and testing.
- A service account may read only the API keys it owns, while a break-glass operator can access secrets only when the resource state is marked as emergency-approved.
- A customer support agent can view records only for the tenant embedded in the resource attributes, not for every tenant assigned to the support role.
- An AI agent may be allowed to submit a ticket, but only if the target workflow item matches the project and environment attributes associated with that agent.
- A CI/CD pipeline can deploy only the artifacts tagged for its release channel, preventing a build identity from touching production resources.
- For a deeper NHI pattern example, the attack path in ASP.NET machine keys RCE attack shows why object-level access to sensitive material matters; the control must be tied to the specific secret or key, not just the caller.
This approach also fits well with policy models described in NIST Cybersecurity Framework 2.0, where access decisions are expected to support least privilege and traceable enforcement.
Why It Matters in NHI Security
Resource-based authorization is critical because NHI compromise rarely stops at the initial credential. Once a service account, token, or agent identity is abused, the attacker often tries to enumerate and access the highest-value resource available through that identity. Fine-grained, resource-aware authorization limits that blast radius by making the decision depend on the object being touched, not just the identity presenting the request. That is especially important in environments where NHIs outnumber human identities by 25x to 50x, and where broad privilege assignment is common; NHI Mgmt Group reports that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface. The same guide also notes that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, which is why resource-aware policy becomes a core control rather than a convenience feature. Organisational risk becomes visible in practice when a leaked token is used to pivot from one object to many, or when an agent crosses a tenant boundary and touches data it should never have seen. Organisations typically encounter the real cost only after a credential abuse or cross-tenant exposure event, at which point resource-based authorization 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-03 | Covers privilege and authorization controls for non-human identities. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access decisions depend on the resource being accessed. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires per-request authorization based on context and resource sensitivity. |
Enforce resource-aware checks so NHI access stays limited to the exact object and context requested.
Related resources from NHI Mgmt Group
- What is the difference between prompt-based control and runtime authorization for agents?
- What is the difference between scopes and role-based authorization in MCP?
- What is the difference between scope-based authorization and object-level authorization in MCP?
- What is the difference between RBAC and policy-based authorization for NHIs?
