A concrete, individual object in an application that authorization policies can target, such as one order, one meal, or one project. Resource instances carry their own attributes and relationships, which lets teams enforce permissions at the level of a specific record rather than at a broad resource type.
Expanded Definition
A resource instance is the specific object that an access control decision applies to, rather than the abstract resource type. In NHI and IAM design, that distinction matters because a policy can allow access to one project, one order, or one dataset while denying neighbouring objects of the same type. The instance often carries attributes such as owner, tenant, classification, status, or relationship to another record, which makes it suitable for fine-grained authorization and policy evaluation.
Definitions vary across vendors on whether instance-level control is implemented through direct object permissions, relationship-based rules, or policy engines, but the operational idea is consistent: a request is checked against the exact record being touched. That precision is especially important when service accounts, API clients, and agents act on behalf of workflows across shared systems. The most common misapplication is treating resource instances like broad resource classes, which occurs when teams reuse type-level permissions for every record and lose the ability to constrain access by ownership, tenant, or state.
Examples and Use Cases
Implementing resource-instance authorization rigorously often introduces policy complexity, requiring organisations to weigh precise access control against the overhead of maintaining object attributes and rules.
- A payment platform lets a billing service account update one invoice resource instance after reconciliation, but not every invoice in the tenant.
- An internal agent can read a single support case tied to its workflow, while a different case remains inaccessible because the instance relationship does not match.
- A project management tool grants a bot permission to adjust only the project record assigned to its team, rather than all projects of that type.
- A secrets review workflow checks one credential record at a time so the automation can rotate a specific API key without exposing unrelated secrets.
For readers mapping instance-level authorization to broader NHI controls, the practical lesson is that every object touched by a non-human actor should be evaluated on its own attributes and relationships. That is also why object-level policy review is often paired with guidance from the NIST Cybersecurity Framework 2.0, which emphasises access control as part of a governed security program. In real systems, instance scoping is easiest to understand after comparing it with a breach pattern such as the ASP.NET machine keys RCE attack, where over-broad trust in a shared component can create exposure far beyond the intended object boundary.
Why It Matters in NHI Security
Resource-instance thinking is central to NHI security because service accounts, automations, and agents rarely need blanket access to an entire dataset. When authorisation stops at the resource type, a compromised identity can move laterally across records, alter adjacent workflows, or expose data that was never intended for that actor. Fine-grained instance controls reduce blast radius, support tenant isolation, and make entitlement reviews more meaningful because reviewers can inspect exactly which records an identity can touch.
This matters even more in environments where NHIs already carry excessive privilege. NHI Management Group reports that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, which makes object-level restrictions a practical control rather than a theoretical refinement. The same logic applies to secrets-backed automations: if a bot can reach one instance, the policy should not assume it can reach every sibling object. The broader governance point aligns with the NIST Cybersecurity Framework 2.0 emphasis on least privilege and controlled access, and the risk becomes visible in patterns such as Gladinet Hard-Coded Keys RCE Exploitation, where a single exposed credential path can unlock far more than one intended object. Organisations typically encounter the need for resource-instance controls only after a service account touches records it should never have been able to reach, at which point the model 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 | Instance-level authorization limits each non-human identity to specific resources. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege requires access decisions that can target individual assets or records. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust enforces per-request, per-resource authorization instead of implicit trust. |
Apply object-level access checks so identities only reach the records required for their role.
