Imagine a CI pipeline that still runs a job created by an engineer who left six months ago. The job uses a hard‑coded service account token stored in a repository, and the token grants unrestricted read‑write access to a production database. No one notices that the token is still active, and the pipeline continues to issue queries that modify critical tables. Weeks later, an audit request arrives asking who changed a set of rows. The lack of an audit trail becomes obvious when the logs show only the service account name, not the human operator, and the database itself has no record of which command originated from which CI run.
This pattern is common on‑prem. Teams provision non‑human identities, service accounts, CI tokens, automation bots, once and then forget about them. The identities are often granted broad privileges to simplify scripting. Because the credential lives outside any human‑centric workflow, there is no built‑in approval step, no per‑request justification, and no reliable audit trail that ties an action back to a responsible entity.
Even when organizations adopt least‑privilege principles for these identities, the enforcement point remains the target system. The request travels directly from the automation process to the database, SSH host, or Kubernetes API. The target sees a valid credential and executes the command without any intermediate check. No session is recorded, no data is masked, and no approval gate exists. The audit trail, if any, is limited to a single line in the target’s generic log, which often lacks context such as the originating pipeline, the triggering commit, or the user who approved the change.
Why audit trail matters for non‑human identities
Regulators and internal auditors expect evidence that every privileged operation can be traced to an accountable entity. When a service account performs an action, the audit trail should include:
- The identity that initiated the request (service account name, CI job ID, or automation workflow).
- The exact command or query executed.
- The time and source host of the request.
- Any policy enforcement that occurred, such as masking of sensitive fields or a required human approval.
Without a centralized enforcement point, each backend system maintains its own logs, which are difficult to correlate. Engineers spend hours stitching together disparate log files, and critical gaps remain when a system does not log a particular attribute.
Setting up non‑human identities securely
Proper setup starts with identity provisioning. Use OIDC or SAML‑backed tokens for service accounts, rotate credentials regularly, and bind each token to a narrowly scoped role. Deploy these identities through an identity provider that can issue short‑lived assertions. This setup determines who may start a request, but on its own does not provide any audit capability.
Even with tight scopes, the request still reaches the target directly. The target validates the token, sees that the role permits the operation, and executes it. No visibility into the request’s context is captured beyond the target’s native log line.