Runtime Conduct

Runtime conduct is what an identity actually does after authentication. In NHI governance, it is the live sequence of access, calls, and resource interactions that reveals whether the identity is operating normally or has drifted into suspicious behaviour that configuration checks will not catch.

Expanded Definition

Runtime conduct describes the observable behaviour of an identity after authentication, including the sequence, timing, destinations, and volume of calls it makes while interacting with services and data. In NHI operations, it is the difference between a service account that is merely provisioned correctly and one that is behaving correctly in production.

This matters because static configuration tells only part of the story. A token may be valid, a certificate may be current, and permissions may look acceptable on paper, while the live activity pattern reveals lateral movement, unusual API chaining, data overreach, or a workload that has been repurposed. Guidance varies across vendors on how much behavioural deviation is enough to trigger a response, so runtime conduct should be treated as an operational signal, not a fixed compliance label. The concept aligns well with the NIST Cybersecurity Framework 2.0, which emphasises continuous governance and detection rather than one-time approval.

The most common misapplication is treating successful authentication as proof of trustworthy activity, which occurs when teams stop monitoring once a secret, certificate, or assertion is accepted.

Examples and Use Cases

Implementing runtime conduct rigorously often introduces monitoring overhead and false-positive tuning, requiring organisations to weigh stronger anomaly detection against the cost of deeper telemetry collection and response workflows.

• A CI/CD service account that normally deploys to one cluster suddenly enumerates storage buckets and IAM bindings across multiple accounts.
• An AI agent that usually reads a small set of approved APIs begins issuing high-frequency tool calls and retrieving records outside its assigned workflow.
• A machine identity with a valid certificate starts calling sensitive endpoints from an unexpected region or host segment, suggesting credential reuse or session hijacking.
• An internal data-processing job begins making outbound requests to unfamiliar services, which may indicate dependency drift or malicious command execution.
• Teams compare normal call graphs against live activity using the NHI governance guidance in the Ultimate Guide to NHIs alongside behavioural expectations from the NIST Cybersecurity Framework 2.0.

In practice, runtime conduct is most useful when paired with identity context such as workload purpose, expected peers, and approved data boundaries. That context helps distinguish legitimate bursty automation from a compromised identity that is expanding its reach.

Why It Matters in NHI Security

Runtime conduct is one of the few signals that can expose compromise after authentication has already succeeded. NHI Mgmt Group reports that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which means most teams are trying to infer risk from incomplete behavioural data. That gap matters because NHI compromise often hides behind valid credentials, automated trust paths, and routine-looking traffic patterns. When runtime conduct is not monitored, excessive privilege, token misuse, and tool abuse can persist long enough to exfiltrate data or pivot into adjacent systems.

Used well, runtime conduct supports Zero Trust thinking by forcing verification to continue after login, certificate issuance, or secret retrieval. It also helps responders separate ordinary automation from abusive automation during incident triage, especially when a workload has begun to act outside its intended function. The concept is closely tied to the identity lifecycle controls described in the Ultimate Guide to NHIs and the continuous monitoring emphasis in the NIST Cybersecurity Framework 2.0.

Organisations typically encounter runtime conduct as an urgent concern only after a service account has already moved laterally, at which point the behaviour itself becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is the difference between runtime protection and NHI lifecycle management?
• What is the difference between code scanning and runtime identity monitoring?
• Why are runtime environments riskier than repository scans for NHI governance?
• When should organisations use runtime authorization for AI agents?