Attribute Schema

Standard ABAC answers may this principal access this data. AI workloads need a larger question answered: may this principal, acting for this purpose, process this data on this class of model, and deliver the result to this destination.

That requires attribute dimensions most tenants do not have at initial setup. This page covers which to add and what each one is load-bearing for.

Attributes are configured in the tag schema and the identity attribute mapping, depending on whether they describe data or principals.

Principal attributes

Subject type

Values: human, service, agent, tool, workflow

The most important attribute in this section, and the one to configure first. It distinguishes what kind of principal is making a request.

Without it, an agent operating on a user's behalf is indistinguishable from the user, which means every constraint you place on autonomous operation is unenforceable. Policies that reference subject type can express requirements that have no equivalent in role-based access control:

• Restricted data may be read by a human principal directly, but not by an agent acting for that human.
• An agent may read a class of data but not forward it to another agent.
• A tool may return a data class into a reasoning loop only when the invoking workflow carries an authorized purpose.

Configure this as a mapped identity attribute, not as something the caller declares. A principal that can assert its own subject type can assert human.

Delegation chain

Values: ordered principal references

Where an agent acts for a user, and possibly for another agent before that, policy needs the whole chain rather than just the immediate caller.

The rule to configure toward: a delegated principal never holds more authority than the principal it acts for. Attributes narrow along the chain; they do not accumulate. If an agent invoked by user A hands work to a second agent, the second agent's effective attribute set is bounded by A's, not widened by the first agent's.

Model this explicitly. Left implicit, a multi-agent workflow tends to accumulate authority as it fans out, because each hop authorizes against the immediate caller.

Data and request attributes

Purpose

Values: training, fine-tuning, evaluation, inference, retrieval, summarization, export

Purpose is what makes AI policy meaningfully different from file-access policy. It controls what a workload may do with data it can otherwise read.

The distinctions that matter most in practice:

• Inference vs. training. Data readable for answering a question at runtime is frequently not permitted to become permanent model weights. This is the single most common AI governance requirement and it is unexpressable without a purpose attribute.
• Evaluation vs. fine-tuning. A held-out set authorized for measuring model quality is not thereby authorized for training.
• Summarization vs. export. Generating an internal summary is a different risk than emitting content to an external destination.

Purpose must be supplied by the calling workload and validated against policy, it is a declared intent that the decision plane checks, not a trusted claim. A request declaring inference against a dataset restricted to evaluation is denied.

Model class

Values: tenant-defined; commonly a composite of provider, deployment location, and capability tier

Policy frequently varies by where the model runs rather than by what it can do. Typical requirements:

• A classification tier that may only be processed by a model deployed inside your own boundary.
• A regulated data class that may not reach a third-party inference API under any circumstances.
• A capability tier restriction, where only a reviewed model version may touch a given data class.

Define the values that correspond to real decisions in your environment. A three-value schema (for example internal-hosted, dedicated-tenant, shared-external) is usually more useful than an enumeration of every model you might call, because the policy question is almost always about the trust boundary rather than the specific model.

Model class is an attribute of the request, asserted by the orchestration layer and validated at the enforcement point.

Output destination

Values: human-ui, agent, service-api, persistent-storage, external

Where a generated result is allowed to land is a separate decision from whether it could be produced. Configure this dimension if you have any requirement of the form "the model may reason over this, but the answer may not leave this boundary."

Destination attributes are evaluated at the output boundary. See Output Controls.

Source trust

Values: tenant-defined trust tiers plus lineage references

Provenance-based policy. Two distinct uses:

• Admission. Reject content originating from an untrusted or unattributable source before it reaches a model or a corpus. This is the primary control against indirect prompt injection through ingested documents.
• Propagation. A derived artifact inherits the trust tier of its least-trusted input. A summary of a low-trust document is a low-trust artifact, and policy can treat it accordingly.

Trust tiers should be few and meaningful. Three tiers that map to real handling differences are more useful than a numeric score nobody can interpret consistently.

Attribute freshness and missing values

For each AI attribute, configure two properties explicitly:

Freshness requirement. How recently the attribute must have been observed to be usable in a decision. Device posture and threat signals go stale in minutes; organizational role does not. An attribute past its freshness window is treated as missing.

Missing-value behavior. What happens when a required attribute is unavailable. The safe configuration for AI workloads is denial — an autonomous system operating on incomplete attribute state is exactly the condition you configured the attribute to prevent.

Lattix will not silently skip a required attribute it cannot resolve. If a required attribute is unavailable or stale, the decision resolves according to your configured missing-value behavior, and the reason appears in the decision record. There is no path where an unresolvable attribute becomes an implicit allow.

Worked example

A policy expressing "customer PII may be summarized at inference time by an internally hosted model for a human analyst, but may never be used for training and may never be delivered to an external destination" evaluates roughly:

Every dimension is a separate deny condition. All must be satisfied; any one unproven denies the request.

Related

• Tag Schema, where data attributes are defined.
• Identity, where principal attributes are mapped.
• Policies and ABAC, how attributes combine into a decision.
• Workload Identity, issuing identities to the non-human principals these attributes describe.