Most privileged access conversations still picture a person: an admin who logs in, does the risky thing, and logs out. Increasingly the account doing the risky thing is a service — a deploy bot, a build runner, an AI agent executing generated code — and it never logs out on its own.
The fix isn't a stronger password on that service account. It's removing the standing privilege entirely. In one of our own builds, untrusted code needed to execute in a sandbox with network access — but 'network access' is exactly the capability that turns a bug into an exfiltration path. The answer was a default-deny egress policy: nothing leaves the sandbox unless a rule explicitly allows it, and the rule list stays short on purpose.
The uncomfortable part of this work is usually not the design, it's the rollout: a default-deny policy will break something on day one, because some legitimate call was quietly relying on the open door. Treat that as the audit finding it is, allow the specific path, and move on. The alternative — leaving the door open because closing it might break something — is how standing privilege accumulates in the first place.
Least privilege isn't a policy document. It's whatever a credential can still do at 3am when nobody's watching.