Why AI governance breaks down the moment no human is in the loop

An agent kicks off a scheduled run at two in the morning. It calls a tool, that tool triggers a code change, and by the time anyone is at a keyboard, the change is already in a pull request. Someone asks the obvious question: who did this? The honest answer is that nobody did. A workflow did, on a schedule, using a credential that was issued to a person who was asleep at the time. Every log entry still has that person’s name on it.

That gap, between what the log says and what actually happened, is where AI governance quietly stops working.

How does authentication work for an agent that runs with no human in the loop at all?

Today, in most stacks, it works by the agent presenting a token tied to a human identity, a shared API key, or a Kubernetes service account, which means every autonomous action still gets attributed to whoever’s credential it borrowed rather than to the agent that actually acted. Nobody has a clean, general way to look at an audit trail and answer a much simpler question first: was this a person, or was this a schedule?

That is not a missing feature so much as a mismatch. Identity and access systems were built around the assumption that a login starts with a person sitting down and ends when they walk away. Standing agents, the kind that run unattended for hours and act without anyone initiating each individual step, don’t fit that shape, and bolting a human’s OAuth session onto something that by design runs without one is a workaround, not a fix.

Why this is a governance problem and not just an engineering detail

An audit exists to answer “who did this, and were they authorized to.” Most current setups can only answer “whose credential was used,” which is a weaker and sometimes misleading question. The two answers diverge exactly in the cases that matter most: when a credential is reused across many automated workflows, when a workflow is reconfigured by someone other than the person whose credential it carries, or when an agent is deliberately given broader delegation than the human it’s nominally acting for.

Security teams can’t write an incident response runbook for an actor they have no name for. Blast-radius planning assumes a bounded session, a person who logs in, does something, and logs out. An agent that runs unattended for hours, chaining tool calls without anyone watching in real time, expands that blast radius without anyone having consciously decided it should. Agents already running in production without this kind of oversight are not an edge case anymore. They are closer to the default.

What enterprises are actually asking for

Not a single new feature, but a shift in what the question even is. Teams evaluating agent governance are converging on a few concrete asks: a way to tell, from the log alone, whether a given action came from a person at a keyboard or a process running on a schedule. A way to trace a chain of delegation, this agent acted, under this policy, configured by this person, at this time, without assuming a one-to-one mapping between a credential and a human that hasn’t been true for a while. And authentication that treats “no human is present” as the normal case for a class of workloads, not an exception that has to be hacked around.

None of this is solved anywhere in the industry yet in a way that’s fully satisfying. That is worth saying plainly instead of papering over it, because a vendor that claims to have fully solved agent identity today is not being precise about a genuinely hard, actively evolving problem.

Where to start, with what already exists

The right instinct is not to invent a parallel identity system for agents. It’s to extend the one your organization already trusts to cover them.

Route agent-initiated and human-initiated actions through the same gateway and the same identity provider. Stacklok’s Gateway is built to be the one place agent-to-tool traffic passes through, integrated with the identity providers enterprises already run, like EntraID and Okta, so machine and human identity sit in a single policy surface instead of two separate, harder-to-reconcile ones.

Make audit logging the default for every tool call an agent makes, not an opt-in. Audit events and OpenTelemetry traces flowing into Splunk, Datadog, Grafana, or New Relic mean your security team can investigate an agent’s actions in the same tools and the same workflow they already use for everything else, which matters more than it sounds like it should when an incident is actually in progress.

Stop treating “the agent is autonomous” as a reason to skip identity provisioning. The pillar that matters here is simple: every agent action should be attributable inside the same governed system you already use for people, deployed on the Kubernetes infrastructure you already operate, not a separate, weaker system that exists because nobody got around to including machine identity in the first design.

What to do this quarter

1. Inventory every agent or scheduled workflow currently running in production, the same way you would inventory service accounts you don’t recognize. Most organizations have never written this list down.
2. Check whether your security team can currently answer “was this a human or a schedule” from existing logs alone. If the honest answer is no, that’s this quarter’s fix, not next year’s.
3. Route new agent workloads through the same gateway and identity provider as your human users, rather than issuing them a standalone credential because it’s faster to set up today.
4. Require every new autonomous workflow to get its own identity in your identity provider before it reaches production, not a shared key inherited from whoever built it first.
5. Treat agent accountability as part of the same governance model as MCP and tool access, not a separate initiative with its own timeline that never quite gets prioritized.

Where to start

Multiple Global 2000 enterprises with thousands of active users are running agents in production today without a clean answer to who is accountable when one acts. The fix is not a new identity system invented from scratch. It’s extending the identity provider, the gateway, and the audit trail an organization already trusts to cover machine actors with the same rigor it applies to people.

Stacklok’s forward-deployed engineers work with platform teams directly, on the Kubernetes infrastructure those teams already run, to bring agent and MCP tool-call activity into that same governed, auditable path from the start.