Field Note / Identity And Authority

Why NHI Tools Do Not Fully Answer AI Software Delivery Risk

Non-human identity matters. Tokens, service accounts, OAuth grants, CI secrets, deploy keys, and cloud roles are often where authority enters the workflow. But identity is an input. The action path is the question.

Last updated: May 9, 2026

Identity is necessary but incomplete

A non-human identity inventory can tell a team which identities, credentials, grants, and secrets exist. That is a valuable starting point. It does not automatically explain how those identities are used inside software delivery.

For AI-assisted engineering, the review needs to follow the identity into the workflow: which repo, which PR, which script, which CI/CD job, which tool, which target system, which action, which approval rule, and which proof trail.

The action path is the control question

identity -> workflow -> tool/script -> action -> target -> approval/proof

The same credential can be low risk in one path and high risk in another. A read-only token used in a local reporting workflow is different from a token inherited by a CI job that can publish packages or trigger release automation.

This is why teams should avoid treating identity posture as a complete answer to AI software delivery risk. The credential matters because it gives a workflow power. The review is incomplete until the team knows what that power can do.

What NHI tools usually do not answer alone

The right relationship

NHI, IAM, PAM, and credential-security tools remain important. The practical model is not replacement. It is composition.

Identity tools help explain who or what can authenticate. AI Software Delivery Control explains how that authority moves through a delivery path and where approval or proof is missing.