Topics

Workload identity: the right foundation, and only the foundation

Workload identity is the practice of giving a running piece of software a verifiable identity based on where and how it runs, rather than on a secret it was handed. Instead of a service holding a long-lived API key, the platform attests to what the workload is, issues it a short-lived credential, and other systems verify that credential against the issuing authority. Standards and frameworks in this space, including SPIFFE and the workload identity federation features of the major cloud providers, have made this approach practical at scale.

For AI agents, workload identity is a strong foundation, and we want to say plainly why before saying where it stops.

What workload identity solves

Long-lived secrets are the root of much non-human identity risk. They leak into repositories, get copied between environments, and outlive the workloads they were issued for. Workload identity replaces them with credentials that are bound to the running workload, short-lived, and automatically rotated. An agent running under workload identity can prove what it is without anyone having handed it a secret to lose.

It also gives agents distinct, attributable identities. When an agent calls an API, the receiving system can verify which workload is calling, on what platform, in which environment. That is the actor that governance needs to attach to. An agent without a distinct identity cannot be governed, because there is nothing to hold accountable.

What workload identity does not solve

Workload identity answers who. It answers it well and in a way that does not depend on secrets. It does not answer what the workload is allowed to decide.

An agent with a perfectly attested workload identity, a short-lived credential, and a clean trust chain can still issue forty refunds in ten minutes, approve a purchase order that splits into six to stay under a threshold, or resize the production database fleet because a metric spiked. Nothing in the identity carries a ceiling, a condition, or an escalation rule. The credential proves that this is the refund agent. It does not say what the refund agent may do.

This is a boundary, not a shortcoming. Workload identity was designed to solve the secrets problem and the attribution problem. Authority is a different question with a different data model.

Identity, access, authority

Our position is that these are three layers and all three have to exist.

Workload identity establishes who the agent is, without secrets, in a way other systems can verify.

Access control, built on that identity, establishes what the agent can reach: which APIs, which resources, which operations.

Authority governance, above both, establishes what the agent is allowed to decide: the decision rights a human delegated, the constraints including cumulative ceilings, the escalation path, and the record.

A common failure is to build the first two carefully and assume the third follows. It does not. A well-identified, well-permissioned agent with no authority model is an agent with a clean credential and no ceiling.

Agents that are not workloads

One more complication specific to agents. Workload identity attaches to a deployed workload. Agents are increasingly spawned inside other agents' processes, created and destroyed within one task, or invoked as tool calls rather than deployed as services. Some of them will have a workload identity of their own. Some will inherit their parent's. Some will have none. An authority check that sits in the action path evaluates the action either way, and treats an actor that cannot be resolved to a governed identity as a result in itself.

Where BotAris fits

BotAris consumes workload identity rather than providing it. When an agent's action reaches a Decision Authority Enforcement Point, BotAris resolves the caller to its governed authority, using the workload identity as one input, and evaluates the action against the Authority Model. The better the identity, the cleaner the resolution. The authority decision is BotAris's job either way.

Frequently asked questions

Is workload identity enough to govern AI agents?

It is enough to identify them without secrets, which is necessary. It does not define or enforce what they are allowed to decide, which requires an authority layer above it.

Should every AI agent have its own workload identity?

Where the platform supports it, yes. Distinct identities make attribution and access control clean. Agents that are spawned inside other processes may not be able to, which is one reason the authority check has to work on the action rather than depend on the identity.

How does workload identity differ from non-human identity governance?

Workload identity is a mechanism for issuing verifiable identities to software. NHI governance is the program for inventorying, owning, and reviewing all non-human identities, including ones that use workload identity.

Keep up to date on Authority Governance

Long-form writing on defining, enforcing, and proving what AI agents are allowed to decide. No product pitches.

Confirm by email. Unsubscribe anytime.

Humans define authority. BotAris enforces it.

BotAris is onboarding a limited group of enterprise design partners. Design partners shape the product roadmap and receive early access. If you are putting agents into workflows with real consequences, we want to talk.

Related topics