Non-human identity: what it means for your audit trail

A human logs in once and you can reconstruct what they did. A service account, a CI runner, and an agent log in thousands of times a day, often as the same shared key, and your audit trail records a machine doing things no person ever reviewed. That is the tension. A non-human identity acts like a user but reports like a process.

The result is an audit trail full of activity and short on accountability. You can see that svc-deploy ran a migration at 03:14. You cannot see who or what decided it should, or whether anyone was supposed to approve it.

Why non-human identity strains the audit trail

Most logging was built around the human session. One person, one login, one trail. Non-human identities violate every part of that shape:

• They are shared. Ten pipelines and three engineers use the same database role, so the log attributes everything to the role.
• They are long-lived. A token minted in 2023 is still authenticating in 2025, and nobody remembers what granted it.
• They fan out. One scheduled job triggers five downstream calls, each landing in a different system's log with no link back to the cause.

An audit trail that cannot name the principal behind an action is a list of events, not an account of decisions.

What a usable trail actually needs

For non-human identities, three properties separate a real record from noise:

1. A named principal per action. Every command resolves to a specific identity, not a shared role. "The reporting agent" is not enough; the trail names the agent, the run, and the human or policy that authorized it.
2. Command-level granularity. "Connected to Postgres" tells you nothing. "Ran UPDATE accounts SET ... on the prod replica" tells you everything.
3. A record outside the actor. If the same process that ran the command also writes the log, a compromised or buggy actor can shape its own story. The record has to live somewhere the actor cannot reach.

Put the audit trail on the connection, not in the agent

The fix is architectural. Stop trying to make every service account, runner, and agent honestly narrate itself, and instead record at the point where it touches infrastructure. That point is the connection.

hoop.dev is an open-source access gateway that sits between identities and infrastructure. Databases, Kubernetes, SSH, and internal services are reached through it, and every session is attributed to a named principal and recorded at the command level. Because the record is captured on the connection, the non-human identity cannot rewrite or omit it. The audit trail stops depending on the good behavior of the thing being audited.

Concretely, when a CI runner queries production through the gateway, the trail shows the resolved identity, the exact statements, any approval that gated the access, and what data was returned. That is an audit trail an auditor can read and an incident responder can trust. For how that attribution maps to identity providers, see the getting-started guide.

A worked example

Say a nightly job reconciles billing. Without a gateway, your trail has a row: billing-svc connected, 9,000 rows read. With the connection governed, the same job produces: principal billing-svc mapped to the pipeline that launched it, the precise query, the masking applied to card data on the way out, and the duration. If that job ever reads something it should not, you find out from the trail, not from a breach report. More on how this model treats machines as first-class identities is on the hoop.dev site.

FAQ

Is a service account a non-human identity?

Yes. Service accounts, CI runners, daemons, and AI agents are all non-human identities. They authenticate and act, so they need the same naming and recording you give people.

Why not just log inside each service?

In-process logs can be incomplete, inconsistent across services, or altered by the same code path that misbehaved. A record captured on the connection is uniform and sits outside the actor.

Does this replace my SIEM?

No. It feeds it. A command-level, per-principal record is far better source data for your SIEM than a shared-account connection log.

If your audit trail still attributes machine actions to shared roles, start with the connection. hoop.dev is open source, and you can read the gateway, the recording path, and the identity model on GitHub.