An actual usage baseline is the observed pattern of permissions a user or account truly exercises after provisioning. It helps teams distinguish necessary access from dormant entitlement. Security teams use it to identify excess privilege, prioritize cleanup, and separate real business need from access granted only as a precaution.
Expanded Definition
An actual usage baseline is the observed set of permissions, actions, and tool calls a user or account truly exercises after access has been granted. In NHI and IAM operations, it is distinct from the entitlement set, which shows what was provisioned, approved, or inherited. The baseline is built from telemetry such as audit logs, API activity, privilege use, and workflow execution, then compared with standing access to identify dormant access and over-provisioning.
Definitions vary across vendors on whether the baseline should be derived from a fixed lookback window, a risk-weighted period, or continuous observation. NHI Management Group treats it as an operational evidence set, not a theoretical permission model. That distinction matters because service accounts, workload identities, and AI agents often accumulate permissions that are never exercised, yet still remain active in production. For control mapping, the concept aligns closely with least privilege and access review practices described in NIST SP 800-53 Rev 5 Security and Privacy Controls.
The most common misapplication is treating approved access as evidence of need, which occurs when review teams rely on provisioning records instead of observed usage.
Examples and Use Cases
Implementing actual usage baselines rigorously often introduces a monitoring and tuning burden, requiring organisations to weigh visibility gains against the effort needed to separate true activity from noisy or seasonal operations.
- A service account is granted database read and write permissions, but audit logs show only read activity over 90 days, so write access is flagged for removal.
- An AI agent receives broad cloud permissions during pilot testing, then is limited after its actual usage baseline shows it only calls a narrow set of storage and queue APIs.
- A CI/CD token has access to multiple repositories, but Ultimate Guide to NHIs notes that most organisations still struggle with NHI visibility, making observed usage essential for cleanup.
- During quarterly access reviews, teams compare actual usage baselines with role grants to identify dormant entitlements that can be removed without affecting operations.
- A workload identity used by a data pipeline is observed through logging to invoke only one downstream API, while broader network and storage privileges remain unused and become candidates for reduction.
For telemetry and review design, the baseline should be measured against control objectives in NIST SP 800-53 Rev 5 Security and Privacy Controls, not against convenience-based assumptions.
Why It Matters in NHI Security
Actual usage baselines help security teams separate business necessity from inherited excess. That matters because NHI environments frequently accumulate permissions faster than they are removed, and NHIMG research shows Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, a condition that sharply increases the blast radius of compromise. When teams understand what an identity really uses, they can reduce standing access, narrow attack paths, and make offboarding and rotation decisions with evidence rather than guesswork.
This concept is especially important for zero trust and privileged access governance, where access should be continually justified by observed need rather than permanent entitlement. It also supports stronger incident response because excessive permissions are easier to spot when a baseline exists for comparison. In practice, an actual usage baseline often becomes the deciding factor for whether a dormant privilege remains acceptable or must be removed immediately.
Organisations typically encounter the operational value of an actual usage baseline only after a breach review or failed access audit, at which point unused privilege becomes impossible to ignore.
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, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Usage baselines support least privilege by exposing dormant access on NHIs. |
| NIST CSF 2.0 | PR.AA-01 | Identity and access management relies on knowing what access is actually used. |
| NIST SP 800-63 | Digital identity assurance depends on accurate lifecycle evidence, including actual use. | |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous evaluation of whether access remains justified. | |
| NIST AI RMF | AI risk management needs evidence of how agentic identities really exercise authority. |
Instrument agents and services so their actual usage can be reviewed for excess authority.
