Vaikora › Blog › Product Updates

Classification tells your enforcement layer what it's enforcing. Without it, every policy is a guess.

Product Updates · Nov 10, 2026 · 4 min read

Treat the title as a proposition worth testing: a DLP rule that fires on "sensitive-looking content" is pattern matching after the fact. A policy that says "block external transfer of files labeled PCI-DSS in scope" is deterministic. The difference is whether classification exists when enforcement needs it, and that depends entirely on where and when classification happens.

Why late classification fails at the enforcement point

Classification that runs at the perimeter, inside a DLP appliance, or at upload time has already missed several decision windows. By the time data arrives at an edge control, it may have been read by a process, cached in a buffer, or fed into an AI agent as context. The classification label was never attached where the data lived.

For AI agents specifically, this matters a lot. An agent reads a file, extracts a table, constructs a prompt, and calls a tool. Each of those steps is a potential enforcement point. If the file had no classification at the point of creation, there is nothing to query at any downstream gate. The agent's action arrives at the enforcement layer as unlabeled content, and the policy decision degrades to heuristics.

What "at the source" actually means operationally

Source classification means labeling data at the point of origination, before any process reads it. Practically, this involves:

• Applying a persistent, machine-readable label when a document, record, or object is created or ingested
• Storing the label in metadata the enforcement layer can query without re-scanning the content
• Covering structured data (database rows, API responses) as well as files

The label needs to survive the data's movement. A classification stamped in a document property that gets stripped on export is not persistent. A label embedded in a database column's metadata that travels with exports and API responses is.

How enforcement consumes classification at runtime

Consider a concrete scenario. An AI agent is authorized to read customer support records to generate summaries. Some records contain medical information that falls under HIPAA. If those records are classified at ingestion, the enforcement layer can query the label before the agent's read tool call executes. If the destination of the summary is an external endpoint, the policy decision is straightforward: block.

Without source classification, the enforcement layer has to decide in real time whether the content in the prompt looks like PHI. That is probabilistic. It will produce false negatives on obfuscated or structured medical data, and false positives on benign clinical terminology.

Vaikora sits inline between the agent and every tool or LLM it calls. When a data object carries a classification label, Vaikora's policy engine can apply a deterministic allow, block, modify, or require-approval decision against it before execution. When no label exists, the decision falls back to content inspection, which is slower and less reliable. Classification at the source is what makes the enforcement layer deterministic rather than approximate.

The audit consequence

An audit chain that records "blocked because file was labeled PCI-DSS in scope" is defensible. An audit chain that records "blocked because content matched a heuristic pattern" requires explaining the pattern, its accuracy, and the false negative rate. Regulators, auditors, and incident investigators all prefer the former.

Vaikora writes every enforcement decision to a SHA-256 hash-chained, tamper-evident audit log. The quality of that log depends on the quality of the signals going in. Source classification is one of the clearest signals available.

Where to start

If your classification program applies labels only at the perimeter or at rest, map the gap between where data is created and where labels are first applied. That gap is the interval during which any process, including an AI agent, can read and act on data with no enforceable policy attached to it.

Check whether your labels are machine-readable and persistent across export, API access, and copy operations. Then verify that your enforcement layer can query those labels at decision time without re-scanning content. If it cannot, the label exists for reporting, not control.

The practical next step is to identify one data type, one source system, and one enforcement point, and trace the label from creation to policy decision. If you cannot complete that trace, you have found the first gap to close.

More from the Vaikora blog