What is log-sanitization?

A set of rules for keeping passwords, tokens, API keys, and other credentials out of server logs. It requires explicit redaction at log call sites and a global filter as a backup.

Use it when logging parameters, URLs, access tokens, or other request details in a server application.

It reduces the risk that secrets are exposed through logs, which are often stored, copied, or accessed by more people than the application itself.

log-sanitization — Cursor rule by microsoft

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods

npx agentmods add rules/microsoft/data-formulator/log-sanitization

Clone the repo

git clone --depth 1 https://github.com/microsoft/data-formulator

Made for: Cursor.

Per session 0 Nothing until a file matches its globs; then the whole rule loads.

When invoked 1,027 The whole file, excluding the scripts and references it only reads on demand.

Security scan A 0 findings. Scan, not verified.

Origin original No closer match found in the catalogue.

Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

Model	Per session	Once invoked
Fable 5	$0.00000	$0.01027
Opus 5	$0.00000	$0.00513
Sonnet 5	$0.00000	$0.00205
Haiku 4.5	$0.00000	$0.00103

Measured yesterday against content hash 22aa7feb8a62, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

log-sanitization scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

.cursor/rules/log-sanitization.mdc · 108 lines

How it starts

The opening of the file, as written. The whole thing — 108 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Log Sanitization

Server-side logs must never contain passwords, tokens, API keys, or other credentials in plain text. This rule complements error-response-safety.mdc (which covers client responses) by addressing the logging side.

Architecture: Defense in Depth

Two layers protect against sensitive data in logs:

Layer 1 — Explicit utilities (call-site): developers use sanitize_url(), sanitize_params(), redact_token() from security/log_sanitizer.py.
Layer 2 — SensitiveDataFilter (global): a logging.Filter registered on all handlers in configure_logging() auto-redacts patterns that slip through.

Layer 1 is the primary defense; Layer 2 is a safety net. Both are required.

When to Use Each Utility

Data Type	Utility	Example
`dict` with password/secret/token keys	`sanitize_params(params)`	`log.info("Init: %s", sanitize_params(params))`
URL (may have `user:pass@host` or sensitive query params)	`sanitize_url(url)`	`logger.info("Connecting to %s", sanitize_url(url))`
Bearer / access token	`redact_token(token)`	`logger.debug("Token: %s", redact_token(token))`
Normal string (no secrets)	Nothing needed	`logger.info("Processing table %s", name)`

Rules

Never log raw params / config dicts that may contain password, secret, api_key, token, or connection_string keys. Always use sanitize_params().
Never log full tokens or API keys. Use redact_token() if you need to identify a token in logs.
Prefer type(exc).__name__ over str(exc) in warning/info logs when the exception may contain connection strings or upstream response bodies. Use exc_info=True for full tracebacks at ERROR level (the filter sanitizes exc_text).
URL logging — use sanitize_url() for any URL from configuration or environment variables (issuer URLs, JWKS URLs, database URLs, API base URLs). It masks embedded credentials and sensitive query parameters such as password, client_secret, token, and api_key.

Read the full file on GitHub · 108 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

yesterday First seen · 108 lines · 0 tokens per session scan A 22aa7feb8a62

Subscribe to this mod's changes

log-sanitization is a cursor rule published in the GitHub repository microsoft/data-formulator (17,048 stars, last pushed 3d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 1,027 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.

Backend and APIs

log-sanitization

Getting it into your agent

What it costs to keep this loaded

Grade A, and why

Nothing flagged

How it starts

Log Sanitization

Architecture: Defense in Depth

When to Use Each Utility

Rules

What this file has done since we first saw it

Other cursor rules, from other repositories

angular-20

dev-standard

typescript

coolify-ai-docs

python_lib

specs