A security approach that places identity at the center of access control, policy enforcement, and data protection. Instead of assuming the network perimeter is trusted, it uses identity context and central policy to decide who or what can access applications, APIs, and sensitive data.
Expanded Definition
Identity-defined security shifts the trust decision from network location to verified identity, device, workload, and request context. In practice, policy is expressed around the identity of the caller, the sensitivity of the resource, and the conditions of access, which aligns closely with NIST Cybersecurity Framework 2.0 principles for access control and governance.
For NHI and agentic AI environments, this means service accounts, API keys, tokens, certificates, and AI agents are evaluated as first-class identities rather than hidden implementation details. The approach overlaps with Zero Trust Architecture, but the terms are not identical: Zero Trust is the broader model, while identity-defined security is the operational pattern that uses identity context to make continuous authorization decisions. Definitions vary across vendors, especially when products blur policy enforcement, identity fabric, and access proxy functions. NHI Management Group treats the concept as a governance model, not just a product feature.
The most common misapplication is treating a perimeters-first VPN or subnet rule as identity-defined security, which occurs when access still depends on network location instead of continuously verified identity context.
Examples and Use Cases
Implementing identity-defined security rigorously often introduces policy complexity and identity telemetry overhead, requiring organisations to weigh stronger control over machine access against the cost of maintaining accurate context.
- A CI/CD pipeline uses short-lived credentials and policy checks before allowing a deployment token to reach production secrets.
- An AI agent is permitted to call a finance API only when its workload identity, purpose, and scoped permissions match policy.
- A third-party OAuth application is reviewed against access policy before it can read mail or storage data, as discussed in the State of Non-Human Identity Security.
- A service account is denied access to customer data unless the request comes from an approved workload, via an approved path, with current risk signals.
- An organisation maps app-to-app access to Ultimate Guide to NHIs lifecycle controls and uses NIST Cybersecurity Framework 2.0 to align access decisions with protection goals.
These use cases are strongest where access is dynamic, machine-to-machine, and difficult to govern through static network segmentation alone.
Why It Matters in NHI Security
Identity-defined security matters because NHIs often outnumber human identities by 25x to 50x in modern enterprises, and visibility gaps make those identities hard to govern. NHI Management Group research shows that only 5.7% of organisations have full visibility into their service accounts, while 97% of NHIs carry excessive privileges, creating a direct path from identity sprawl to breach impact. The Top 10 NHI Issues and 52 NHI Breaches Analysis both show how quickly secrets, OAuth grants, and service accounts become enterprise-wide exposure points when identity is not the control plane.
When identity is the policy anchor, organisations can reduce standing access, scope machine privileges more precisely, and investigate anomalous access by identity rather than by IP alone. This becomes especially important when secrets are stored outside approved systems, when third-party integrations proliferate, or when AI agents begin acting across multiple services without clear ownership. The practical benefit is not just tighter access, but a governance model that can be audited, rotated, and revoked.
Organisations typically encounter the need for identity-defined security only after a compromised token, over-privileged service account, or rogue integration has already expanded access, at which point the term 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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Identity-defined access depends on controlling NHI lifecycle and authorization scope. |
| NIST CSF 2.0 | PR.AC | Identity-based authorization maps directly to the Protect function's access control outcomes. |
| NIST Zero Trust (SP 800-207) | SP 800-207 | The term operationalises Zero Trust by making identity the basis for each decision. |
| NIST SP 800-63 | IAL/AAL | Identity assurance and authenticator strength shape trust in the calling identity. |
| OWASP Agentic AI Top 10 | AGENT-03 | Agentic systems require scoped tool access and policy-constrained execution. |
Use identity context to enforce least privilege and continuously review access decisions.
