Slack: Redact Sensitive Information from Messages
Redacts sensitive content from outgoing Slack message arguments before the call reaches Slack.
- Direction
- ingress
- Rego package
slack.ingress.redact_sensitive_info- App
- slack
- Bundle
- slack
- Published
- Minimum gateway
- 1.0.0b24
- Schema version
- 1.0.0
- Checksum
sha256:77ad4d9fd33a830df6c976a3dbcb351e9774b652e48deaf1dd8b84727786679e
slackpiisecretsdlpredactioningress
What this policy does
Direction: ingress (tool_pre_invoke)
Default: allow (transform-only — never denies)
Package: slack.ingress.redact_sensitive_info
What it does
Redacts sensitive content from outgoing Slack message arguments before the call
reaches Slack. It is transform-only — it never denies a call, it only rewrites
matching content to [REDACTED]. Any tool that is not a Slack tool, and any
message with no matches, passes through untouched.
Why ingress
Sending a Slack message is a write with permanent side effects — once the call reaches Slack the content exists in channel history and may be syndicated to search, digests, and other members. Redacting on the request (ingress) path is the only way to keep the secret out of Slack entirely; an egress policy could only mask what is read back, not what was posted.
Scope / tool matching
Applies to any tool whose first hyphen-separated name segment starts with
slack, so it works regardless of how the Slack MCP server is named on a
given gateway (slack-..., slack-prod-..., slack-mcp-...). Confirm the
exact tool names your gateway emits with the dump-input debug technique.
Fields inspected
textandmessage— string bodies; redacted in place when they match.blocks(Block Kit) andattachments(legacy) — serialized to JSON, byte- replaced, then reparsed.
Only fields that actually contain a match are rewritten. Clean fields, absent
fields, and all other arguments (channel, thread_ts, etc.) pass through
unchanged. For blocks/attachments, if the replacement would produce invalid
JSON the field's patch is silently omitted, so the policy never emits malformed
arguments (fail-safe).
What gets redacted
A single alternation pattern covers:
- PII — US SSN, credit-card numbers, email addresses, US phone numbers.
- Cloud / SaaS API keys (vendor-prefixed) — AWS (
AKIA/ASIA), Google (AIza,ya29.), GitHub (ghp_/gho_/ghu_/ghs_/ghr_), GitLab (glpat-), Slack (xox[abprs]-), Stripe (sk_live_/sk_test_/pk_live_/pk_test_). - OAuth / bearer —
Authorization: Bearer <token>and JWTs (header.payload.signature). - Generic secrets —
api_key/apikey/secret_keyandpassword/secret/token/credentials/client_secretassignments. - Database connection strings — URI (
postgres://,mysql://,mongodb+srv://,redis://,amqp://,mssql://), JDBC, and ADO.NET (Server=...;User Id=...;Password=...). - PEM private keys —
-----BEGIN ... PRIVATE KEY----- ... -----END ...-----.
The pattern set is shared with the JIRA egress redaction policy
(jira.egress.redact_sensitive_info). Tune it for your environment — add token
shapes for providers you use, and remove patterns that are noisy for your
traffic.
Examples
Redacted
{
"input": {
"action": "tool_pre_invoke",
"resource": { "name": "slack-mcp-slack-post-message", "type": "tool" },
"payload": {
"name": "slack-mcp-slack-post-message",
"args": { "channel": "C123", "text": "here's the api_key: sk-abcd1234..." }
}
}
}
The text argument is rewritten to here's the [REDACTED]; channel is
untouched. allow = true, plus
reason = "Sensitive content redacted from Slack message" so the redaction
is explained in the dashboard.
Passthrough
{
"input": {
"action": "tool_pre_invoke",
"resource": { "name": "slack-mcp-slack-post-message", "type": "tool" },
"payload": {
"name": "slack-mcp-slack-post-message",
"args": { "channel": "C123", "text": "lunch in 5" }
}
}
}
No match, no transform — args pass through unchanged. allow = true.
Composition
Transform-only and default allow := true, so it composes cleanly with deny
policies on the same ingress pipeline (e.g.
block-secrets,
deny-direct-messages). block-secrets
blocks a message that looks like it contains a secret; this policy redacts
the secret and lets the message through — choose one posture per deployment, or
order them deliberately if you attach both.
Known limitations
- Regex over text. Expect general-purpose false positives (e.g. an email- shaped substring inside a longer token) and false negatives (custom-format or short-lived secrets that match no known shape). Treat this as a high-signal first line of defense, not a complete DLP solution.
- Inspected fields are fixed. Only
text,message,blocks, andattachmentsare scanned. If your Slack MCP server carries body content under another argument, add a corresponding patch rule.
Policy source (Rego)
package slack.ingress.redact_sensitive_info
# Transform-only policy: redacts sensitive content from outgoing Slack message
# args before the call reaches Slack. Never denies. Uses the same pattern set
# as the JIRA egress redact policy (jira.egress.redact_sensitive_info).
default allow := true
# -----------------------------------------------------------------------------
# Tool matching — any tool whose server-name segment starts with "slack".
# Matches "slack-...", "slack3-...", "slack-prod-...", etc.
# -----------------------------------------------------------------------------
is_slack_tool if {
name := lower(input.resource.name)
server_name := split(name, "-")[0]
startswith(server_name, "slack")
}
# -----------------------------------------------------------------------------
# Sensitive-content regex — every shape we want to redact, joined into a
# single alternation so one regex.replace call covers them all per field.
# (?i:...) groups scope case-insensitive matching to specific alternatives so
# vendor-prefixed shapes (AKIA, ghp_, sk_live_, etc.) stay case-sensitive.
# -----------------------------------------------------------------------------
sensitive_pattern := concat("|", [
# ---- PII ----
`\d{3}-\d{2}-\d{4}`, # US SSN
`\d{4}[- ]?\d{4}[- ]?\d{4}[- ]?\d{4}`, # Credit card
`[\w.-]+@[\w.-]+\.[\w.-]+`, # Email
`\+?1?[- .]?\(?\d{3}\)?[- .]?\d{3}[- .]?\d{4}`, # US phone
# ---- Cloud / SaaS API keys (vendor-prefixed) ----
`AKIA[0-9A-Z]{16}`, # AWS access key ID
`ASIA[0-9A-Z]{16}`, # AWS temporary (STS) access key
`AIza[0-9A-Za-z_-]{35}`, # Google API key
`ya29\.[0-9A-Za-z_-]+`, # Google OAuth access token
`ghp_[A-Za-z0-9]{36}`, # GitHub personal access token
`gho_[A-Za-z0-9]{36}`, # GitHub OAuth token
`ghu_[A-Za-z0-9]{36}`, # GitHub user-to-server token
`ghs_[A-Za-z0-9]{36}`, # GitHub server-to-server token
`ghr_[A-Za-z0-9]{36}`, # GitHub refresh token
`glpat-[A-Za-z0-9_-]{20}`, # GitLab personal access token
`xox[abprs]-[A-Za-z0-9-]+`, # Slack tokens (bot/app/user/refresh/etc.)
`sk_live_[A-Za-z0-9]{24,}`, # Stripe live secret key
`sk_test_[A-Za-z0-9]{24,}`, # Stripe test secret key
`pk_live_[A-Za-z0-9]{24,}`, # Stripe live publishable key
`pk_test_[A-Za-z0-9]{24,}`, # Stripe test publishable key
# ---- OAuth / bearer ----
`(?i:bearer\s+[A-Za-z0-9._~+/-]+=*)`, # Authorization: Bearer <token>
`eyJ[A-Za-z0-9_-]+\.eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+`, # JWT (header.payload.signature)
# ---- Generic key=value secret patterns ----
`(?i:(?:api[_-]?key|apikey|secret[_-]?key)\s*[:=]\s*\S+)`,
`(?i:(?:password|passwd|pwd|secret|token|credentials|client[_-]?secret)\s*[:=]\s*\S+)`,
# ---- Database connection strings ----
`(?i:(?:postgres(?:ql)?|mysql|mongodb(?:\+srv)?|redis(?:s)?|amqps?|mssql|sqlserver)://[^:\s]+:[^@\s]+@[^/\s]+(?:/\S*)?)`,
`(?i:jdbc:[a-z0-9]+:[^\s]+)`,
`(?i:(?:Server|Data Source)\s*=\s*[^;]+;\s*(?:User Id|UID)\s*=\s*[^;]+;\s*(?:Password|PWD)\s*=\s*[^;]+)`,
# ---- PEM private keys ----
`-----BEGIN [A-Z ]+PRIVATE KEY-----.+?-----END [A-Z ]+PRIVATE KEY-----`,
])
replacement := "[REDACTED]"
# -----------------------------------------------------------------------------
# Per-field patches — each is added only when this is a Slack tool, the field
# exists, and it contains at least one match. Fields without matches (and
# absent fields) are left untouched in the final args.
# -----------------------------------------------------------------------------
patches[k] := v if {
k := "text"
is_slack_tool
original := object.get(input.payload.args, k, "")
is_string(original)
regex.match(sensitive_pattern, original)
v := regex.replace(original, sensitive_pattern, replacement)
}
patches[k] := v if {
k := "message"
is_slack_tool
original := object.get(input.payload.args, k, "")
is_string(original)
regex.match(sensitive_pattern, original)
v := regex.replace(original, sensitive_pattern, replacement)
}
# Block Kit blocks: serialize → byte-replace → reparse. If the byte-replace
# produces invalid JSON (possible if a pattern chews across boundaries), the
# unmarshal fails and this patch is silently omitted — fail-safe rather than
# emitting malformed args.
patches[k] := v if {
k := "blocks"
is_slack_tool
original := object.get(input.payload.args, k, null)
original != null
serialized := json.marshal(original)
regex.match(sensitive_pattern, serialized)
v := json.unmarshal(regex.replace(serialized, sensitive_pattern, replacement))
}
# Legacy attachments: same treatment as blocks.
patches[k] := v if {
k := "attachments"
is_slack_tool
original := object.get(input.payload.args, k, null)
original != null
serialized := json.marshal(original)
regex.match(sensitive_pattern, serialized)
v := json.unmarshal(regex.replace(serialized, sensitive_pattern, replacement))
}
# -----------------------------------------------------------------------------
# Apply the transform only when at least one field needs redaction.
# object.union overwrites only the keys present in `patches`; every other arg
# (channel_id, thread_ts, etc.) passes through unchanged.
# -----------------------------------------------------------------------------
transform := {
"transformed_payload": object.union(input.payload.args, patches)
} if {
is_slack_tool
count(patches) > 0
}
# Surfaced on the decision event whenever a patch is applied, so the dashboard
# can explain the rewrite.
reason := "Sensitive content redacted from Slack message" if {
is_slack_tool
count(patches) > 0
} Canonical source: policy.md on GitHub · raw · raw on this site (.md)
Used in these guides
Related policies
Block Secrets in Slack Messages
Blocks Slack send-message tool calls whose message body looks like it contains a secret — API keys, passwords, tokens, or PEM-formatted private keys.
Slack: Deny Channel Creation
Blocks Slack channel-creation tool calls at ingress. Every other Slack tool — and every non-Slack tool — passes through untouched.
Slack: Deny Read/Search/Summarize of Sensitive Channels
Blocks read, search, and summarize operations that target a configurable set of "sensitive" Slack channels.
Slack: Deny Sending Direct Messages
Blocks Slack message-write calls whose destination resolves to a direct conversation — a 1:1 DM, a message posted to a user ID (which Slack auto-opens as a…