Release note · August 1, 2026

A sensitivity label can retain your tenant’s metadata

Removing a visible header or changing a file name does not necessarily remove the governance state a Word package carries. Office can retain sensitivity-label metadata that identifies label and tenant context, records state and method, and may name header, footer, or watermark markings. That is important during an external handoff, but a CI report must not become another way to disclose it.

DocFence 0.11 makes this stored package evidence review-visible as bounded, private inventory. It emits only aggregate counts useful to a gate. The actual label metadata remains inside a local SHA-256 comparison signature.

Two compatible ways Office can retain label state

Modern Office packages can hold an Office 2021 Sensitivity Label Information part. Its labelList records label identity, enabled or removed state, method, tenant site ID, and optional details. Microsoft also specifies how that part relates to the older property model in its LabelInfo/custom-property precedence rules.

Older and compatibility paths can retain MIP metadata in custom document properties such as MSIP_Label_<GUID>_<attribute>, including custom or versioned attributes described in Microsoft’s MIP metadata guidance. DocFence also recognizes the legacy Sensitivity property and Word’s documented header, footer, and watermark content-marking property names from the sensitivity-label property contract.

Counts in reports, private comparisons underneath

Public profile, Markdown, and SARIF output contain only aggregate LabelInfo part, label, enabled-label, removed-label, extension, legacy MIP-label, legacy MIP-property, legacy Sensitivity-property, and Word content-marking-property counts. They do not print label or tenant IDs, label names, methods, dates, action IDs, extension payloads, custom property names or values, marking text, or part paths.

Those fields still matter to a baseline comparison. DocFence fingerprints the full recognized inventory privately, so changing a label name, extension payload, or legacy property can fail a protected baseline even when every public count stays the same. Relationship-ID renumbering by itself remains quiet.

Choose a clean handoff or a protected baseline

For a publishing or external-handoff boundary, reject stored label metadata outright:

rules:
  require_no_sensitivity_label_metadata: true

This produces DFP035. It fails if any sensitivity-label count is nonzero, including an empty recognized LabelInfo part. A template that intentionally carries an approved label needs a different promise:

rules:
  no_sensitivity_label_metadata_changes: true

DFP036 protects that baseline from a later private-inventory mutation. The rule does not turn a label into a security verdict; it establishes an explicit package-state boundary that review can enforce.

Strict package evidence, not label enforcement

DocFence recognizes a modern part through the standard classification-label relationship, the Office SDK content type, or conventional docMetadata/LabelInfo paths. A recognized classification-label relationship must originate at the package root, be internal, and resolve to a stored member. At most one LabelInfo part is accepted. The labelList root, direct label records, required state, tenant-site GUID, and extension-list structure are validated; malformed recognized state fails closed. Recognized legacy properties are found even when a custom-property part uses a noncanonical relationship target.

This is stored-package evidence only. DocFence does not decrypt an IRM-protected file, read LabelInfo from encrypted storage, resolve tenant policy or an effective label, calculate permissions, apply or remove a label, render a header, footer, or watermark, or prove that a label is enforced. Microsoft’s Office sensitivity-label documentation is useful context for why package metadata and client behavior must remain separate claims.

Release evidence

The 0.11 regression suite has 31 tests. It covers same-count LabelInfo name, extension, and legacy-property mutations; JSON, Markdown, and SARIF redaction; policy findings; standard relationship, content-type, and conventional unlinked discovery; malformed roots, attributes, and tenant-site IDs; unavailable, external, and non-root relationships; multiple parts; a noncanonical custom-property part; and relationship-ID churn. The suite ran in Python 3.11 and 3.13 CI. The final wheel was installed outside its source tree, profiled against a labeled fixture, and rebuilt alongside the source archive from the release commit; the two independent builds matched byte-for-byte. Stable unlabelled Open XML SDK Word document and template fixtures reported zero counts.

python -m pip install https://github.com/SybilGambleyyu/docfence/releases/download/v0.11.0/docfence-0.11.0-py3-none-any.whl

docfence profile candidate.docx --format markdown
docfence check approved.docx candidate.docx --policy docfence.yml --format sarif --output docfence.sarif

The public release includes the wheel, source archive, and SHA-256 manifest. The precise rule semantics and limits are in the policy reference and threat model. For the preceding workflow-state boundary, read A Word document can carry a task graph—and an add-in.