Privacy Metadata Rules

Purpose

Use these rules when reviewing privacy metadata for an AI workflow directory entry. The goal is to make privacy-relevant facts visible before users install, copy, run, recommend, or submit a workflow.

This is not a legal compliance checklist. It is an editorial rule set for directory maintainers and contributors: name the data touched, name where it goes, name what is retained or unknown, and keep the evidence fresh.

Required Metadata

Every entry that can touch private context should answer these questions.

1. What data is touched? Prompts, source files, generated files, logs, tickets, browser state, clipboard content, secrets, embeddings, telemetry, datasets, screenshots, transcripts, model outputs, or customer-like examples.
2. Where does it run? Local shell, local app, browser extension, MCP server, hosted API, cloud worker, SaaS integration, CI job, notebook, or background automation.
3. Where can data go? Model provider, tool vendor, third-party API, local disk, logs, vector store, issue tracker, pull request, metrics backend, public artifact, or generated documentation.
4. What is retained? Nothing known, local files only, request logs, transcripts, analytics, cache entries, uploaded files, embeddings, traces, or unknown retention.
5. Who controls access? The local user, project workspace, organization account, vendor account, shared team space, public repository, or downstream service.
6. What evidence supports this? Documentation, source code, package metadata, configuration examples, policy pages, changelog notes, or maintainer review.

If a field is unknown, write "unknown" with the reason. Do not silently omit it.

Review Rules

• Require privacy notes when the workflow reads or writes private context.
• Distinguish local execution from hosted processing.
• Distinguish user-controlled storage from vendor-controlled retention.
• Describe generated artifacts that can leak private data, such as summaries, screenshots, traces, notebooks, reports, indexes, embeddings, or README output.
• Record provenance for privacy claims: source URL, reviewed file, policy page, or maintainer note.
• Include a last-reviewed date or freshness note when privacy behavior depends on external documentation.
• Keep examples synthetic. Do not use real secrets, account IDs, customer names, private repository names, or production incidents as sample metadata.

Privacy Note Patterns

Use direct, observable wording. Good privacy notes say what may be exposed and where.

• "This workflow reads local source files and sends selected snippets to a hosted model provider."
• "The command writes generated reports to the repository; review them before committing because they may include private file paths or excerpts."
• "The MCP server can access issue titles and comments through the configured account permissions."
• "Retention behavior is not documented in the source material; treat uploaded prompts and files as vendor-processed until confirmed."
• "Telemetry can include command names, timestamps, project identifiers, or anonymized usage counts; do not include secrets in labels or run names."

Avoid vague notes such as "privacy safe," "no risk," "secure by default," or "does not store data" unless the source evidence says exactly what is not stored.

Grounded Reference Table

The review rules above map directly onto established application-security guidance. The OWASP Logging Cheat Sheet is the primary anchor: it enumerates the data categories that must not be captured in logs or artifacts, requires bounded retention, and demands due-diligence checks before data leaves for a third party. Use the table below to trace each metadata field back to a published practice.

This table does not restate the reviewer prompt in copySnippet; it documents the external evidence behind the field definitions so a maintainer can verify each rule against current guidance.

Directory Entry Checklist

• {"task": "Data touched", "description": "The entry names prompts, files, logs, browser state, secrets, telemetry, generated artifacts, or personal data it may touch"}
• {"task": "Execution surface", "description": "The entry says whether processing is local, hosted, browser-based, MCP-based, CI-based, or third-party API-based"}
• {"task": "Data movement", "description": "The entry names where data can be sent, stored, logged, cached, exported, or published"}
• {"task": "Retention known", "description": "Retention, logging, cache, transcript, trace, artifact, or unknown behavior is stated plainly"}
• {"task": "Source evidence", "description": "Privacy claims are backed by current docs, source code, package metadata, policy pages, or maintainer review"}
• {"task": "Freshness noted", "description": "The reviewer can tell when the privacy metadata was last checked or why it is still current"}

Do Not Merge When

• the entry says "no privacy impact" but reads prompts, files, logs, browser state, secrets, customer-like examples, or generated artifacts;
• hosted processing is described as local-only;
• telemetry, retention, uploads, caches, traces, or generated reports are omitted even though the workflow can create them;
• private examples are copied into public metadata;
• vendor claims about privacy are repeated without a source URL or reviewed source file;
• unknown retention or sharing behavior is hidden instead of disclosed.

Troubleshooting

• The docs do not mention retention: say retention is unknown and require a maintainer review before presenting the workflow as privacy-preserving.
• A tool runs locally but calls a hosted model: describe both surfaces.
• The entry has privacy notes but no source evidence: ask for the policy, repo file, package docs, or configuration page that supports the notes.
• Generated artifacts may include private data: require a review step before committing or publishing those artifacts.
• The submitter wants to keep metadata short: keep the card short, but put the privacy facts in the entry body where users can inspect them.

Duplicate Check

Checked existing rules, guides, collections, hooks, skills, MCP entries, statuslines, registry quality code, submission policy code, and recent PRs for privacy metadata rules, privacy notes, data touched review, retention metadata, privacy policy routing, data provenance, and AI workflow directory privacy.

Adjacent content includes a privacy-first research collection and registry quality helpers that score privacy metadata. This rules entry is distinct because it gives portable do/don't behavior for contributors and reviewers who must decide whether any AI workflow directory entry has enough privacy metadata to merge.

DPV Concept Mapping

The W3C Data Privacy Vocabulary (dpv, namespace https://w3id.org/dpv#) provides standardized top-level concepts that map onto the privacy facts these rules ask reviewers to capture. Use the DPV term as a shared vocabulary when a submitter's privacy notes need a precise label.

References

• OWASP Logging Cheat Sheet (what not to log, retention, third-party due diligence): https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
• OWASP User Privacy Protection Cheat Sheet (transparency, user control): https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html
• OWASP Logging Vocabulary Cheat Sheet (consistent, sensitive-value-safe field names): https://cheatsheetseries.owasp.org/cheatsheets/Logging_Vocabulary_Cheat_Sheet.html
• W3C Data Privacy Vocabulary (personal-data categories, processing purposes, provenance): https://w3c.github.io/dpv/2.3/dpv/

• Source repositorygithub.com 2026-07-19T11:20:19-07:00
• Documentationcheatsheetseries.owasp.org
• Submitted by MkDev112026-06-04