NHI security: seven risks and the fix for each.

An API key or client secret with no expiry is a password that never changes and that nobody types, so nobody notices it leaking. It sits in a config file, an environment variable, a CI secret and a developer laptop at the same time. The fix: issue short-lived credentials from the platform where the system supports it, and give every remaining static key an owner and a rotation date you can check.

An identity without an owner cannot be reviewed, because there is nobody who can say what it is for. The safe-looking choice is to leave it alone, which is how a service account keeps broad access for years. The fix: require a named owner as a field on the identity itself, not in a wiki, and treat an identity whose owner has left as an open item rather than a background risk.

Each new task adds a permission and no task ever removes one. After two years a reporting account can write where it only ever needed to read. The fix: derive the permissions the identity actually used over the last ninety days, propose that as the new scope, and keep the difference visible so the reduction is a decision rather than a guess.

One key used by four jobs cannot be rotated without breaking three of them, and its log lines cannot be attributed to any of them. Sharing turns a small change into an outage risk. The fix: split the identity per consumer before you need to rotate it, starting with the ones that touch production.

An employee clicks Allow once and a third-party app holds mail, drive or CRM access from then on. The grant survives password changes and shows up in no access review. The fix: list every grant with its scopes and its approver, revoke what is unused, and review the rest on a schedule rather than after a vendor incident.

A credential is not only exposed where it is used. Anything running in the same shell, container or CI job can read it, which is how a coding agent inherits a deploy token it was never given. The fix: keep production credentials out of jobs and machines that do not need them, and check what else can read a secret before deciding it is safely stored.

Most systems log that a key was used. Few record which workload used it, so after an incident you cannot say which of the four consumers made the call. The fix: make identity per consumer the precondition for useful logs, then keep the log long enough to cover the window an incident is usually discovered in, which is months rather than days.