jenkinsci / jenkinsci/explain-error-plugin
Feature: Log sanitization and send-before-preview for LLM payloads
- Dominant language
- Java
- Stars
- 44
- Forks
- 24
- Avg merge
- 12h 4m
- Merged PRs (30d)
- 2
Description
## Summary
Add a log sanitization layer that runs on the build log payload *before* it is sent to any AI provider, along with an optional preview/audit mechanism so admins can verify what is being transmitted.
## Motivation
The plugin sends build log content to external AI providers (OpenAI, Bedrock, Azure, etc.). Enterprise users reasonably worry about whether those logs contain:
- API tokens, passwords, secret keys
- Internal hostnames / IPs / URLs
- Customer data or PII
- License keys
- Private artifact paths or repository info
While the workspace context feature already skips known sensitive files (`.env*`, `credentials*`, `target/`, `build/`, `.git/`, etc.), that operates at the *file* level when gathering workspace context — it does not scrub the *log output* itself. Logs can easily leak secrets through environment variable dumps, command output, or error traces.
## Proposed Capabilities
1. **Sanitize before sending to LLM** — a configurable regex-based scrubber applied to the log excerpt before it hits the provider API.
- Common preset patterns for tokens, keys, passwords, URLs, IPs
- Mask matches with `[REDACTED]` (or a configurable string)
2. **Preview payload before sending (optional)** — a "dry run" mode or preview panel in the Jenkins UI that shows what *would* be sent, so admins can audit before enabling live sanitization.
3. **Audit what was sent** — log (to Jenkins system log, at a minimum) a sanitized summary of each request: provider, model, log line count, lines redacted, timestamp.
4. **Allow/deny regex policy** — let admins define custom patterns, with a choice to block sending entirely if certain patterns are detected (i.e., fail closed) vs. redact and proceed.
## Non-Goals (for this issue)
- Row-level encryption or tokenisation
- Full DLP integration
- Workspace context changes (already handled separately)
## Notes
This is scoped as an opt-in, configurable feature. Default behaviour (no sanitization) stays unchanged for backward compatibility.
Contributor guide
Assessment
This issue has not been assessed yet.