A behavioural profile built from the combined activity of multiple processes, tasks, or agent instances sharing the same runtime boundary. It is useful for operations, but for security it can hide malicious deviation when one actor’s behaviour is averaged into the group.
Expanded Definition
A workload baseline is a reference profile built from the combined activity of multiple processes, tasks, or AI agent instances that share a runtime boundary. In NHI security, that matters because the baseline can describe a container, virtual machine, host, namespace, or orchestration unit rather than a single credential or service account. It is an operations-friendly lens, but it is not a true identity control by itself.
Definitions vary across vendors on whether the baseline should include network calls, filesystem writes, API destinations, token use, or scheduler behaviour. NHI Management Group treats it as a behavioural aggregate that can support detection, but not replace per-workload identity, attestation, or secret governance. That distinction is important when teams use baseline drift to spot compromise while still enforcing identity-centric controls described in the Ultimate Guide to NHIs and the SPIFFE workload identity specification. The most common misapplication is treating the averaged profile as proof that each actor inside the runtime boundary is trustworthy, which occurs when shared runtimes mask privileged or malicious sub-process behaviour.
Examples and Use Cases
Implementing workload baselines rigorously often introduces false-comfort risk, requiring organisations to weigh broad anomaly detection against the possibility that a single compromised process is hidden inside an otherwise normal aggregate.
- A Kubernetes namespace baseline captures typical pod-to-pod requests, helping operators spot a sudden outbound call to an unfamiliar API while still validating the pod’s SPIFFE identity.
- An ephemeral build agent baseline records normal package fetches, compilation steps, and registry pushes, then flags a runner that begins exfiltrating secrets from environment variables.
- A serverless workflow baseline models function invocations and downstream service calls, making it easier to detect when one function starts behaving like a data staging point instead of a short-lived task.
- A shared VM baseline helps security teams compare the expected cadence of batch jobs against a new process that opens a shell, scans local credentials, and persists beyond the job window.
- NHIMG’s Guide to SPIFFE and SPIRE is useful when baseline analytics need to be paired with workload identity issuance and attestation rather than inferred trust.
These use cases align with guidance from the SPIFFE workload identity specification, which focuses on identity for workloads rather than aggregate behaviour, and with NHIMG’s broader view that baseline analytics should support, not substitute for, runtime assurance.
Why It Matters in NHI Security
Workload baselines matter because NHI compromise often emerges inside shared execution environments where multiple actors reuse the same image, host, or orchestration boundary. If teams rely only on an averaged behavioural profile, malicious activity can look normal enough to evade alerting. That risk is amplified when secrets, tokens, and certificates are present in code paths or runtime memory, a pattern highlighted in NHIMG research where 96% of organisations store secrets outside of secrets managers and 79% have experienced secrets leaks. A baseline can help detect drift, but it cannot establish ownership, rotation discipline, or least privilege.
Used properly, workload baselines support incident triage, but only after identity evidence and secret hygiene are in place. They are especially relevant when organisations compare normal runtime behaviour against compromised service accounts or agentic processes described in the Ultimate Guide to NHIs — Standards. The operational lesson is that baselining is strongest when it is one signal among many, not the authority that decides trust.
Organisations typically encounter the limits of workload baselines only after an alert is missed during a lateral movement event, at which point the concept 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, OWASP Agentic AI Top 10 and CSA MAESTRO 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 | Behavioural profiling can hide compromise inside shared runtimes, so monitoring must preserve workload-level identity. |
| NIST CSF 2.0 | DE.CM-1 | Continuous monitoring covers workload behaviour changes and anomaly detection across runtime environments. |
| NIST Zero Trust (SP 800-207) | SC-2 | Zero trust rejects implicit trust from shared context, which is exactly where workload baselines can mislead. |
| OWASP Agentic AI Top 10 | AIA-02 | Agentic systems need behaviour monitoring because one agent can hide inside an averaged workload profile. |
| CSA MAESTRO | TBD | MAESTRO addresses monitoring and control for autonomous workload behaviour in agentic environments. |
Correlate baseline anomalies with per-workload identity and secret controls before treating activity as trusted.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 21, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
