AI Security

Prerequisites

What must exist in a Lattix tenant before AI-specific configuration is meaningful: identity, classification, policy, and connector baseline.

AI governance in Lattix is not a separate subsystem. It is the existing policy, classification, key, and audit machinery applied to a new set of principals and surfaces. That means the AI-specific configuration is only as good as the foundation under it.

Complete these before wiring any AI surface.

1. Tenant baseline

Standard tenant setup must be complete: organization profile, administrative roles, and a retention baseline that covers your AI audit volume.

Note the retention interaction specifically. AI workloads produce substantially more decision events than human workflows, a single agent task may generate hundreds of authorization decisions. Set the retention baseline against the regulatory requirement, not against expected volume, and size accordingly.

2. Identity and attribute source

Identity configuration must be in place, with attribute mapping from your identity provider.

For AI specifically, confirm two things:

  • Human principals carry the attributes your policies will evaluate. An agent acting on behalf of a user can only inherit constraints that are actually present on the user's attribute set.
  • Service and workload principals can be issued their own identities. An AI agent must not authenticate as an end user. See Workload Identity for why this matters and how to configure it.

If your identity provider cannot issue distinct credentials for non-human principals, resolve that before proceeding. Everything else in this section depends on it.

3. Tag schema

A tag schema must be defined and in use. AI policy is expressed against classification, so an environment where most data is untagged will produce policies that are either uselessly permissive or uselessly restrictive.

You do not need a perfect schema. You need one that is:

  • Applied to the data your AI workloads will actually touch. Coverage matters more than granularity at this stage.
  • Stable enough to write policy against. A schema still under active debate will produce policy churn.

If classification coverage is thin, connectors will close most of the gap, see step 5.

4. At least one working policy

Before adding AI attributes, you should have at least one non-AI policy authored, tested, and enforcing successfully through the Policy Engine. This confirms that identity, attributes, classification, and enforcement are correctly wired end to end.

Debugging an AI retrieval denial is considerably harder when the underlying cause is a general attribute-mapping problem that would have been obvious in a simple file-access policy.

5. Connectors for the data your AI reads

If your AI workloads read from systems Lattix does not yet see (object storage, a document repository, a knowledge base) configure connectors for those systems first.

This is the step teams most often skip, and it produces a specific failure: retrieval authorization works correctly for protected artifacts and silently passes through everything else, because unprotected content has no policy to evaluate. An AI system reading from a mix of protected and unprotected sources is governed only over the protected fraction.

Decide explicitly how unprotected content is handled at the retrieval boundary (admitted, denied, or admitted with a marker) rather than inheriting a default. See Retrieval and Context.

6. Audit export path

Configure audit export to your SIEM before you start generating AI decision volume. AI events carry additional identifiers (session, agent, model class, workflow) and your SIEM ingestion mappings need to accommodate them. Establishing this early avoids a retroactive backfill.

Readiness check

You are ready to proceed when all of the following are true:

  • A human principal and a service principal can each authenticate and receive a correct attribute set.
  • A protected artifact can be wrapped and unwrapped under policy, with the decision visible in the ledger.
  • Classification is applied to the data your first AI workload will read.
  • Audit events are arriving in your SIEM with the expected fields.

If any of these is unverified, fix it before continuing. Every subsequent page assumes all four.