Why non-human identity risk has to be explainable

Most security products that touch machine identities ship a risk score. Very few can tell you why a given identity earned it, what evidence supports it, or what would change it. That gap matters more for non-human identities (NHIs) than for people, because nobody is going to phone a service account and ask what it was doing at 03:14.

The problem with opaque scores

A score is a compression of evidence. When the evidence is hidden, three things happen:

1. Analysts stop trusting it. The first time a “critical” turns out to be a test key in a sandbox, every subsequent critical gets a discount.
2. Owners can’t act on it. A platform engineer who is told “risk 87” has nothing to fix. One who is told “long-lived key, admin role, no owner, reachable from CI, last used from an unfamiliar runner” has five things to fix.
3. Nobody can audit it. When the model changes, historical comparisons silently break.

Our position is simple: evidence before claims. If there is no evidence for a factor, the factor is unknown, and unknown is displayed as unknown — not folded into a number that looks confident.

A conceptual framework, not a formula

We describe identity risk with a small set of factors that can each be traced to a source:

Risk ≈ Identity criticality
     × Privilege
     × Exposure
     × Reachability
     × Credential risk
     × Lifecycle risk
     × Behavioral risk

This is deliberately not presented as a scientific formula. The multiplicative shape communicates one idea: a factor close to zero should pull the whole assessment down. A highly privileged identity with no reachable resources and a credential that cannot leave a hardware boundary is not, in practice, a high risk.

Each factor answers a concrete question and names its evidence:

Factor	Question	Typical evidence
Identity criticality	What does this identity exist to do?	Owner attestation, tags, environment
Privilege	What could it do if it tried?	Effective permission evaluation
Exposure	Could an attacker get the credential?	Scanning results, storage location, rotation age
Reachability	From where can it reach what?	Network and trust-policy analysis
Credential risk	How strong and how old is the authentication?	Credential type, age, reuse
Lifecycle risk	Is anyone responsible for it?	Ownership, offboarding records, last review
Behavioral risk	Is it doing something new?	Baseline vs. observed authentication and actions (not evaluated by Trustivan’s posture engine, by design)

Every finding answers nine questions

An explainable finding is one that a responder can act on without opening another tool. We hold findings to a checklist:

• Why is this a finding?
• What identity and credential is involved?
• Who owns it (or: nobody does)?
• Where does it live, and where can it reach?
• How is it being used right now?
• Blast radius — what becomes reachable if it is compromised?
• Recommendation — the smallest change that removes the risk.
• Action — what the platform can do from this screen.
• Evidence — the snapshots, logs and records that support all of the above, with timestamps.

What this means for AI agents

Agents make explainability non-negotiable. An agent’s authority is assembled from the credentials it inherits, the tools it can call and the other agents it can delegate to. When an agent action is denied, the people who built the agent will ask why — and “the model decided” is not an answer. The decision must be reconstructable from identity, credential, tool, resource, autonomy and context, with each input traceable to evidence — and the declared purpose recorded alongside, not decided on.

Takeaways

• Prefer a smaller number of explainable factors to a large opaque model.
• Show unknown when evidence is missing. An honest blank is more useful than a confident guess.
• Make every finding carry its evidence with it, so remediation never requires re-investigation.