Identity for the agents that work without you

At 3:12 a.m., a pull request merges into a production repo. The audit log says Jeremy approved it. Jeremy left the company a month ago.

No one did anything malicious. Last quarter, Jeremy set up an agent to triage dependency updates overnight. The agent needed credentials, so he gave it his. When he was offboarded, IT disabled his login, but the long-lived token sitting in the agent’s config kept working. The agent kept running with everything Jeremy had access to, and every action was recorded under his name.

When the security team traced it, they were left with questions nobody could answer quickly. Which other systems has this agent touched? How much has it spent on model calls? How do you shut it down without knowing what else depends on it?

This is what happens when autonomous workloads borrow human identities. For work a person kicks off and watches, acting on that person’s behalf is the right model. But a growing share of agent work runs on a schedule, responds to events, or keeps going long after anyone logs off. Those workloads need identities of their own.

Stacklok Enterprise supports service accounts: non-human identities for agents, pipelines, and scheduled automations, governed with the same groups, Model Sets, and tool-level policies you already apply to people.

What is a service account in Stacklok Enterprise?

A service account is a non-human identity that represents a workload rather than a person. The identity belongs to the process or workflow making requests, not to any individual agent running inside it. A workflow might run one agent on a schedule or several agents working together; either way, they operate within the boundary of that workflow’s service account.

Think of a service account like a project defined within Stacklok Enterprise. Each project can be configured with it’s own unique identity according to the administrator’s configuration. How you map service accounts to workloads is up to the administrator. Some teams create one per workflow. Others share one across a broader project or initiative, the same way multiple people might work inside a single project. There’s no single right answer; it comes down to how you want to scope access and attribute activity.

In Stacklok Enterprise, a service account can:

• Authenticate through workload identity federation, using trust bindings that administrators configure
• Belong to groups alongside people, so existing access policies apply
• Be assigned Model Sets that define which LLMs it can use
• Be granted access to specific connectors and individual tools
• Have its LLM spend tracked separately through budgets

Why does non-human identity matter for AI agents?

Most enterprise identity programs were built around people, and most of the tooling agents rely on assumes a person is present. AI workloads break that assumption in three ways.

Agents run when nobody is logged in. The standard pattern for connecting an agent to a system is an MCP server in front of it, with authentication at the MCP server and again at the backend service behind it. OAuth handles both well for humans, because a person is there to click through the browser consent flow. A scheduled workload can’t do that. Without its own identity, teams fall back on shared credentials or a personal token tied to whoever set it up. When that person leaves or rotates a password, the agent breaks, or worse, keeps running with access nobody remembers granting.

Agents act, not just read. Through MCP connectors, an agent can open pull requests, update records, or send messages. Every one of those actions needs an honest answer to “who did this?” If a nightly workflow shows up in your logs as Jeremy accessing GitHub, your audit trail is misleading.

Agents spend money. Every model call has a cost. When workloads share an identity with people, you can’t tell which one is driving your bill.

Service accounts give each workload its own identity, its own permissions, and its own cost line.

How do service accounts authenticate?

Stacklok Enterprise service accounts use workload identity federation. Rather than issuing and storing another secret, Stacklok Enterprise establishes trust with identity providers you already run and maps verified workload identities to service accounts.

Administrators define trust bindings that specify which external issuers Stacklok Enterprise trusts and which workload identities map to which service accounts. At runtime, the workload presents a token from that trusted issuer, such as a Kubernetes service account token or an AWS IAM credential, and Stacklok Enterprise verifies it and resolves it to the right service account.

This matters for two reasons. You don’t replace or duplicate your identity infrastructure; the systems that already know which workloads are legitimate keep doing that job. And you avoid adding another long-lived secret to manage, rotate, and potentially leak, because the credential the workload presents is short-lived and issued by a system you already trust.

Authentication versus authorization

It’s worth being precise about what each layer does.

Workload identity federation establishes which workload is making the request. That’s authentication.

Groups, Model Sets, and connector and tool policies determine what that workload is allowed to do. That’s authorization. A service account can be added to a group, assigned a Model Set, and given access to specific tools on a connector. An agent can be allowed to read from a ticketing system without being allowed to close tickets, using the same tool-level controls that apply to people.

Neither layer establishes which human, if any, authorized a workload to perform a given action on their behalf. That’s the delegation problem described earlier, and it sits outside the scope of service accounts.

What service accounts give you for audit and cost

Service accounts let you attribute gateway activity and model spend to a non-human principal instead of to whichever person’s credentials happened to be in a config file. That’s a meaningful improvement for audit, incident response, and cost attribution.

What they don’t do on their own is identify the specific agent instance that ran, the user who initiated a request, or the full delegation chain from person to agent to sub-agent. Service accounts are the foundation that makes that provenance possible, not the whole of it.

Spend from service account requests is recorded against budgets, so FinOps and platform teams can see cost by workload rather than by whichever employee set it up.

Service accounts give every autonomous workload a name of its own. That’s the starting point for governing agents the way you govern everything else in your environment.


Two identity problems, not one

It helps to separate two problems that often get lumped together.

The first is autonomous workloads operating without a human session. A nightly triage agent or an event-driven pipeline has no person present to authenticate. Something has to represent that workload, and today it’s usually a shared secret or a personal token.

The second is delegation. Jeremy authorizes Agent A to act on his behalf, and Agent A spins up Agent B. Tracing that chain end to end is a broader agent identity problem. This brings a different set of challenges to admins today. 

Service accounts solve the first problem. They’re a foundational building block for the second, because you can’t reason about a delegation chain until you can distinguish a human principal from a workload principal. This post focuses on the first problem.

Learn More

Identity is a core tenant to what we’re doing with agent infrastructure at Stacklok. Learn more about how we’re enabling always-on agents in the enterprise.