Workload Identity Proves Who the Agent Is. It Doesn't Say What It May Do.

Teams that have cleaned up their cloud security often ask the same question when they deploy AI agents: “We already have workload identity. Isn’t that enough?”

It is a good start. Workload identity (cloud managed identities, Kubernetes service accounts, SPIFFE/SPIRE) gives a running process a short-lived, verifiable identity without a stored password. For an agent, that answers one question well: which workload is calling?

It does not answer the questions that matter once an agent starts acting for a person across third-party APIs, MCP servers and other agents:

• Whose authority is the agent using right now?
• Which exact action is it allowed to take, against which system, with what limits?
• Where is the record that a human could read after something goes wrong?

This post separates the layers, shows where each one fails on its own, and explains the business case for putting a credential broker on top.

What workload identity does well

A workload identity is issued to code, not to a person. The platform attests that a process is running where it claims to run, then mints a short-lived token or certificate.

• No long-lived secret sits in an environment variable.
• Tokens expire in minutes, so a leak has a short window.
• Rotation is automatic.
• Service-to-service calls inside one trust domain can use mutual TLS.

For internal services, this is the right foundation. Keep it.

Where it stops for AI agents

An agent is not a normal service. Three properties break the assumption that “the workload is the actor.”

1. One workload, many principals

A single agent runtime often serves many users and many tasks. The workload identity is the same for all of them. If the runtime holds one token that can reach a CRM, every user’s request reaches the CRM with the same authority. That is the shape behind cross-user session bleed and the confused deputy.

2. The target is outside your trust domain

Workload identity is strongest inside a platform boundary. Agents call SaaS APIs, partner systems and remote MCP servers that do not trust your SPIFFE bundle. They want an API key, an OAuth token or a signed request. Someone still has to hold that secret, and without a broker it ends up in the agent’s configuration or prompt context. See scoped credentials for AI agents.

3. The agent chooses its own actions

A service runs code you wrote and reviewed. An agent decides at runtime which tool to call and with what arguments, influenced by text it read. Indirect prompt injection means a valid, attested workload can be steered into a harmful call. The identity is real. The action is still wrong.

The layers, side by side

Layer	Question it answers	Fails when
Workload identity	Which process is this?	One process acts for many users or tasks
User delegation (OAuth, token exchange)	Whose authority is borrowed?	Tokens are broad, long-lived or passed through
Credential broker	Which secret may be used, for which call?	Agents hold the secret themselves
Policy and approval	Is this exact action allowed now?	Rules fail open or no human is in the loop
Audit and trace	What happened, and who decided?	Logs are per-service and cannot be joined

No single layer is optional. Workload identity is the bottom one, not the whole stack.

How this plays out across MCP and A2A

MCP. An agent connects to a tool server. The server needs a credential for the downstream API. Workload identity can authenticate the agent to the MCP endpoint, but the tool call still needs a scoped credential and a decision about whether this call is allowed. See audience binding and token passthrough.

A2A. One agent delegates a task to another. The receiving agent has its own workload identity, but the delegation chain, the original user and the allowed scope have to travel with the task. See token exchange and the A2A delegation chain and A2A protocol governance.

In both cases the workload identity is the outer handshake. The inner questions, whose authority and which action, need their own controls.

What goes wrong without the upper layers

Consider a support agent running as a well-configured managed identity.

1. It reads a customer email containing hidden instructions.
2. It calls a billing tool to “issue a refund” for a large amount.
3. The billing API accepts the call because the agent holds a valid, broad token.
4. The audit trail shows the managed identity name and a timestamp. Nothing links the refund to the email, the user or the approval that never happened.

Every identity check passed. The failure was authority, policy and traceability. Compare six AI agents gone wrong.

The business case for a broker on top

A credential broker sits between the agent and the systems it acts on. For leadership, the case is not “another security tool.” It is four concrete outcomes.

1. Smaller blast radius. Agents never hold the upstream secret. A compromised or manipulated agent can only make calls the broker’s policy permits, within limits. Leaked keys can be rotated in one place.
2. Faster approvals from security and legal. Reviewers get one place to see which agents exist, what they can reach and who approved it. That maps to non-human identity governance, SOC 2 audit controls and the EU AI Act and ISO 42001 expectations.
3. Data ownership stays with you. Requests, responses and credentials pass through a layer you control, with response sanitization before data returns to a model.
4. Incidents become investigations, not guesswork. One record ties the agent, the user, the policy decision, the approval and the outcome together. See agent incident forensics and trace propagation across A2A and MCP.

Build-versus-buy is a fair question; we cover it in build vs buy for an AI agent credential proxy.

How Fullmakt fits

Fullmakt is a credential broker and governance layer for AI agents. It is designed to sit alongside whatever identity your platform already provides:

• Agent principals and OAuth clients give each agent its own identity and token, separate from the humans it serves.
• Credential references keep upstream secrets in a vault or environment backend. The agent names a reference and never sees the value.
• Policy is evaluated per call, and sensitive actions can require a human approval that the agent cannot grant itself.
• Signed envelopes bind a request to its exact arguments to resist replay.
• Audit history records requests and decisions in one place.
• MCP and A2A surfaces let agents connect through standard protocols instead of bespoke integrations.

Use workload identity to prove the process. Use Fullmakt to decide what that process may do with other people’s systems, and to prove afterwards what it did.

Checklist

• [ ] Workload identity is used for agent-to-platform authentication.
• [ ] Each agent has its own principal, not a shared service account.
• [ ] User authority is delegated per task, not cached per runtime.
• [ ] Upstream secrets live in a vault or broker, never in the agent.
• [ ] Policy is checked per call and fails closed.
• [ ] High-impact actions need out-of-band human approval.
• [ ] One audit record joins agent, user, decision and outcome.
• [ ] Offboarding an agent revokes every credential it could reach.

FAQ

What is workload identity for AI agents? It is a short-lived, platform-attested identity issued to the process running an agent, such as a cloud managed identity, a Kubernetes service account or a SPIFFE ID. It proves which workload is calling, not what it is allowed to do.

Is workload identity enough to secure an AI agent? No. It authenticates the process but does not scope the agent’s authority per user, hide third-party secrets, evaluate each action against policy or produce a joined audit trail.

Do I still need a credential broker if I use SPIFFE or managed identities? Yes, when agents call systems outside your trust domain or act for individual users. A broker holds the upstream secrets, applies policy and records every decision. The two are complementary.

How do MCP and A2A relate to workload identity? Workload identity can secure the transport and authenticate each agent or server. MCP and A2A still need per-call authorization, delegation chains and audit, which sit above the workload layer.

How does Fullmakt work with existing identity systems? Fullmakt gives each agent its own principal and OAuth client, keeps upstream credentials behind references, and enforces policy and approvals per call. It complements your platform identity rather than replacing it.

See how Fullmakt brokers credentials for AI agents or browse the Fullmakt blog.