DLP rules for AI agent activity logs that preserve useful evidence.

Apply DLP to the record path, not to an imagined “agent transcript.”

An agent run can cross several evidence boundaries: a human request, model input and output, an authority decision, tool arguments, a tool result, a changed system, and a final summary. Copying all of those into one searchable log creates a second concentration of secrets, personal data, source code, and customer records.

A useful DLP design identifies where sensitive content can enter, which activity moves it, and what control response applies. It does not assume that one keyword rule can make an unrestricted transcript safe.

1. Map five places sensitive content can escape.

1. Capture. Instrumentation records prompts, messages, file contents, tool arguments, or results before minimisation.
2. Transport. Exporters, queues, browser uploads, CI artefacts, or support bundles move the record to another trust zone.
3. Storage. A trace backend, data lake, log index, workflow summary, or downloadable handback retains it.
4. Access. Search, dashboards, alerts, AI assistants, and broad roles expose more content than the reviewer needs.
5. Reuse. Debug exports, tickets, model evaluation sets, and incident reports turn temporary evidence into a new dataset.

Put a control at the earliest reliable boundary. A dashboard mask is useful for display, but it does not undo sensitive content already exported and indexed.

2. Define the rule as data + location + activity + response.

Microsoft Purview describes DLP policies in terms of sensitive information, where it appears, the activity being monitored, and the protective action. The same decomposition works even when you use a different control stack.

rule: agent-record-sensitive-content-v1
data:
  - credentials, tokens, cookies, private keys
  - regulated identifiers and customer records
  - source code or file contents outside approved paths
location:
  - telemetry exporter, CI artefact, review handback
activity:
  - write, upload, paste, share, or long-term retention
response:
  - remove field; replace with typed marker; alert; require approval; block
evidence_retained:
  - rule id and version
  - matched data class (not the matched value)
  - action taken, override or approval reference
  - protected source reference and unresolved verification gap

Keep the matched secret or personal value out of the DLP event itself. A detection record that repeats the sensitive value defeats the control.

3. Use an allow-list for the default review projection.

OpenTelemetry recommends minimising sensitive telemetry at instrumentation and using processor controls such as deletion, hashing, filtering, and redaction before export. For agent activity, an allow-list is easier to review than an ever-growing deny-list.

• Keep by default: event time, workload identity, operation name, bounded target type, policy decision, status, timing, correlation IDs, evidence class, unknowns, and next human decision.
• Replace with a marker: prompt present, file read, argument suppressed, result suppressed, or personal data detected.
• Keep only by protected reference: native log event, source document, approval record, tool response, or downstream receipt.
• Never copy into the handback: access tokens, secrets, session cookies, private keys, raw credentials, or hidden model reasoning.

Hashing is not a universal anonymisation step. Low-entropy identifiers and known values may still be guessable. Use keyed pseudonymisation or omit the field when correlation is not required.

4. Separate DLP evidence from execution evidence.

OBSERVED   tool call update_customer was recorded
GOVERNED   policy agent-record-sensitive-content-v1 allowed metadata only
PREVENTED  raw tool result was removed before export
OBSERVED   downstream API returned HTTP 200
UNKNOWN    whether the intended customer record is now correct
NEEDS HUMAN read back the target record and approve or investigate

A DLP match proves that a rule observed a pattern at one inspection point. A block proves that the controlled activity was prevented there. Neither proves that the agent did nothing elsewhere, that the record is complete, or that the business outcome is correct.

5. Roll out audit, warning, and blocking deliberately.

Microsoft documents audit-only, warning, override, and blocking patterns for endpoint DLP. A safe rollout uses those modes as distinct experiments rather than jumping from no visibility to a blanket block.

1. Audit. Measure matches, false positives, uninspected formats, and legitimate review needs without storing the matched value.
2. Warn. Give the operator a specific reason and a safe alternative, such as a metadata-only export.
3. Require authority. Record who or what approved an exception, the rule version, scope, and expiry.
4. Block. Prevent high-confidence credential and regulated-data egress where no legitimate exception exists.
5. Verify. Test the actual exporter, CI artefact, browser path, and backend—not only the policy definition.

Acceptance checks for an agent-log DLP rule.

Official references.

• OpenTelemetry: handling sensitive data
• Microsoft Purview: learn about data loss prevention
• Microsoft Purview: endpoint DLP policy scenarios
• Microsoft Purview: DLP policy conditions and actions reference
• NIST SP 800-92: Guide to Computer Security Log Management