Agent Identity vs. Workload Identity

“Agent identity” and “workload identity” are often used as if they describe competing technologies. They answer different questions. Workload identity is the established idea that running software receives an attributable, bounded identity instead of a shared secret. Agent identity is the application of identity and authorization controls to software that plans and takes actions through tools.

The clean implementation is usually not a new principal type for every model invocation. It is a clear software principal plus explicit delegation and credential-selection records. In Axec, Agent is product terminology for an Application doing agentic work, not a separate authentication kind.

Four Identities Commonly Collapsed into One

An agent workflow can involve at least four actors:

These identities may be related, but they are not interchangeable. A Kubernetes workload identity can establish which service is running. It does not by itself prove that Alice approved access to her repository, nor that the service may use Alice’s upstream OAuth token.

Axec authenticates the Application Credential at its boundary. A user Connection represents one authenticated upstream account for one Connector. A Grant records the exact approved path from requesting Application to target gateway and credential source.

Delegated and Autonomous Authority

The important distinction is not “agent versus workload.” It is user-delegated versus application-principal authority.

User-delegated flow

The Application starts Authorization Code with PKCE for an exact MCP resource. The user logs in, connects an upstream account if necessary, reviews capabilities and duration, and consents. Axec creates a Grant that pins the Application Credential and exact Connection or workspace credential.

Application + Application Credential
  -> browser authorization + user consent
  -> Grant + exact Connection
  -> resource-bound gateway bearer
  -> MCP capability

The Application acts with a user-approved slice of authority, not as the user in every context.

Application-principal flow

A static confidential Application can use the OAuth client_credentials grant against its own gateway. There is no browser user, Authorization Transaction, or user Grant in this path.

POST /oauth2/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: Basic BASE64_CLIENT_ID_AND_SECRET

grant_type=client_credentials&scope=mcp%3Ainvoke&resource=https%3A%2F%2Faxec.example%2Fg%2Fops%2Fmcp

In Axec this principal may use only active vaulted or none Connector attachments on its own gateway. It cannot load or decrypt a user’s Connection. That boundary is more important than giving the autonomous agent a special label.

Where Workload Identity Fits

Platform workload identity can improve how an Application obtains credentials. Examples include short-lived cloud credentials, SPIFFE identities, or orchestrator-issued service account tokens. They reduce static secret distribution and improve instance attribution.

At the Axec boundary, however, the identity must map to a supported Application authentication profile. Axec currently supports public PKCE clients for browser authorization and client secrets for static confidential clients. Do not imply that presenting an arbitrary platform token automatically authenticates an Axec Application.

This layered approach is useful:

1. The platform authenticates the running workload.
2. The workload obtains or protects the Application credential.
3. Axec authenticates the Application.
4. Axec evaluates delegated or application-principal authority.
5. Axec selects the approved upstream credential only during execution.

Service Accounts Are a Separate Control Plane

Service accounts can also be confused with autonomous agents. In Axec, a service account is a tenant-owned non-human principal for management automation. It has a normalized management permission ceiling and short-lived management tokens. It has no user role, Application authority, Connection, or Grant authority.

Use a management service account to automate supported tenant administration. Use an Application identity to invoke an Application gateway. Keeping these roles separate avoids giving runtime agents control-plane permissions merely because both are non-human.

Practical Recommendations

Name the principal in every log and decision

Record the Application ID, credential generation, principal kind, gateway, Grant when applicable, and selected Connector. “Agent called tool” is not sufficient attribution.

Bind authority to exact identities

Do not grant access to broad labels such as “all assistants.” Bind consent to the exact Application Credential and Connection identity. Rotation or reconnection should create a new authority identity so old approval does not migrate silently.

Choose the flow from the credential owner

If execution uses a user’s upstream account, use browser delegation and consent. If it uses a workspace credential with no user context, use a tightly scoped Application-principal path. Do not simulate user consent in a headless flow.

Security Caveats

An identity tells you who or what is calling; it does not establish that the requested action is safe. Enforce capability and argument constraints at the gateway. Runtime attestation can strengthen workload identity, but it still does not replace user consent or upstream credential governance.

Avoid creating a principal for every ephemeral sub-agent unless it has an independently managed lifecycle and authority. Otherwise, multiplying identities can create noisy records without improving control. Preserve parent Application and user delegation context across spawned work instead.

FAQ

Is the model provider the agent identity?

Usually not. The client Application orchestrating the model and tools is the actionable software principal. A provider may be relevant supply-chain context, but it should not replace client authentication.

Can one Application represent several deployed replicas?

Yes, when they share the same intended authority and lifecycle. Platform telemetry can distinguish instances while Axec authorizes the Application boundary.

Is a service account sufficient for user-delegated access?

No. A service account is non-human authority. It cannot stand in for a user’s consent or make a user-owned upstream Connection available.

Primary References

• OAuth 2.0 Client Credentials Grant (RFC 6749, Section 4.4)
• SPIFFE Concepts
• NIST SP 800-207: Zero Trust Architecture