From payload patterns to provenance-aware DLP

Traditional data-loss prevention inspects content at an egress point. Rules, classifiers, fingerprints, and entropy checks can identify many sensitive payloads. They are useful controls, but an agent can transform, summarize, encode, or mix data before sending it.

Provenance contributes a different signal: did this value derive from a protected source?

Source history changes the decision

Consider two identical-looking outbound values. One was created from a public constant. The other was extracted from a private support ticket and normalized through several string operations.

Payload inspection may treat them the same. Provenance does not.

A runtime lineage record can connect:

private ticket
  -> tool output
  -> model-generated code input
  -> normalize
  -> JSON field
  -> HTTP request body

The policy decision uses that path together with the destination and the applicable declassification rules.

Provenance and content inspection are complementary

Lineage is not a replacement for secret scanners or content classifiers. A source may be unlabeled, a runtime path may be unsupported, or a native dependency may bypass object-level tracking.

A layered system can combine:

• source labels for known protected inputs;
• dynamic propagation for supported runtime values;
• payload inspection at guarded sinks;
• process-level provenance for escaped or unsupported code;
• sandbox controls that limit the remaining effect surface.

The product opportunity is not another universal security detector. It is a deterministic dataflow control at the point where agents turn information into actions.