AI agent identity is becoming workload identity with bounded authority

Teams often name an agent, assign it one API key and then treat every request carrying that key as the same trusted actor. The key proves only possession of a secret. It does not prove which binary, container, model, tenant, user or task is using it, and it provides no automatic boundary for subagents or tool calls.

A useful identity must be anchored in evidence that a verifier can check. For workloads, that evidence may include platform-issued service-account tokens, process attributes, image identity, node attestation, managed-resource identity or a hardware root of trust. The identity should be issued only after those properties match policy.

The name shown to a user remains useful for product experience, but it belongs to a different layer. Display identity, runtime identity, operator identity and delegated principal should be linked without being collapsed into one field.

The human or organization that wants an outcome is the delegating principal. The agent workload is the software process performing planning. The session identifies one bounded execution context. A subagent may be created for a narrower task. The resource server owns the final decision about its data or operation.

Confusion appears when a user token is forwarded through every layer. Downstream services may see the user but not the intermediary agent, making it impossible to distinguish a legitimate user request from an agent exceeding the intended task. The opposite mistake is using only a service identity and losing the represented principal entirely.

Tokens and audit records should preserve both the actor and the represented principal where the protocol supports it. The receiver should know who is calling, for whom, and under which delegation chain.

SPIFFE and cloud workload identity systems avoid static bootstrap secrets by asking a local platform component or identity service to attest the workload. Selectors can include Kubernetes namespace and service account, Unix process attributes, cloud instance identity or managed workload evidence. The issuer maps those verified properties to a workload identity.

The credential is then delivered over a local workload endpoint or cloud metadata path and rotated automatically. Short lifetimes reduce the value of theft and make lifecycle changes visible. Rescheduling a workload can produce fresh evidence rather than reusing a certificate copied from an old instance.

Attestation is only as strong as its selectors and trust root. Broad selectors, mutable image tags, compromised nodes or an overpowered delegated identity broker can issue convincing credentials to the wrong process. Registration and broker permissions therefore require the same governance as privileged IAM roles.

Bearer tokens can be replayed by anyone who obtains them. Mutual TLS and DPoP bind token use to a client key, reducing the usefulness of a copied token. Resource indicators and audience claims limit where a credential is accepted. Short expiry and revocation reduce the time window.

These controls answer whether the presenter possesses the expected key and whether the token was intended for this receiver. They do not answer whether the requested deletion, transfer or account change is appropriate. That question belongs to policy and business validation.

The key used for proof of possession should live in a hardware-backed or isolated key manager when the risk warrants it. The general model runtime should request signatures through a narrow service rather than reading private key material.

OAuth token exchange provides a standard pattern for presenting one token and receiving another for a different audience or actor context. In an agent system, the broker can combine the workload identity with evidence that a user or organization delegated a bounded task. The resulting token should carry less authority than the original principal, not a copy of every permission the user possesses.

Rich authorization details can describe specific action types, objects, limits or purposes more precisely than a broad scope. Approval profiles can represent missing prerequisites such as manager consent or stronger authentication. The policy decision remains external to the model.

Forwarding the user's long-lived access token is attractive because it is simple, but it turns the agent into a bearer of all current user authority and obscures which intermediary made the request. Exchange and attenuation create a narrower, auditable boundary.

OAuth scopes and IAM roles are often too coarse for dynamic agent tools. The important question may be whether this specific agent, acting for this user, can invoke this tool with these arguments against this tenant at this moment. AuthZEN's subject-action-resource-context model and policy decision point pattern make that question explicit.

The policy enforcement point sits at the tool gateway or API boundary. It normalizes the request, validates the identity and delegation evidence, and asks a decision service. The policy engine can combine static rules with current risk, data classification, approval state and resource ownership.

The model must not be able to alter the policy bundle, skip the gateway or reinterpret a deny. Unknown actions, claims, policy versions or context should fail closed. A policy outage should preserve read-only or human routing where designed, not default to broad access.

Agent frameworks can create temporary specialists, remote agents or background workers. Each new actor creates another place where credentials can leak or authority can expand. A child must receive a new identity and a grant derived from its parent, not inherit unrestricted access to the parent's credential store.

Attenuation means the child has a subset of resources, actions, duration and onward-delegation rights. A maximum depth prevents an agent from creating an unbounded chain whose effective authority becomes impossible to reason about. The parent remains accountable for the delegation it initiated, while the child remains independently identifiable.

Task completion, cancellation or parent revocation should terminate child authority. Orphaned subagents with valid credentials are a lifecycle failure even if each token is cryptographically correct.

Federation lets one organization accept identities or tokens issued by another, but technical signature validation is only the beginning. The receiver must decide which issuers, assurance methods, claim mappings, policy versions and delegation semantics it trusts.

Workload identity federation can exchange an external platform identity for a local cloud token without distributing long-lived keys. SPIFFE trust-domain federation exchanges bundles so workloads can authenticate across domains. OpenID and OAuth profiles are exploring how agent and user identity can cross enterprise MCP boundaries.

Claim mapping is a common failure point. A subject string, role or tenant attribute may have different meaning in another domain. Receivers should map to local canonical identities and policies, deny unknown semantics and limit federation to named resources and audiences.

A user's employment, device posture, account risk, manager approval or resource classification can change while an agent is still running. Waiting for an hour-long token to expire may be unacceptable. Revocation, introspection, continuous access evaluation and shared security signals allow policy to reflect new facts.

The system should define which events invalidate new actions, terminate sessions, revoke child grants or require step-up approval. Distribution latency becomes a measurable security property. A decision point that cannot reach current state should not assume the old grant remains valid indefinitely.

Revocation also needs recovery semantics. A paused task should preserve enough context for a user or operator to review what happened without retaining reusable credentials or automatically resuming after the risk clears.

A useful audit record links the delegating principal, workload identity, session, subagent, token issuer, audience, policy version, normalized action, decision, approval evidence and downstream result. A generic line saying that 'the agent used tool X' is insufficient for investigation or dispute.

Sensitive tokens, private keys and unnecessary prompt content should not enter the audit store. Hashes or stable references can connect artifacts held in separate protected systems. Decision evidence should be immutable enough to show which policy and inputs were used at the time.

Outcome reconciliation completes the chain. Authorization proves permission to attempt an action; it does not prove the action succeeded or remained committed. The final resource state should be captured and linked to the decision.

Multi-tenant agents often share model infrastructure, gateways and tool adapters. A shared service identity can accidentally turn a tenant identifier supplied by the model into the only isolation boundary. Prompt injection or a simple parsing error may then route a valid credential to the wrong customer's resource.

Tenant must be derived from authenticated context and bound into the token audience, resource identifier and policy request. The model may select among resources already authorized for that tenant, but it should not define the tenant itself. Cross-tenant administrative tools require separate identities and stronger approvals.

Tests should include confused-deputy calls, altered tenant IDs, reused session caches, vector-store leakage and subagents created under one tenant but executed under another.

Teams need an inventory of agent services, owners, environments, models, tools, credentials, delegated principals and policy dependencies. Every identity should have a creation, rotation, review, suspension and retirement process. Temporary experiments should not quietly become permanent service accounts.

Start with low-risk actions and narrow identity mappings. Observe denials, approval frequency, token-exchange failures, revocation latency and policy drift. Expand authority only when evidence shows that the current controls are reliable and operators can investigate failures.

Incident response must include the ability to stop token issuance, revoke a trust relationship, disable a tool, terminate child agents and preserve evidence. A single global kill switch for new consequential actions is often more useful than trying to patch prompts during an identity incident.