Workload Identity

Every AI component that touches data needs its own identity. Not a shared service account, and not the end user's token forwarded down the call chain.

This is the configuration step with the highest ratio of importance to effort, and the one most commonly done wrong.

Why a user token is not a workload identity

The convenient pattern is to take the user's token at the front door and pass it to every component behind it. The retriever uses it, the tool uses it, the agent uses it. Access appears correct: everything runs with exactly the user's permissions.

This breaks in three ways that matter specifically for AI:

You cannot constrain autonomy. If an agent presents the user's identity, no policy can distinguish "the user read this file" from "an autonomous process read this file on the user's behalf, unattended, three hundred times, at machine speed." Those are different risks and you have lost the ability to treat them differently.

You cannot scope a compromise. An agent that can be induced by injected content to make requests is, under a forwarded user token, an attacker with the user's full permissions. With its own identity carrying its own narrower attribute set, it is an attacker with the agent's permissions — which you configured to be the minimum the task requires.

You cannot attribute an action. An audit record showing the user's identity for an action a model initiated is a record that cannot answer the question it will be asked during an incident.

Lattix will not accept an end-user token as proof of workload identity at a protected boundary. A workload presenting only a user credential is treated as an unauthenticated workload, and protected operations are denied.

What to register

Register a distinct principal for each component that independently requests data:

Resist the pull toward one identity per instance. Per-instance identities produce an unmanageable principal population and no additional policy expressiveness, since policy is written against roles.

Credential model

Workload credentials must be:

• Short-lived. Issued for a bounded window and renewed, not long-lived static secrets. This is the single most effective control against credential theft from an agent runtime.
• Bound to the workload. Issued by your platform to a specific verified workload rather than embedded in configuration or an image.
• Distinct per principal. Sharing one credential across agent roles collapses them into a single principal regardless of how they are registered.

Where your platform supports mutual TLS with issued workload certificates, use it. Where it supports short-lived signed tokens with an audience claim, that is equally acceptable. Do not mix: a partially configured transport is rejected at startup rather than falling back to an unauthenticated path.

Configuration specifics for your deployment's credential issuance are delivered with your deployment. This page covers the model; your operational runbook covers the mechanics.

Delegation

Most AI requests are made on someone's behalf. Configure the delegation chain so that relationship is explicit in the request rather than implied.

The invariants Lattix enforces:

• The chain is authenticated at every hop. Each participant proves its own identity; it does not merely assert the chain.
• Authority narrows monotonically. A delegated principal's effective attribute set is the intersection of its own and those of the principal it acts for. It never widens.
• The chain is recorded. Every decision record carries the full chain, so an action taken four hops from a human is still attributable to that human.
• Depth is bounded. Configure a maximum delegation depth. An unbounded chain is a way for a workflow to launder authority through enough hops that nobody can reason about the result.

The practical configuration question is what an agent should be allowed to do when acting for a user versus on its own schedule. A scheduled agent with no human in the chain has no delegated authority to inherit, it holds only its own attributes. Set those deliberately; they are the entire authority of every unattended task that agent runs.

Capability scoping

Beyond identity, bound what each workload may do:

• Data scope. Which classifications and which sources the principal may request at all. This is ordinary policy, but write it narrowly for agents, an agent's data scope should be the task's requirement, not the invoking user's entitlement.
• Action scope. Which purposes the principal may declare. A retrieval service should not be able to declare training.
• Rate and volume bounds. A ceiling on request volume per window. This does not prevent misuse on its own, but it converts a silent high-volume extraction into a visible, alertable event.
• Tool allowlists. For agents, the set of tools invocable at all. Deny by default and add.

Verification

Before integrating an AI surface, confirm:

1. The workload authenticates with its own credential and receives its own attribute set, not the user's.
2. A request presenting only a forwarded user token is denied at a protected boundary.
3. A delegated request records the full chain in the decision record.
4. An agent requesting data outside its configured scope is denied, and the denial reason is legible.
5. Revoking the workload's credential immediately stops its access, without requiring a restart of the AI stack.

Step 2 is the one worth actually testing rather than assuming. It is the control that everything else on this page rests on.

Related

• Identity, attribute mapping and identity provider configuration.
• Attribute Schema, the subject type and delegation attributes referenced here.
• Agents and Tools, protecting what these principals exchange.
• MCP Authentication, the token model for MCP clients specifically.