# Stop AI agents from leaking secrets into Slack

Once an agent posts to Slack, an API key is in channel history and search. Catch it before the send, not after.

For: Platform and InfoSec teams running an AI assistant with Slack write access

A Slack message is a write you can't take back. The moment your agent calls `slack-post-message`, the text is in channel history and search indexes, and may have already gone out in email digests. So when an agent drops an `AKIA…` key or a `-----BEGIN PRIVATE KEY-----` block into a "summary," redacting on read is already too late. The secret is out.

The fix is to inspect the call before it reaches Slack. The `block-secrets` policy runs at ingress (`tool_pre_invoke`) and denies any send whose body matches a high-confidence secret shape: AWS keys, GitHub PATs, Slack tokens, Stripe `sk_live_` keys, OpenAI keys, PEM private keys, and generic `key: value` pairs. Other sends are unaffected.

A hard deny suits high-assurance environments. Where it gets in the way of normal chatter, reach for `redact-sensitive-info` instead. It rewrites the matching substrings to `[REDACTED]` and lets the message through, minus the secret. Use deny where you can't tolerate a leak; use redact where you'd rather not break the message. Both run on the same pipeline, so you can attach either one or layer them.

## Policies in this guide

- [Block Secrets in Slack Messages](https://www.intentbasedpolicy.com/policies/slack/block-secrets) — 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: Redact Sensitive Information from Messages](https://www.intentbasedpolicy.com/policies/slack/redact-sensitive-info) — Redacts sensitive content from outgoing Slack message arguments before the call reaches Slack.