AI Security

This section covers how to set Lattix up so that AI workloads in your environment operate under the same data-layer controls as everything else: every artifact protected, every access decision authorized, every output governed, every action recorded.

It is written for the person doing the configuration, a platform engineer, AI platform owner, or security architect wiring Lattix into an existing AI stack. It assumes you have read Platform Overview and are comfortable with the core concepts.

The problem this solves

An AI system is not a single application with one access boundary. It is a set of surfaces that each touch data independently:

• A retriever pulls document chunks into a context window.
• A memory store persists conversation and task state across sessions.
• A tool returns business data into a model's reasoning loop.
• An agent hands work (and data) to another agent.
• A training pipeline admits samples into a corpus.
• An output path delivers a generated response to a human, a system, or another agent.

Every one of those is a place where data can reach a principal that should not have it, and where a generated claim can leave the system without a source behind it. Conventional controls do not cover them, because the request that moves the data does not look like a user opening a file. It looks like an internal function call inside a workflow that a network or application boundary already admitted.

Lattix treats each of those surfaces as a data-access boundary and applies the same protected-object model to all of them.

What "outside the model" means in practice

The central design rule is that no model participates in its own governance. Concretely:

• The component that decides whether data may be released is not the model, is not reachable from a prompt, and does not accept model output as an input to the decision.
• Decisions are deterministic. The same request, against the same policy version and attribute state, resolves identically every time. There is no sampling and no scoring model in the decision path.
• Decisions are grounded in your configured attributes and classifications rather than in inference about what a document probably contains.

This is why prompt injection has a limited blast radius here. An injected instruction can change what a model says. It cannot change what a model is given, because the authorization for that data was resolved before the model saw anything, by something the prompt never reaches.

It is also why hallucinated content does not silently pass an output boundary. Where you require provenance, an assertion that cannot be traced to an authorized source artifact is denied rather than delivered with lower confidence. See Output Controls.

Setup order

The pages in this section are ordered as a build sequence. Following it out of order generally works, but each step assumes the previous one:

1. Prerequisites, what must exist in the tenant before AI-specific configuration is useful.
2. Attribute Schema, extend your tag schema and attribute set with the AI-specific dimensions policy needs.
3. Workload Identity: register agents, services, and tools as first-class principals, distinct from the humans on whose behalf they act.
4. Retrieval and Context: authorize retrieved content per item, before it enters a context window.
5. Agents and Tools: protect tool payloads and cross-agent messages, and bound what each agent may do.
6. Output Controls: configure the transforms, provenance requirements, and destination rules applied to generated content.
7. Training Data, bind datasets to a purpose and authorize corpus admission per sample.
8. Verified Controls, the validation and approval lifecycle a control set passes through before it can enforce anything.
9. Audit and Evidence: what gets recorded, and how to answer the questions an auditor or incident responder will ask.

Steps 1 through 3 are foundational and should be completed before you integrate any AI surface. Steps 4 through 7 can be adopted independently and in any order, most teams start with retrieval, because that is where the largest volume of sensitive data moves.

What this section does not cover

• Model selection, prompt engineering, or evaluation quality. Lattix governs the data and the actions, not the quality of a model's reasoning.
• Inference hosting. Lattix is model-agnostic and sits at the orchestration layer. Where your models run is your decision; it becomes a policy attribute, not a platform dependency. See Attribute Schema.
• Agent framework internals. Integration points are described in terms of the primitives every framework has (retrievers, memory, tools, callbacks) rather than per-framework recipes. Framework-specific integration guides are delivered with your deployment.

Related reading

• Policies and ABAC, the decision model these controls are built on.
• Trusted Data Format, the envelope every protected AI artifact is wrapped in.
• Model Context Protocol, connecting MCP clients to the Lattix control plane.
• AI Security overview, the architectural summary, for a non-implementation audience.